Saturday, July 26, 2014

Mobile Development with Cordova (Phonegap): Chapter 8

Chapter 8: Tips on Writing Your App

Now that you can compile and distribute your apps, the hard part is past... and now comes the lengthy part, actually writing out your application, then revising it repeatedly as specs change and budgets dwindle. That's all on you: if you're using this tutorial then you should know enough about web development to do that on your own.

But, here are a few pointers and pitfalls that may help you out.


First, I'll get the self-promotion out of the way. I have written up a starter app, which includes jQuery mobile, leaflet for doing maps, a good starting place for a welcome page, a settings panel, and so on. You may want to check it out.

Choosing a HTML/CSS framework

jQuery Mobile is quite popular, and we use it quite a lot here at GreenInfo Network. The big bonus is that it is jQuery and therefore ubiquitous, with a very large community and a startling number of plug-ins, hacks, and known workarounds. It is also very much based on HTML, and therefore as the lowest barrier to entry of most mobile frameworks, by virtue of letting you use HTML, CSS, and JavaScript much as you normally would.

It is not a panacea, however. The applications tend to look very "canned" and not entirely native as much as mobile-friendly websites (which is the point). The responsiveness isn't always great either; it definitely feels slightly more lagging then a truly native app.

You can ask Google for a plethora of other frameworks and opinions. Lately, we have become interested in Ionic which is based on AngularJS. This technique involves a more programming than HTML, and requires more structure instead of chaos, but in return, the apps tend to load up very quickly and to feel very fluid and responsive during use.


Most HTML mobile frameworks, and a time delay on processing your taps. This is meant to detect a double-tap, but in reality it just makes your app seem lag. He as it ignores you for quarter of a second.

Check out the Fastclick library. This JavaScript file and one command, removes this time delay to make your apps seem more responsive. If you use this with jQuery Mobile, you'll probably want to use the .click() event instead of the .tap() event.

Local CSS & JS

You should really include all of your JavaScript and CSS files, as well as all other assets such as marker images, logos, etc. within the app, and not load them over the network.

If you do use remote URLs, you're actually loading over the network. This is slower than loading of them out of the apps own storage, relies upon the network being unavailable and sufficiently fast, and consumes network throughput and battery power that might better be spent elsewhere. It also slows down the startup time of your app, since the app won't really get started until it has downloaded the requisite files.

Just don't do it.

Minifying CSS and JS

Unlike a networked web browser on your PC, Cordova does not need to download the CSS and JavaScript files. And if your app is written loading CSS and JavaScript files over the network, you should definitely look at that and fix it!

As such, minifying or compressing these files does not make any sense. It may make your resulting app a few kilobytes smaller, but that really is irrelevant compared to the multi-megabyte size of even small apps. Balance that questionable gain against the overhead of compressing these files, and I find that it's totally not worthwhile.

Put <script> tags at the bottom of your HTML

With some specific recent applications that were rather intensive, I hit upon an interesting condition. When running the app on my iPad, it would fail to load - the framework would load up, HTML would display and style, ... then nothing. This would never happen. When I run it under an emulator, nor on older/slower devices, and never if I put in a blocking time delay such as a alert() call to slow it down.

Ultimately, the workaround was simply to move all of the script tags down to the bottom of my index.html file. This seems to affect the loading sequence in some way, as to avoid some sort of race condition in my iPad, but I couldn't characterize. Strange but true.

Downloaded Files and iCloud

If your app downloads and stores any files, such as map tiles for off-line use, or a JSON file database, then your app probably will not be accepted into the iOS App Store. This is because of a term, that apps may only store data specifically generated by the user, such as documents. It goes on to state that files that are automatically downloaded for off-line use, such as the map tiles and JSON database file, must be tagged, so as not to be backed up by iCloud.
Any directory or file that you create within your own code, you must use the setMetadata() call to tag it for not being backed up. This is done as follows:
file.setMetadata(null, null, { "":1}); 
As you test your app, go into your iPads backup settings, and check the iCloud usage for your app. There will be a minimum of about 100 kB, for metadata files and the like, and that is acceptable. But if you see it storing more than that, look closer.

Low Ceilings

A high-end modern smart phone, can have 2 GB of RAM and two CPUs. But go back only two years, and things change somewhat. While an iPhone 5 can readily handle 150 relatively complicated trails being loaded from GeoJSON and laid out onto a Leaflet map as vectors, an iPhone 4S will crash the app trying.

It's important not to go overboard. Seemingly-small enhancements such as adding a glow effect, do cost CPU time and make rendering slower. Downloading a JSON database with thousands of records may not be a problem, but drawing all thousands of markers onto the map could be a problem same as on a PC... but perhaps with a lower ceiling that you don't notice when you do that very same data set on a PC.

The moral of the story, is simply to keep in mind that not everybody has a fancy cell phone like yours, and that you should be testing on lower-and hardware and emulators as well.

No comments:

Post a Comment