PhoneGap: What Is Good And What Is Bad
Based on the report contributed by MobiDev to iForum 2013, written and presented by our leading PhoneGap specialist Yuriy Luchaninov.
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, neither 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.
If the default API is not enough, PhoeGap Plugin API will allow to write a code, which implements the lacking functionality. This code is written on the native programming language, which is specific to each peculiar platform.
a native browser (webView), embedded in the project;
API for writing native plugins;
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 suggested solutions for these problems. Thus we reached a conclusion that the 'weak points' of PhoneGap are basically technical specificities, which should be treated as such.
To conclude, here are several useful tips on PhoneGap development - to save time and avoid frustration.
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;
The app doesn't 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;
Use CSS background to display images; therefore an image will be loaded only if an element of the list is displayed on the screen;
Place input fields on the upper side of the screen - thus you'll avoid differences in behavior of the page layout while displaying the keyboard;
Long lists are a problem that should be avoided - unless you have a solution;
Avoid shades, gradients and translucency, where possible. All this finery requires extra power, that's why use it only where necessary;
Use the power of the graphics processing unit via CSS.