This blogger has moved! |
I want to invite you to my new gig over at Rift Labs. We are devloping Open Source Hardware for photographers. Come join us if you are into UX, design or photography at some level. Visit Rift Labs |
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.
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.
Posted by: Tom | November 28, 2008 at 10:10