PhoneGap: How To Create One App For All Platforms

PhoneGap is a popular framework for creating cross-platform applications. The main advantage is the possibility of using the same code on various platforms. But that's not fully correct, because PhoneGap is a native WebView component, which has an HTML5/JavaScript application; and which is able to access the native functions of a mobile device (accelerometer, compass, contacts etc.).


Choosing platforms for a PhoneGap application


Currently PhoneGap supports the following platforms: iOS, Android, webOS, Windows Phone, BlackBerry, Symbian OS, Tizen. We can check the statistics: covering just two platforms (Android and iOS), we cover 91% of the whole smartphone market; as well we cover Apple App Store and Google Play, which hold 92% of revenue volumes.


A good app is a responsive app - that's one of the main tasks to fulfill in PhoneGap development. The user won't feel discomfort, if the app, while performing a long operation, blocks the interface and shows the progress bar. But the discomfort appears when a user touches the button that doesn't respond at once. And it's not a matter of several seconds - it takes only 100 millisecond lag between touch and response to cause a subconscious discomfort. And that's how we feel that the app interface doesn't react as an object of the physical world.


What are the problems in making a PhoneGap application responsive? Let's accentuate the specificity of PhoneGap development.


1) The 300 millisecond lag between touch and click event on touchscreens;
2) The problems of touching;
3) Optimization of DOM (document object model) of the app screen;
4) The problem of long lists.
The 300 millisecond lag between touch and click event on touchscreens


Mobile browsers on touchscreen devices have a timeout of 300 milliseconds to avoid a false click by an accidental touch. The solution to this problem isn't hard to be found around the Internet. There are several JavaScript libraries, and their work principle is the same - tracking such events as TouchStart and TouchEnd - and at the moment when the latter is done, runs a click event. It's hard to find a library that correctly transmits and installs focuses for elements, and which consistently works with different types of input fields on different mobile operating systems. That's why the solution here is to generate not a click event, but rather a custom event (e.g. tap event), and react to it directly.






The problems of touching


One of the most widespread bugs in PhoneGap apps is usually described as either "I touch the button, but it doesn't always work", or "I touch the button to no response". This bug appears due to improperly created interface, and it raises the problem of touching.


Here we can see how the finger interacts with the device. The red spot shows the visual contact area between the finger and the screen, while the green one shows the real contact area. These areas differ, because we look at the touchscreen at an angle, while the finger-cushion is curvy.


The difference is measured by mere pixels, but with small interface elements it's enough to feel. With bigger interface elements, there can be a complaint like "The lower side of the button doesn't respond to the touch." This can be corrected quite simply - proper layout of the app page. For example, the area of response can be made bigger than the button itself - placed upon a bigger, invisible interface element. Or otherwise, the button size can consider the possible area of a touch.
Optimization of DOM (document object model) structure of the app screen


Let's look at a more or less standard app screen:
This example shows a page with 300 HTML elements (DOM objects). An average page of a PhoneGap application contains 100 to 250 elements. It should be mentioned that we don't consider pages with long lists yet. On average, an app has 5 to 15 pages. But unfortunately, JavaScript apps have no mechanism to store and transmit data between the pages.


For example, if you choose an element of the list on a page, then proceed to another page to display the result - you need to store data somewhere between the pages. Usually these data are transmitted through the server and are stored there. But since WebView gives no opportunities to transmit data between the pages, there has to be another solution.


One of the simplest ways to solve this problem is using one-page apps. These are apps that display the same page, which has changing content. This approach causes lags in the app. The more complicated the app is, the longer lags are.


There are two ways to solve the problem:
1) Load the content of the page with Ajax queries;
2) If the page is loaded, the branches of DOM, which are responsible for invisible pages, should be detached from the main DOM tree, while links to these branches should be saved in JavaScript;
The maximum optimization can be reached with two of these combined. Then you will have to load the page just once.


The problem of long lists

This problem basically begins upon the previous one, which adds the necessity of rendering or recalculating the list elements, including the invisible ones. For example, if the fill of a list element depends on its position in the list - the rendering machine will apply CSS to all of the list elements, including the ones that are beyond the visible area.

To read further feel free to visit our BLOG