I know….I started a 5 part series on debugging WAMS, and the series is not done yet. It has been a very busy past few months. More installments will be coming shortly, and they are good ones. However, I recently had an opportunity to use LANSA LongRange. The new(ish) LANSA tool for building apps to deploy on Mobile devices. I thought I would take a few moments to document my experience and give a review.

My Rating: 4 Stars (out of 5)

LANSA LongRange is a Native Mobile app development tool which allows the developer to use either LANSA code or RPG to drive the application.

• Without learning a new language, the LANSA developer is building pages in no time. The applications built with this tool are cross platform and are deployed to the end user as a native app for iPad or Android.
• The tool includes a schema editor. The schema allows the user to setup buttons and menus which would used by the screens. Not much time was spent in there…it was used mostly in the beginning to build the menus for each page, and then only once in a while when adjustments needed to be made.
• When running in online mode, there is no presentation or data stored on the mobile device. The presentation, business logic and the data are all stored server side.
• When building code, you actually send instructions to the mobile client where fields, tables and objects are stored on the screen. Some may not like the presentation layer being mixed with the logic, but in this case, it has a very big benefit.
• Changes require no new deployment. Changes are rolled into production on the server, and immediately show up on the mobile client.
• The app store has a LANSA LongRange app in it. This would be installed on all the clients, and then your server side code does the rest.

Overall, I enjoyed working with this tool. I worked with a team which built an application consisting of about 8-10 very complex pages and integrated with legacy backend systems seamlessly. The pages had many advanced features like attaching photographs, capturing signatures, and validation of all the input data with highlighting of fields in error. In the backend we also have a PDF generation component (using LANSA Integrator) which allowed the signatures to be added to the PDF’s. We took the online approach, which means that all our data is stored directly and immediately on the server. The end user would require a full time connection to use this application. This was a design decision as the tool supports offline application development as well. We took approximately 3 months to build the meat of our application with about 2.5 developers. More time was spent afterwards going through the QA process, and dealing with requirement changes. We had no real training, but reviewed the shipped documentation and had some mentoring by someone experienced with the product. Having someone experienced on the project was invaluable, and while the tool is fairly easy to use, there are some nuances that would cause a new developer to spin their wheels (or make a bad design decision) if left to their own devices. I am aware of another team elsewhere who is building a similar mobile app, and has been at it for a long time with a cost of more than 10 times what this project incurred. This tool does not feel to me to be completely mature yet, but I am sure that with time LANSA will fill out the extra “power” features which will make this into a 5 star tool.

The Positive

• No new language to learn
• No new Editors to install (only partially true… A schema editor was included, but all real code was built in the standard LANSA IDE)
• Complete and seamless integration with all your server files which you are already using, and all your existing LANSA code libraries and objects
• Application changes do not require full re-deployments
• Trace logs were built in to simplify debugging
• Online/offline capabilities
• iPad and Android compatibility without having to learn multiple languages. My experience is only with the iPad.
• No communication layer required to be built so that your app can talk to the server
• Apps could be built purely with your iSeries developers. Nobody needs to learn Objective C.

The Negative

• Better documentation required
• No WYSIWYG screen design tool
• It wasn’t clear to me how to step debug

Andy
LinkedIn
https://plus.google.com/+AndyBain
@jandybain