Creating hybrid mobile applications

Looking over a portfolio of legacy applications, it might be relatively easy to identify the ones that clearly need to be modernized, but figuring out to what can be slightly more challenging. 

It's not a decision to be taken in isolation. One critical component to the answer is the total cost of modernization. Getting a line of business app off Windows XP to an equivalent desktop version on .NET/C# might seem to be all that's possible with the current budget. Even though there would be great benefits and long-term economies in moving to a Web-mobile version, is it financially feasible? And with users embracing BYOD and all it represents, a pure .NET version leaves a lot of use cases out in the cold.

What's a CIO to do? Going from "really old" to "cutting edge" looks like a major rewrite, with all the costs, time, and risk that implies. Does the CIO have to tell internal customers that a desktop version of the same old app is the best they will get?

A strategy for success

If you're facing this delimma, there is a strategy to get you current and meet customer requirements. You can simultaneously get off an antiquated platform and provide desktop, web, and mobile versions of your app. Make everyone happy. Get a gold star on your performance review. 

Step 1: Use automation to convert your legacy app to .NET desktop. Congratulations! Now you're off your old platform. From here on, everything else is gravy.

Step 2: Use automation to slice the UI from your .NET app and create a new HTML5 version. Way to go! Now you've got a web version plus it's handily refactored to make it easy to put the business logic and database up in the cloud.

Step 3: Use PhoneGap (or similar framework) to build mobile versions from the HTML/JS code. What a superstar! Now your users are able to BYOD and use the app on whatever device they have. 

The nice thing about this strategy is that it avoids the need to rewrite everything, it allows you to use tools to dramatically cut the cost of application modernization, and winds up with a nice cross-platform strategy.

Cut to the chase: why hybrid development?

Hybrid mobile development makes a lot of sense for LOB (line of business) applications. Most of your application is written in HTML5 and Javascript, using css files for formatting. Application frameworks like PhoneGap, can make it easy to have a single code base that targets iOS, Android, Windows Phone, even Blackberry. Capabilities that are either not yet supported in HTML5 or are unreliably supported on different platforms can be accessed via native API calls. The alternative on tablets and phones would be either a browser-only version that couldn't take advantage of things like geolocation or accelerometers or else multiple native versions.

There are a number of frameworks that address hybrid development (see the link above), many of which are based on Javascript but there are other approaches as well. The ones that run in Javascript by their nature can't exist as a complied executable so there are performance issues--these may or may not be showstoppers for your application. 

Other issues include:

• Memory utilization: adding the JS layer on top of your app can increase the memory footprint, which might kill some background processes for other apps
• Device balkanization: Different devices support different stuff so you can count on everything being available. Users with older devices may not be able to upgrade to the lastest version of their OS. You'll need a way to gracefully handle those exceptions.
• Battery: mobile devices typically operate un-tethered, so battery consumption is potentially an issues. Be sure you understand how your app consumes power and where you can optimize for battery life.
• UX: A phone isn't a laptop, nor even a tablet. Moving an entire UI from a formerly-desktop application to a 5 inch screen is usually a bad idea. You may need to think about slicing the application into more modular pieces to handle only the most common use cases.
• Widgets: some frameworks give you a native look and feel, others don't. Is this important to your users? If so, factor that into your development strategy.

When to go native

HTML is a great way to go, but it's obviously not always the best approach. A pure-native application will always beat the performance of a hybrid application and will have the familiar look and feel the user is accustomed to on their device. But writing native versions means you need skills not only in the native API and programming model, but also in the language (ObjectiveC? Java? C#). And, of course, it means branched code with all that implies for future updates as well as current debugging. If you're writing a commercial game, of course you will probably think native first. For a LOB application, unless you need the extra je ne sais quoi of a native version, look to Javascript, HTML, and your framework of choice.