Mobile cross platform development

Among the many mobile app development challenges (user experience being one of the most important) the platform is one of those that has seen many solutions raising in the recent.

There are a few platforms out there, some are growing (iOS and Android), some are still in the process of seeing sun light (Microsoft) and some are slowly falling to the backyard of the market (Symbian, BB, etc).

When you develop a mobile app you either learn all the platforms you want to support or you try to leverage the frameworks available out there.

There a few promising mobile app portability frameworks, each with their own pros and cons and, obviously, none can really stand the comparison against the true native app, but you must be ready to sacrifice something at the altar of portability.

HTML5

One type of portable frameworks relies on the web and it’s HTML5 ecosystem to provide an “almost native” experience: you develop an HTML5 application, then the framework wraps it in a headless browser exposing some native functions through JavaScript.

One of those frameworks is Apache Cordova (previously known as PhoneGap) which does exactly what I just described and supports many different mobile OSes, not all of them at the same level though. The JavaScript mapping functions allows an HTML5 app to store data locally, access the phone camera, know the device orientation, access contacts and calendar, etc…

This approach produces 99% reusable code, meaning the only non reusable parts are the little native bits you might need to plug/customize to get some native features: as an example, if you want to show one of those ad banners using the native ad provider, you need to plug in a little native fragment.

Performance wise these type of frameworks have a limitation directly connected to the native web browser component: faster is the native browser, faster will be your app.

Please note that this type of frameworks usually do not provide any widget by themselves: they just present whatever HTML5 content you tell them to render: while this might be a great benefit it is usually their greater weakness.

To achieve a pseudo native UI style the designers/developers have to pick some JavaScript framework capable of styling HTML tags appropriately (or write their own very specific CSS/HTML) like jQuery Mobile, Sencha Touch and so forth. When using such libraries a lot of JavaScript and DOM processing is involved which results in UI being a little sloppier than the native ones.

In my experience such difference is not so bad to make apps unusable, but you can definitely say it’s not native or not really optimized. Please note: this is not an issue directly related to the portable framework itself, but to the native components these framework use and the UI library the designers adopt.

Native Mapping

Another approach to achieve mobile app portability is through a common mapping layer/library: this approach consist of exposing through a uniform library the interface of the native components, as per the well know Adapter design pattern. This is the same approach Java used for their AWK library. The greatest limit of this solution is the framework either exposes the Lowest Common Denominator (abbrv LCD) of the native features or delegates to the end users the problem (AWK used the first approach, which revealed as a failure).

One expression of this approach is Appcelerator Titanium which remaps native operations/function/structures into JavaScript ones, including UI components.

The level of reusability these approach provides is definitely lower than the previous one and can greatly vary depending on a per app basis: their authors state a generic app usually reuse 80% of the codebase, with the remaining 20% customized on a per target OS. These figures are still good considered the 100% non reusable code you get by going completely native, but what is the performance/capability loss? Well, from a capability point of view, the loss is usually not so much if the framework you adopt has taken the approach of exposing the union of all the features available on the OSes it supports. Please consider though there is a time gap between when a features is made available on the native OS and the same feature becomes available within the framework.

Performance wise it depends on the framework approach, as an example Appcelerator Titanium went for an interpreted language (javascript) which has very good support and performance attention by many OS vendors, mainly because it is used within their native browsers! Obviously a compiled approach would provide better performance at the price of lesser portability.

There’s no silver bullet here yet: pick your option considering the different pros and cons while the market evolves and new options get explored!

Advertisements

Testing your web sites

Testing your web sites

Have you ever got an email from a customer saying something like “Hey man, your website is damn slow!” but you don’t experience such slowness where you are? Or something like “I can’t see that button you are talking about” while you can swear that button is there?

Well, this tool can help you solve those problems because ti allows you to specify a location, a URL and a web browser providing you a screenshot and the performance breakdown!