Mobile App Journey - Part IV

Once you have a an editor and testing environment, you can write much of your mobile app without any regard to PG.  This article will not attempt to teach you HTML, javascript, or CSS.  Nor will it attempt to teach you how to call a web service and retrieve data.  I will show you certain things I did, which may or may not be "best practices".  I will show you how I got my idea on Google Play using HJC and PGB and how I handled various issues.

Disclaimer:  Much of what I share is not my own invention, nor is it meant to be the only or best way.  I'm just trying to recount how I got from "nowhere" to an app that doesn't crash. :-)

Phonegap.js

Earlier I asked you to ignore this file in Index.html.  When using PGB you don't actually need the physical file but you do need to reference it in your .html files.  PGB needs to see the reference to it in order to do its build properly.  I tried having it only in Index.html, but then I couldn't get PhoneGap functions to work on other pages, so I added it to each page.  I don't know if this is optimum or correct.

PG has an API, which allows you to communicate with the device itself.  But, it's important that you do not call the API until PG has finished loading on that page!  The PG deviceready event will fire when PG has finished loading.  For example, you wouldn't check navigator.connection.type until after PG was done loading.

While there is code that may need to be called in the user function called by the deviceready event, you can call PG API code outside of the user function if you do it properly.  Sometimes you are testing on your desktop, perhaps using Chrome + Ripple, so there is no PG loaded as PG is only "alive" inside a real PG build, on a device.

You may want to leverage native device behavior when it's available because it may just look better than javascript.

Take the beloved javascript alert() function for example (I think I ripped off a variation of this routine from Ray Camden):

Rather than calling javascript alert(), we call the user function showAlert() with a message and an optional title as parameters.  if (navigator.notification) looks for the existence of PG's API.  Either it hasn't been loaded yet or it won't be because we are running in desktop mode or the device doesn't support it.  If the API doesn't exist on our page we fall back on the good old alert().  Otherwise we call the device's native version of "alert", courtesy of PG's navigator.notification.alert, which will probably look more, um, 'native-like' and polished than the javascript alert().

I guess the moral is that I did not do any interaction with deviceready here -- since normally PG will be loaded by the time the user does something, and I check for PG's "existence" first, and finally I have the javascript alert() as my fallback.

But there are times that you will want to execute code when the page loads that does involve the PG API, and for that you'd better put that code into the function you have deviceready calling.

to be continued...