|Mobile Architectures: Which Way to Go?|
|Networking - Wireless / Mobile|
|Written by Joe Pluta|
|Wednesday, 31 October 2012 00:00|
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.
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?
|Last Updated on Wednesday, 31 October 2012 00:00|