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: "info@mobilexweb.com",
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.
