Google claims HTML5 on the web is the future of applications on mobiles and they present the high-end mobile version of Gmail (on iPhone and Android) as an example of what can be achieved with web-based applications. But, as I wrote earlier, the Android-browser does not support HTML5’s webdb, appcache or geolocation at all (and neither does Google Chrome). Instead Google offers similar (but different) functionality in their Gears-plugin.
Almost the same functionality, but with a different API, how did they implement mobile Gmail? Well, Appcache (a.k.a. “offline web application”) seems to be implemented separately. That makes sense as defining which files can be stored locally is more or less a one-off job. But for more complex data-oriented offlining with a local database, Google created a wrapper-script that hides the Gears and HTML5-API’s and the underlying differences, thus offering a unified way to store and retrieve information from a local db. The code, including an example, can be found in WSPL’s svn-repository in Google Code.
And while it’s not used (or needed) in gmail, there also is a a geolocation-wrapper to abstract those HTML5 and Gears-implementations. Once the wrapper is instantiated, getting the user’s location on iPhone (OS3), Android and some others becomes as easy as doing:
geo_position_js.getCurrentPosition(success_callback,error_callback);
Great stuff, those wrappers. But wouldn’t it be even greater if Google’s browsers would support the native html5-specs, so these stopgap solutions weren’t needed to start with?