Support MC Press - Visit Our Sponsors

Forums Sponsor

POPULAR FORUMS Unable to create java virtual machine on V7R1 (805 views) RUNRMTCMD to Windows Server 2008 R2 (613 views) Fixed header table plugins (577 views) AIRLIB Objects Work on V7R1? (549 views) CL to monitor job queue and release jobs (488 views) PDF Colors and Fonts - Do these changes apply only to Paragraphs? (471 views) Password-Protect PDF in the IFS (371 views) CL to monitor job queue and release jobs (351 views) 35 free gem-quality diamonds (245 views) Print Bar Graph from RPG (243 views)   Forums

Search Sponsor

 

Search

 

So you think you're ready to go mobile? You may want to take a moment to review your options, because your success will depend on your choice.

Just when you thought it was safe to go mobile! With the advent of HTML5 and its great acceptance within the mobile community, you might have thought that you were going to get to a nice, standardized development strategy. Ha! Silly you!  

In fact, the mobile landscape has become splintered in the last couple of years with a whole spectrum of new development tools and frameworks. In time, I'd like to introduce you to each of them, but for now let's focus on the bigger picture.

The Big Three Options

The three major options consist of Web apps and native apps. ("Uh, Joe, that's only two options.") Why, right you are! But you see the third option is a hybrid of the first two; in fact, the industry term for such an application is "hybrid app." And since the third option has characteristics of the other two, I'll explain those two first.

A pure Web application is straightforward: you use the base characteristics of the browser. These days, especially for mobile devices, you can count on the availability of HTML5. And as long as you're using the "webby" features as opposed to the evolving native access features of HTML5, you can feel comfortable that your application will run on most devices.

But what it "webby"? Well, that's pretty much anything that doesn't use the actual hardware of the device, such as the camera or the GPS. While HTML5 will eventually support these things in a standard way someday, that day is not today. In fact, those sorts of extensions are very implementation-specific and very bleeding edge. As an example, access to the camera device was originally going to be through a <device> tag, but that has since changed to a JavaScript API call, which may in turn change again before the standard is finally codified.

And so today if you want to make use of the mobile device hardware, your best bet is to use a native app. A native app is one that's written in the base language for the device (for example, Java for Android devices or Objective-C for Apple). Native apps, though, come with a couple of downsides. Unlike a Web app, which can be accessed passively by just surfing to a Web site with the device's browser, a mobile user has to actually download and install a native app on the mobile device. And typically this download operation will require asking the user for special permissions since by default most devices don't allow unfettered access to things like the hardware or even the Internet. So even though you download the app from the Internet, you have to then execute a second step to enable it to talk to the Internet (something I assume most business apps are going to want to do). Granted, it's not a particularly onerous process to download and enable an app, but it is an additional hurdle. The bigger problem is that you need to write all the business logic and UI code multiple times in multiple languages—Java and Objective-C at a minimum—and that's a lot of duplicated effort.

Which brings us to the hybrid architecture. A bit more complex at first blush, the hybrid architecture has the potential to simplify your development effort considerably. The idea is to use traditional HTML5 for the bulk of the application, but to wrap the HTML5 in a native framework that provides access to the mobile device through standard APIs. The wrapper itself is the only part that's device-specific; you need a different wrapper for iOS than for Android, for example, but within the wrapper your application stays the same.

How to Choose, Then?

That's the $64,000 question isn't it? For me, unless you have complete control over your target device community and can force your users into either Android or iOS, then fully native apps for anything more than a trivial project is just too much duplicated effort. And since it's rare that you can lock your users down like that, especially in this day of BYOD (Bring Your Own Device), the reality is that the choice is either pure Web app or hybrid. The choice there, though, is relatively simple: if you don't need the device's hardware, use a pure Web app written in HTML5 and JavaScript. Do that, and the beauty of the hybrid architecture is that if you do decide to go hybrid, you can reuse most if not all of your HTML5 work.

There are several hybrid frameworks available today, including PhoneGap and IBM Worklight. I hope to bring you more information on those solutions in upcoming articles.