Programming the Mobile Web : Widgets and Offline Webapps - Standards

The standards in this area are still emerging, but we can identify some official and de facto standards in the mobile widget world.

1. Packaging and Configuration Standards

First, for packaging and for the configuration file, the W3C has the Widget Packaging and Configuration standard, defined at http://www.w3.org/TR/widgets (not only for mobile widgets). The W3C standard defines a ZIP file as the package format, with a configuration file and an optional icon included in the root folder of the package.

The configuration file must be named config.xml. Here’s a sample file:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns="http://www.w3.org/ns/widgets"
        id="http://mobilexweb.com/widget">
    <name short="Example 2.0">
        The example Widget!
    </name>
    <description>
        A sample widget to demonstrate some of the possibilities.
    </description>
    <icon src="icons/example.png"/>
    <content src="myWidget.html"/>
</widget>

The other de facto standard is the Apple Dashboard Widget, used for Mac OS X widget development. It also uses a ZIP file, and a property list file (info.plist) is used for configuration.

The property list format stores serialized objects in a file with a .plist extension. The contents are in XML format, but without the typical XML tag usage.

In a property file, objects are stored along with their properties. Each property can be a string, a number, a Boolean, an array, a key/value dictionary, or some other type, depending on the system. For each property, we define the name as one key tag and the value as another tag, depending on the type. For example:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
    <dict>
        <key>Numeric Property</key>
        <integer>2010</integer>

        <key>String Property</key>
        <string>Value</string>

        <key>Boolean Property</key>
        <true/>
    </dict>
</plist>

2. Platform Access

For mobile platform access standards, we have already talked about HTML 5, Google Gears, and the W3C Geolocation API. To that list, we can add the BONDI standard, the de facto PhoneGap standard, and a proposed standard by Nokia called Nokia Platform Services.

2.1. BONDI

BONDI (http://bondi.omtp.org ) is a standard for mobile platform access from JavaScript including security policies defined and published by the Open Mobile Terminal Platform (OMTP) organization, now taken into the Wholesale Applications Community (WAC) and integrated with JIL and GSMA OneAPI. BONDI is supported by many companies, including ACCESS (NetFront), Myriad (Openwave), Sony Ericsson, LG, Opera, T-Mobile, Orange, and Vodafone. It supports access from a widget or even the browser.

Devices supporting the BONDI platform for widget development began entering the market in 2010. At the time of this writing there are two versions of the standard, 1.0 and 1.1, and the full API can be found on the website.

An open source independent SDK provided by the LiMo foundation is available at http://bondisdk.limofoundation.org , and every vendor should provide its own SDK (like LG, as we will see in the following pages). The LiMo SDK is Eclipse-based and includes a Phone View with some kind of BONDI emulator, as well as an incorporated debugger. This SDK also includes a debugger for testing WRT-based widgets (the Symbian format).

Note:

Remember that mobile widgets are just like any other HTML, CSS, and JavaScript code. We can even create something like a product catalog or a small data application that synchronizes with the server using Ajax without using any special API.

A BONDI widget is a ZIP package following the W3C widget standard, so it includes a config.xml file, a startup HTML file, and all the required resources. In order to be recognized as a BONDI widget, the ZIP file extension must be changed to .wgt and the file must be served as application/widget.

The API defined in the 1.0 and 1.1 standards manages all functionality with a bondi global object that is available in compatible devices. It includes the modules described in Table 1 . You can access a module if you define it in the feature tag of the config.xml file. This is to allow the user to know what features you will use when installing the widget.

Table 1. BONDI widget modules
Module name	Module object	Allows us to...
Application Launcher	bondi.applauncher	Launch any application installed, including standard ones (browser, email, phone, SMS, or media player)
Messaging	bondi.messaging	Send SMS, MMS, and email messages
User Interaction	bondi.ui	Define navigation mechanisms, configure soft keys and native menus, access effects (vibration, sounds, and lights), change the orientation, and fire some application events
File System	bondi.filesystem	Browse and manage files in known folders (documents, images, videos) or in any path in local or external memory
Gallery	bondi.gallery	Access media files on the device
Device Status	bondi.devicestatus	Access properties of the device
Application Configuration	bondi.appconfig	Change and read application settings defined by the developer
Geolocation	location	Implement the W3C Geolocation API
Camera	bondi.camera	Access video recording and photo snapshot capabilities
Communication Log	bondi.commlog	Access the list of recent messages and calls
Contact	bondi.contact	Access the SIM card and stored phone contacts
Calendar	bondi.pim.calendar	Access the device’s calendars
Task	bondi.pim.task	Access the device’s tasks list

Many methods support event listeners and JSON-style object parameters.

For example, the JavaScript code for sending an email with attachments taken from the filesystem from a BONDI widget would look like this:

<script type="text/javascript">
function send() {

  var file=bondi.filesystem.resolve("/Photo.jpg");
  var email = bondi.messaging.createEmail({
      from: "[email protected]",
      to: document.getElementById("email"),
      subject: "Sent from a widget",
      body: "Hi! This is our message from a widget with an attachment",
      attachments: file
  });
  bondi.messaging.sendEmail(function() {
        // Sent handler
        alert('Your message was sent');
  }, function() {
        // Error handler
  }, email);
}

Note:

For testing purposes, you can download a widget from the BONDI Reference Implementation, a Windows Mobile 6.x official implementation. You can also download testing SDKs and emulators for other vendors, such as LG.

The BONDI JavaScript API should also work in the future on normal browser-based websites, but we may first ask for permission using bondi.requestFeature(success_callback, error_callback, module_name). The browser usage is not yet implemented on any platform.

At the time of this writing LG, Samsung, and Sony Ericsson are starting to support BONDI widgets. There are also some wrappers and open source projects to make them work on Symbian, Android, and other devices.

2.2. PhoneGap

If you know about PhoneGap, you may wonder why I am talking about it here, in the API standards section. PhoneGap (http://www.phonegap.com ) is an open source framework for creating mobile web applications in HTML and JavaScript while still taking advantage of the core features of native applications in some platforms. It is becoming a de facto standard for iPhone, Android, and BlackBerry devices and is entering into the webOS, Symbian, Maemo, and Windows Mobile world.

Note:

Other similar projects are RhoMobile (http://rhomobile.com) and Titanium Mobile (http://appcelerator.com).

PhoneGap has two main features:

A JavaScript API for usage in our code
The ability to embed our web applications in native projects

PhoneGap applications are native applications that open a full-screen embedded browser with our mobile web code running inside. This framework provides a bridge between JavaScript and the native runtime, providing support for additional features not available in JavaScript.

Note:

You can create PhoneGap-like projects easily for every platform by using the web browser control that each platform offers in its native environment, and opening your HTML code inside. The disadvantage of not using PhoneGap is that you will not have access to any mobile-specific JavaScript APIs.

PhoneGap supports several new JavaScript native objects when you are running inside a PhoneGap project. The objects are listed in Table 2.

Table 2. PhoneGap native objects
Object	Description
Geolocation	Provides similar functionality to the W3C Geolocation API
Accelerometer	Provides listeners for the accelerometer
Camera	Provides access to the camera
Notification	Provides access to sound, vibrate, and other notification options
Contacts	Allows you to manage contacts from the user’s agenda
File	Enables you to read, write, and manage files on the filesystem
SMS	Lets you send SMS messages
Phone	Lets you make a call
Maps	Allows you to open a map
Audio	Allows you to record and play audio files
Settings	Gets information about the device
HTTP	Makes a GET request to an URL

For example, to take a picture we will use a code similar to this:

function takePicture() {
   navigator.camera.getPicture(function(image) {
      // This function is called with the picture data in base64 format
      document.getElementById("img").src="data:image/base64;" + image;
   }, null, {quality: 8});
}

2.3. Nokia Platform Services 2.0

Nokia has developed its own standard based on the Symbian WRT widget engine, which we will look at in the next section. This standard is an easy-to-use JavaScript API for accessing device services and is intended to be a future standard for many other vendors.

2.4. Apple Dashboard

Apple Dashboard, as one of the first widget engines for desktops, is the de facto standard for a global widget object in JavaScript. The most widely compatible methods are openURL, for opening the browser, and the persistent storage methods preferenceForKey and setPreferenceForKey, which we will cover later.