PhoneGap: How To Create One App For All Platforms

May 23, 2013 3078 View
← Back
PhoneGap: How To Create One App For All Platforms

Based on the report contributed by MobiDev to iForum 2013, written and presented by our leading PhoneGap specialist Yuriy Luchaninov.


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.



300 ms lag between touch and click event on touchscreens

touchscreen

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

problem with 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 structure of the app screen

DOM

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

long listsLong lists2


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.


In native components it's realized, as shown on the first part of the picture, with replacement of data in an invisible element, and with change of its position. This means there's no list of 1000 elements on the screen - there are 10 visible elements, while others (cache) are hidden, and alter their content.


A suggested solution to this problem is pagination, which divides the list into parts. It can be realized with a JavaScript library, which implements the adapter pattern, similar to native components.



Useful tips for building a good PhoneGap application


Place input fields on the upper side of the screen;

Avoid long lists and overloading screens with excessive elements;

Avoid shades, which decrease performance on low-end Android devices:

Gradients don't always look good (depending on the display quality and screen resolution), and require extra capacities, in comparison with one-color fill. That's why, just like shades, they should be applied only out of necessity;

Semitransparent fill should be implemented as a .png file, in order to make it render the same on various platforms;
Use the capacities of the graphics processing unit (GPU) for animations.



What are the advantages of PhoneGap?

+ The most obvious advantage is cross-platform capabilities, and the number of platforms to choose from;
+ PhoneGap apps are written upon HTML, JavaScript and CSS, with the opportunities of using numerous external libraries;
+ Adjustments can be performed via browser; remote adjustments can be performed on a mobile device via "weinre".


What are the drawbacks of PhoneGap?

- Necessity to optimize UI for different platforms. Each platform requires an extra amount of time for this optimization; however, it's much faster, than creating another native app from scratch;
- No support of multithreading, since not all of the mobile WebViews have the implemented WebWorkers. This can be resloved through native PhoneGap plugins;
- Necessity to create a responsive interface (including the abovementioned problems - the 300 ms lag, the problem of touching, optimization of DOM and long lists).

As you can see, these drawbacks are not quite 'drawbacks' in their nature, but rather make up the technical conditions of PhoneGap - its specificity, which you should consider, like in a usual mobile development for all platforms.

Thus, if you want the app to perform complicated calculations, or display a lot of data simultaneously - it's a matter of native development.


PhoneGap will be a perfect solution for your project, if:

• You need a great unique UI;
• Complicated calculations and operations are performed on the server side;
• The app contains a lot of image, audio and video content.


Thematically PhoneGap suits best for:

• mass media;
• online shops;
• portals, forums and blogs;
• presentations, branded and PR applications;
• applications for tourism industry etc.

PhoneGap sheme


Others also read:
comments powered by Disqus
scroll top