Setting the scene

Early attempts at bringing the Internet experience to the mobile phone were dependent on microbrowser technologies such as WAP that compensated for the lack of capability in contemporaneous devices, and the low bandwidth and high latency of the GPRS networks at the time.

This situation is now changing with leading browsers from the likes of S60, Opera, Access and Apple supporting many of the Web technologies used in the desktop space today.

The diagram opposite illustrates in broad terms the architecture of a modern mobile browser:

The browser is effectively composed of three elements:

1. A rendering engine that displays and formats content using standard Web technologies such as xHTML (defining the Web page content), CSS (page styling) and SVG (scalable vector graphics).
2. A script engine (JavaScript) that provides a means of executing simple logic that defines the function of the Web page.
3. Support for the XMLHttpRequest (XHR) method that enables script within the page to asynchronously request new information (XML data) in the background hence making the Web page seem more responsive and interactive.

This combination of technologies, and in particular the practise of using the XHR method to update the contents of a page forms the basis of AJAX, an approach increasingly being used by many of the Web 2.0 services today.

In fact, many such services now only ever load a single page, all other user interactions and presentation of information being achieved through AJAX.

This approach is especially attractive on a mobile phone where inherent network latencies can create a sluggish user experience when downloading full pages.

For those Web services that are accessed frequently, the logical extension of this concept is simply to cache all of the graphical assets and program logic associated with the service and only use the mobile connection for refreshing the content – presenting a weather bulletin would then simply be a case of retrieving the base information and then displaying the correct icons (sunny, cloudy etc.).

What is needed therefore is a way of utilising the browser framework to support client-side Web applications – this is what’s known as a Web Runtime.

In a Web Runtime, the core functionality of the browser (i.e., the rendering engine and the scripting engine) are architecturally extracted from the browser to become a common resource that can be shared between the browser (as a client application) and any other Web application that wishes to use it.

To a certain extent, a good example of a Web Runtime is something like WebKit which forms the core of both the Apple Safari and S60 browser frameworks (although a Web Runtime also requires a few additional components such as an Application Management System).

Benefits of Web Runtimes

By leveraging Web technologies, a Web Runtime offers a number of significant additional benefits for application development on mobile phones:

• Makes the mobile phone accessible to a much wider developer base
• Reduces development time to a matter of days rather than months
• Decouples development from platform differences hence minimising porting issues & costs
• Allows dynamic update of the application to changes in the environment & user needs
  

For these reasons, the Web Runtime will become a catalyst in driving innovation on mobile phones.

But perhaps most interesting are the opportunities it presents for delivering new ways of accessing the Web and evolving Web experiences beyond the browser.

Widgets, in particular present a much easier mechanism for a user to access their favourite content on the Web without having to fire up the browser, and either navigate to a bookmark or enter a search string; an important point given the user interface constraints of a typical mobile phone.

Device APIs

The next step is to open up device APIs to the Web Runtime thereby enabling Widgets to start mixing up both local data and information from the Web to generate a range of interesting 'mashup' services, or simply to make services more personal.

For instance, the weather Widget would now be able to deliver a forecast based on the user's actual location. Other examples include displaying a map based on a contact’s address or setting up a call by clicking on a Web advert within the Widget.

A range of device APIs could be opened up including file system access, PIM data, messaging, call handling, camera and system data; in fact there are no technical barriers to opening up everything, the issue is one of security: safeguarding the privacy of the user’s data and preventing malicious attacks.

From an architectural perspective, the Web Runtime would need to be extended to provide a binding between the JavaScript engine and the underlying application APIs provided by the native platform1.

¹ A specification and prototype have already been developed by VF Group R&D and is being socialised as an industry standard through the OpenAjax Alliance