Creation of a hybrid mobile application, part 1

Author: Daniel Jozsef June 25th, 2012

, , , ,

In the last few weeks, I have worked on the iOS version of a hybrid mobile application. It was an epub-based book reader we created for both Android and iOS, with support for rudimentary DRM and shoplike functions (ie. downloading books from a central location). While the reader part (rendering and navigation) was built entirely in JavaScript, we made use of native code for the DRM and network connectivity components.

In this series of articles, I am going to walk you through an abstraction of the project we created (some details will be changed or left out, out of courtesy for our client), and shed some light on the peculiarities of developing hybrid mobile applications.

Hybrid apps have become something of a fad in certain developer communities. If you might not be certain what we mean by hybrid app, it is a mobile application that uses HTML, CSS and JavaScript for its presentation component, and possibly part or whole of its business logic, but takes on the form of a “proper” mobile application, usually distributed through the central App Store.

The most popular way of developing these applications is using the PhoneGap framework, also known as Apache Cordova since its enrollment in the Apache incubator program. It is a actively developed system that allows you to compile a HTML5/JavaScript application for Android, iOS and Blackberry devices, with the possibility to add native plugins, ie. native code that can be accessed from JavaScript through a pre-defined interface. Thus, if your application needs to perform operations that fit better with native code, you can still code the body of the app in JavaScript, and create the critical components in native code (of course, in this case, you need to code these parts for all targeted architectures separately).

I am going to focus mainly on iOS development, but the basics are the same across all platforms. So let’s start with…

* Snappy UI or sluggish CPU hog

The first question you might ask is “but aren’t hybrid applications slower and more sluggish than native ones”, and the answer is that it depends entirely on how you go about coding the UI. Using the right techniques, and leveraging the power of the GPU present in high-end mobile devices will result in a satisfying user experience, while failure to follow best practices might indeed render your application slow and unresponsive.

Even though hardware accelerated graphics might not be the first thing to come to mind when thinking of JavaScript, in fact most modern mobile devices use acceleration to display CSS3 effects. Open source libraries such as iScroll can help you make use of accelerated CSS3 functionality in creating specific effects, without the need to code everything from ground up. For example, iScroll will give you an “elastic scrolling” experience similar to native applications.

Another important aspect of using iScroll is that many Android phones have a deficiency in displaying position: fixed elements. So in screens where we needed to display a static header and footer, we used absolute positioning, and made the central work area scrollable using iScroll. Thanks to the hardware acceleration, we didn’t experience any slowdown compared to “native” scrolling.

There were many use cases where we needed to change the appearance of something programatically, such as  setting the display to night mode, changing font size, etc. In cases like this, if by any means possible, you should follow our example, and use pre-defined CSS classes. Changing classes from JavaScript, and relying the preloaded static CSS rules is magnitudes faster than setting inline style from code.

Another extremely important point is that you should keep all screens in the same html file as <div>elements, and navigate by setting their visibility. This is magnitudes faster than loading new html files, which would mean reloading all JavaScript resources as well, and losing application state.

* Making the page play nice with mobile browsers

Speed is not all, there are some other things to remember when coding HTML for mobile platforms. Inadvertent scaling of the viewport can result in an unprofessional look, and even make your application borderline unusable. Few people are aware, but for example the mobile Safari will not display pages with 1:1 zoom by default, which means pixel-perfect screens put together specifically for the iPad will, by default, stretch off the screen when loaded.

To fix this problem, and to disable the pinch-to-zoom functionality built into the HTML viewport, you need to specify the following META tags:

These tags will fix the first problem. The first one is for webkit-based devices (ie. iPhone and Android) while the second is for Microsoft devices. For the second tag, you need to set the screen width you optimized the page for.

And to disable pinch-to-zoom, set the following:

That’s all for today, next week I am going to go into some detail about the app, and show you what you need to do to start building PhoneGap apps in XCode.

, , , ,