Web Runtime APIs

Back in the days when J2ME was the mobile development platform of choice, there was a lot of both ridicule and concern about how fragmented J2ME was. Pundits claimed that with the second coming of the Mobile Web all those problems would be over, and developers would live happily ever after in a world of True Internet Bliss. I wish it was true, I really do. But apparently it's not easy to agree on standards when all players struggle to differentiate from each other.

The current state of affairs is that everybody+dog is cooking their own solution. Here is a brief overview:

Nokia Web Runtime

Nokia was early with a plug-in for the Nokia WebKit browser that basically gave access to battery and signal strength. With S60 5.0, launched recently with the Nokia 5800 "Tube", Nokia introduced WRT 1.1:

AppManager Service API	Access and launch applications on a device
Calendar Service API	Access and manage calendar information
Contacts Service API	Access and manage information about contacts
Landmarks Service API	Access and manage information about landmarks
Logging Service API	Access device logging events
Location Service API	Access device location information and perform location-based calculations
Media Management Service API	Access information about media files stored on a device
Messaging Service API	Send, retrieve, and manage messages such as SMS and MMS
Sensors Service API	Access data from the physical sensors of a device
SystemInfo Service API of WRT 1.1	Access and modify system information on a device
SystemInfo Service API of WRT 1.0	Access system information and control certain device features

Motorola WebUI

Motorola WebUI runs on Motorola Linux devices with the first handset, MOTO VE66 scheduled to be out before Christmas. Here is the API's:

File system API	Read and write access to files in the file system
Location API	Information about the device’s location
Contacts API	Access to contacts database and native contact list picker UI
Calendar API	Access to calendar entries
Internationalization API	Language translation and language change notifications
Application launching API	Launching other applications and UI services
Event subsystem API	Subscribing to system events; publishing and subscribing to non-system events
System API	System settings and status information
Soft key management API	Getting or setting the soft keys and receiving notification when they are pressed
Media Finder API	Searching for files based on metadata tags
Download API	Downloading and storing files

ACCESS NetFront

With the announcement of NetFront version 3.5, ACCESS, who makes the Sony Ericsson browser, introduced a device API. I haven't seen the specs anywhere, but ACCESS says:

"DirectConnect, ACCESS' ECMAScript-driven interface, enables the creation of a entirely new class of applications which combine Web 2.0 services with device-resident capabilities. Such capabilities include location using GPS and other positioning methods, access to local content stored in the address book and calendar, sharing of music, pictures and movies made accessible by DLNA (Digital Living Network Alliance) technology, etc."

BONDI/W3C

BONDI is an attempt by OMTP bring order. To define a common set of interfaces for access to handset capabilities. BONDI will submit their work to W3C in order to establish an industry standard. Details will be finalized by years end and a reference implementation is in the works. Too late?

Telephony API	Place calls
Communication Log API	Access the call log
PIM API	Access contacts, calendar, task and notes
Messaging API	Send SMS, MMS and email messages
Media Gallery API	Store and retrieve media files
Persistent Data Storage API	Access persistent storage
Location API	Access location info
Application Invocation API	Launch native applications
Phone Status API	Access device status for battery level, network connection, orientation etc.
Camera API	Access the Microphone and Camera functions

Others

Microsoft will introduce a "RIA framework" in an "upcoming version" of Windows Mobile. Their strategy seems to be Silverlight, but it would make sense to support AJAX based applications as well. No?

The iPhone does not currently expose any device capabilities through the browser. What their plans are is anyone's guess. With the success of the AppStore, they are probably not in a hurry.

The BlackBerry recently added support for AJAX and exposes a location object that lets you access the GPS from the browser. It also has some nice push features, but no other capabilities through the browser.

The first Android device, G1, features Google Gears. Gears gives access to location plus local storage. In theory anyone could write a browser plugin to expose most any phone feature, that goes for S60 and iPhone as well as Android. The only problem is that there is no friendly way to the the plugin onto the phones.

Doom or gloom?

None of the above API's are compatible. Not only are the methods different and located in different classes, the capabilities are only partly overlapping. The security mechanisms are different, with different policies and different certificates.

Standardisation efforts notwithstanding, this emerging chaos probably has to be solved through technology. Somewhere in here, there is a business opportunity for an enterprising developer.

Comments

[Tom]

Tom said...

Fortunately Motorola have canned the MAGX Linux platform, so we can hopefully safely ignore their attempt...

You're absolutely right though, expecting everything to be better the next time round is a triumph of hope over experience and also ignores the many other areas where fragmentation still occurs like screen sizes, input mechanisms etc which all affect the UI.