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.
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.
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.
Let's look at a more or less standard app screen:
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;
The maximum optimization can be reached with two of these combined. Then you will have to load the page just once.
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.
• 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.
+ The most obvious advantage is cross-platform capabilities, and the number of platforms to choose from;
+ Adjustments can be performed via browser; remote adjustments can be performed on a mobile device via "weinre".
- 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.
• 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.
• mass media;
• online shops;
• portals, forums and blogs;
• presentations, branded and PR applications;
• applications for tourism industry etc.
July 03, 2014
On June 2, 2014, Apple has announced the news that no one expected: a new object-oriented programming language - Swift. What's... more →
July 12, 2013
Based on the report contributed by MobiDev to iForum 2013, written and presented by our leading PhoneGap specialist Yuriy... more →
On April 24, MobiDev participated in iForum, which is the biggest conference in Western Europe, dedicated to IT, Internet, and... more →