Guest Blogger: Paul Conte, President PCES, is a leading Application Development Strategist.
My wife and I just got back from three weeks in the southwest of France; and when we travel, we like to go “native.” In this region of France that means a daily diet of duck, truffles and goat cheese, washed down with local red wine and a final dose of rustic Armagnac. You can see why I like the “native” approach!
The same is true for travel apps on my Samsung Galaxy S III, our ever handy trip companion.
Web browser apps just won’t do for maps, navigation, weather and on-the-spot translation. And the benefit of mobile apps isn’t limited to these workhorse categories. On this trip, we narrowly avoided being forced to spend an unplanned night in Amsterdam when our flight from Paris to Amsterdam was delayed so long we couldn’t have made our connection back to Seattle. It was Delta’s mobile app that saved the day. While hoards of unhappy passengers on the same flight crowded around the gate, I used this app to display a personalized list of alternative itineraries and in only a few minutes, confirm a switch at no cost to a direct, Paris-to-Seattle flight.
Here’s why most of the highly-rated mobile apps are native – they’re faster and take more advantage of mobile device features, such as the camera and GPS. And good native apps also have a familiar user interface that’s consistent with your mobile device, whether it’s an iPhone, ‘droid or Windows phone.
For IT professionals looking to develop mobile apps, however, there’s another side to consider before “going native.” Native mobile apps can be as painful to create and maintain as scrunching up in a coach class middle seat on an 11 hour flight from Paris to the west coast.
As with travelling, there’s a difference between going native and going “primitive.” I’ve left behind my days of living off bread, cheese and mystery sausages and my nights of trying to sleep in a musty youth hostel. Similarly, you don’t have to rely solely on “bare metal” languages and tools to exploit the benefits of native mobile apps.
Like a savvy traveler, you can enjoy the benefits of going native while still staying in your comfort zone. Two strategies are available: so-called “hybrid” mobile applications or using a proprietary mobile app platform with a “native” engine that runs on target devices. Before looking at how these approaches work, let’s consider some of the requirements for high-quality mobile apps and the hurdles to delivering them. I’m going to concentrate on business applications (rather than games, for example) from the perspective of an IBM i developer.
Although there are exceptions, in most situations you’ll want your mobile app to run on at least Apple (iOS) and Android devices. Some enterprises will also want their apps to run on Windows Phone and/or Blackberry. The problem with a primitive approach to going “native” is that developers will have to master the complexities of multiple operating systems, programming languages, development tools and device-specific APIs and user-interface conventions. The high cost and lengthy time-to-market of this approach is a show-stopper for most IBM i development organizations.
Needless to say, you want your applications to perform well, which is one of the main reasons to go native, rather than go with traditional web-browser-based apps. Similarly, mobile apps should have the “look-and-feel” of the device on which they’re running, whether it’s an iOS, Android, or other device.
In many cases, business applications need to access data and programs that reside on an IBM i server.
These are pretty imposing objectives, and no doubt if you’re an IT manager, the first thing that comes to mind is “How is my current IBM i development team going to grapple with all the new skills that’ll be required.”
Well, let’s take a look. If you leave integration with IBM i data and programs out of the picture, “hybrid” mobile apps can greatly simplify development and support for multiple targets. All the major mobile OS players are supporting a set of industry standards that provide much of what you can accomplish by device-specific development, but using only one set of languages and supporting development tools. These standards include the HTML5, CSS3 and JavaScript for Mobile languages, along with associated libraries and tools, such as JQuery Mobile. A good starting point to learn about these standards is mobilehtml5.org. Various organizations and vendors offer frameworks on top of this platform to simplify user interface and other aspects of mobile app development, for example JSON, Dojo Mobile and Sencha Touch. Check out a comparison of these offerings.
The “hybrid” strategy is essentially based on taking markup and scripting languages that were originally intended for pretty simple web page layout and logic and turning them into full-function languages that support cross-platform, mobile application development.
Now, here’s the wrinkle for IBM i developers. Although the new standards simplify mobile app development and address the complexity and cost of targeting multiple mobile devices, the set of languages, libraries and tools still requires a traditional IBM i developer to master a daunting array of new skills. In addition, nothing in these new languages is really targeted at supporting and simplifying integration with IBM i data and business applications.
An alternative approach addresses the full range of issues by providing a completely native mobile application for each of the targeted mobile OSs. This family of runtimes or “engines” presents a consistent mobile application platform that addresses multi-device development, as well as providing additional functionality, such as simpler ways to access server data and invoke server programs from mobile apps.
The LongRange application development product is an example of this approach. The concept is really quite simple – LongRange supplies a native mobile application, which is installed once on a mobile device. This application renders user output sent from the LongRange server installed on an IBM i. The output can be a native interface (called a “form view”), an HTML web page (if you want to reuse any existing web apps), or a plugin that automatically synchronizes local and remote files and folders between the mobile device and the IBM i. The form view is a native interface that harnesses all of the standard elements on the device, such as tabs, drop downs, date pickers, check boxes, data fields and text labels.
What’s of particular interest to IBM i developers is that form views can be defined using the familiar DDS language, which LongRange enhances with extensions that provide additional support for mobile device features, such as audio, image and video capture, GPS and more. When a form view is rendered, the native app handles sizing and orienting the screen, based on the device size and position. A normal RPG or COBOL program controls what gets sent to the mobile device, and the LongRange server takes care of the necessary translations and communication “hand-shaking,” relieving the application programmer of that kind of “plumbing” coding.
Going the other way, the LongRange mobile app recognizes user actions (such as a touch) and either responds appropriately or sends a command and associated input back to the LongRange server, which returns input and invokes the appropriate RPG or COBOL program, if necessary. As you might expect, input from the device can include images from the camera, GPS location coordinates, etcetera.
Because LongRange is built on top of a cooperating native mobile app and an IBM i server application, it’s able to deliver both mobile device and IBM i functionality which a developer can exploit with RPG or COBOL and DDS. And, since LongRange also supports standard web page definitions, developers retain the freedom to embed existing or new HTML/JavaScript where that may be useful; providing the widest range of development options.
This strategy offers a lot of promise for going “native” without the pain, and I suspect we’ll see more vendors of application development tools following this lead in the future.
