I am currently doing some research in which directions applications on mobile devices will develop in the future. The following post on offline web applications on mobile devices has been inspired by a blog entry on Ajit Jaokars OpenGardens blog.
On the desktop, many web browser based JavaScript applications exist today with well designed user interfaces and connectivity to services and databases on the web. Web based applications such as GMail (email reader), Bloglines (blog reader), Writley (text processor), etc. are now even taking over some of the functionality of locally installed programs. On mobile devices, this trend is not yet wide spread. In my opinion, there are a number of reasons for this:
- Web browsers on mobile devices need to become AJAX capable. This is well underway and in the mid-term its likely that most mobile devices will include such a browser. As JavaScript and the functions for asynchronous communication with the web server are standardized, developers can design applications which will work over a wide variety of mobile devices. This is an important key to success as services which only work on a limited number of mobile devices are unlikely to be successful as they will be unable to attract a sufficiently large user base.
- Web applications need to work even if the network is not available. This is crucial for applications such as calendars, address books, etc., which have to be accessible at any time and any place.
- Some applications should also be able to get access to the resources of the device which is important for applications used for uploading information such as pictures to the web or use the device’s built in GPS device to get the current position to be able to deliver information relevant to the user’s current location.
With the traditional server/browser approach these things are not possible. If the connection to the network is lost, web applications can not be loaded onto the device from the web server and user input can not be sent back to the web. A number of different initiatives have thus started to address these shortcomings.
Google Gears
Google’s approach is based on a web browser plugin which offers JavaScript applications on web pages an API to store pages locally. Furthermore, the plugin allows applications to store data locally. When the page is accessed when the device is not connected to the network, the local copy of the web page including the JavaScript program is used instead. The Gears plugin extends a web browser with the following functionality:
- A local server which feeds the web browser with web pages which have been stored in the local cache in case the device is used in offline mode.
- A relational database in which JavaScript applications on web pages can store information. To stay with the example above, a calendar application could hold a copy of the user’s calendar entries which are synchronized with the calendar entries in the web when the device is online and the application is used.
- As synchronizing the local and remote data depository after going online could take considerable time it is important that such activities do not block the execution of the JavaScript application on the web page. Thus, the Gears API contains a ‘WorkerPool’ which allows executing JavaScript code in the background.
At the beginning of 2008, Google Gears is only available for desktop based browsers as it depends on a web browser plugin interface which is not yet available in any mobile browser. As the software is available as open source under a BSD license the way is free for mobile browser developers to include it in future versions of their products. While Google Gears enables web applications to run offline, there is not yet an extension which also allows web applications to use local resources (e.g. access to the file system, getting network information, GPS information, etc.).
Nokia S60 Web Widgets
Nokia’s vision for local web applications on mobile devices are widgets. Unlike Google Gear’s approach a widget is not executed inside the web browser. Instead, it just uses the web browser’s core as a runtime environment and otherwise looks like a native application. Widgets can even have their own icon that appears along local applications in application menus of the device. Not running in the user interface of the web browser but instead having the full screen available has a number of advantages. From the user’s point of view the program can be started and controlled just like local applications. When the widget is started by clicking on the icon in the program list, the web browser core is loaded and the JavaScript and HTML page which the JavaScript application can modify is shown on the screen just as a local application.
The first version of the web widgets packet does not offer local storage to applications which limits its use to times when the device is connected to the network in case data needs to be stored between invocations of the widget. Also, there are no interfaces at the moment to get other data from the device such as calendar entries, address book access, etc. Widgets do have access, however, to system information such as the current battery power level, network properties such as signal strength and network name, display light control, vibration control, speaker control, memory properties, etc.
HTML-5
For version 5 of the Hypertext Markup Language (HTML) the World Wide Web Consortium (W3C) is specifying tools to make web pages and embedded JavaScript applications available offline. The approach taken by the W3C is very similar to Google Gears and also features offline caching of web pages and a data repository for JavaScript applications to store data locally. There are two ways of storing data locally. For simple data structures, data can be stored in name/value pairs. For more complex data, JavaScript applications can use a SQL database with standardized functions to query, insert, change and delete data. The advantage over Google Gears is that once the standardization of HTML-5 is finalized, browsers can natively support offline web applications and a plugin like for Google Gears is no longer required.
That’s it for a first overview. In a future post I’ll take a look at data synchronization between the network database and the local cache, why and how some applications should be able to access local data beyond the cache and the security and privacy implications of local web applications.
As always, comments are welcome.