PhoneGap: What Is Good And What Is Bad


PhoneGap is a framework for cross-platform development on HTML / JavaScript, for seven mobile platforms. Today one can read a remarkable number of articles dedicated to PhoneGap, written by either native developers, who tried out cross-platform programming, or front-end developers, who tried out mobile development. Their assessment of how good or bad PhoneGap is, is influenced by their original field of activities; therefore PhoneGap is called either 'cool' or 'flawed'.

But there are developers who dedicated their activities solely to PhoneGap development, and they study the subtleties of this cross-platform framework. There's no universal solution, either in native development, nor in cross-platform development. Everything depends on the software project; and these subtleties can help decide whether PhoneGap should be chosen as the platform for the project.

The cross-platform capabilities of PhoneGap are achieved in the following way: a native project is generated, distinct for each platform, which includes a browser (a native webView component) as the main component. This browser is able to display HTML / JavaScript code as a usual web page. The file system of this project acts the part of a file server, which gives access to the page. As an additional bonus, there is an object that allows PhoneGap to standardize the access to native features of mobile devices running the supported operating systems, such as camera, compass, accelerometer, contacts etc.

If the default API is not enough, PhoeGap Plugin API will allow to write a code, which implements the missing functionality. This code is written on the native programming language, which is specific to each specific platform.

Basically, a PhoneGap project contains four functional parts, which ensure the implementation of the HTML / JavaScript code:
1) a native browser (webView), embedded in the project;
2) structured API for accessing the native functionality of a mobile device from JavaScript code;
3) API for writing native plugins;
4) file storage, which contains HTML, JavaScript, and other web resources of the application.
Thus PhoneGap allows to build a service-oriented, single-page HTML-5 application.

99% of PhoneGap development is layouting and JS coding with consideration for the environment peculiarities (a mobile device, limited processing power, memory, touchscreen etc.) and browsers. During PhoneGap development one needs to consider the specificity of each platform, its default browser (which has webView based upon it). PhoneGap is demanding, when it comes to architecture and optimization. User interface has to be optimized for each platform; that's why specifying the target platforms will affect the time spent on the project.

We have previously touched upon the issue of PhoneGap, and outlined four major problems while building a responsive app on PhoneGap: the 300 millisecond lag, the problem of touching, DOM structure optimization and long lists. And we have proposed solutions for these problems. Thus we reached a conclusion that the 'weak points' of PhoneGap are basically technical specifications, which should be treated as such.

To conclude, here are several useful tips on PhoneGap development – to save time and avoid frustration.

1) The fewer external libraries are used, the better. This concerns the limited resources of a mobile device. It's close to having a fleet of ships to carry one single box (the business case of the application). The fuel will be consumed by the whole fleet. Choose libraries thoughtfully and try to fully utilize their capabilities;
2) The app does not have to look the same on all platforms and OS versions. It's better to make a trade-off in style and appearance of an app, in order to keep the speed and functionality intact;
3) Use CSS background to display images; therefore an image will be loaded only if an element of the list is displayed on the screen;
4) The optimization methods, applicable for web pages with client-server architecture, are not always the best solution for a PhoneGap application. There are no long network requests for loading HTML / JS / CSS files, so there's no need in considering the size of a JavaScript file, or, for example, in minimization of invisible pixels in an image. Choose a way to cope with the unavoidable 250 millisecond lag before a file loads; our choice was lazy preloading and tiles;
5) Place input fields on the upper side of the screen – so you'll avoid differences in behavior of the page layout while displaying the keyboard;
6) Long lists are a problem that should be avoided – unless you have a solution;
7) Avoid shades, gradients and translucency, where possible. All this finery requires extra power, that's why use it only where necessary;
8) Use the power of the graphics processing unit via CSS.


Leave a Reply