If you are thinking of writing (or having an app written) that works on a wide range of smartphones including Android, Blackberry OS5/6/7, Nokia S60 and iOS then there are some issues that you need to resolve.

First off it is tempting to write one application in HTML, Javascript and CSS for all the platforms. Here are some of the issues you will find:

• Must work offline. >appCache solves that – but it’s not available on Blackberry OS5 nor S60.
• Must store data locally. localStorage solves that but again not available on OS5 / S60.
• Handle GPS data. Different support on different browsers and no accuracy on S60.
• Check Online status. Android 2.1 provides a call but it always returns true.
• Must do Cross Domain Ajax calls – restricted on all platforms

You will also need to convert your web page into an app for each platform, test it and make sure that users are aware of new releases.

 If you want to make an app that pushes data to the phone rather than poll for changes then you have even more limited options – Apple and Blackberry offer their own proprietary push mechanisms while Android and S60 don’t. Apple push messages are very limited in length and you don’t know whether they have been delivered. If you try and send data from a device that is coming and going out of data coverage then you have no knowledge of whether data has actually been sent – it may be held in the operating system’s buffers or it may have been lost.

The Mercury framework solves all these issues. A standard Mercury login is downloaded to the phone. This authorises a user and indicates the name(s) of the web-based application to be run. The web pages are loaded and saved for offline use – subsequent logins simply check if there have been any changes, so updates are immediate. New apps can be rolled out by simply adding a new URL to be loaded.

The web page that is loaded has access to the Mercury communication library. The initialisation causes the device to listen for new messages. A new data record is inserted into the Mercury server via a simple POST, and your Javascript code on the mobile is called when that data is delivered into memory (and saved in local storage). When your Javascript code changes any stored data the change is automatically reflected back to the copy on the Mercury server, from where events are fired to any existing business process.

The Mercury library contains extensive support for workflow applications. A workflow editor is provided that can be used to design workflows, creating steps and handling reporting back at each step. Calls to move to a specific step are available, commonly attached to a button in the HTML that displays the data from the job to the user.