What mobile AJAX can learn from the fragmentation of Java Me

By Paddy Byers

paddy_post.JPG

Edited by Ajit Jaokar

ajit.JPG

As we have seen from previous posts in this blog about Mobile Ajax, Mobile AJAX has a lot of potential. However, many questions still remain about the details of how Mobile AJAX could be implemented and exploited.

Specifically, this post discusses the problems that occurred in the evolution of Java ME (formerly called J2ME) and how Mobile Ajax and other browser technologies can learn from them; both in terms of the browser platform itself, and the associated developer ecosystem.

I’d welcome discussion on how to resolve the issues that are raised.

Mobile apps aren’t just about interactivity

Many inherent advantages of browser-based solutions have been articulated clearly in the preceding posts, and AJAX gives a dramatically superior level of interactivity than was possible with conventional XHTML; but the truth is that AJAX has only just improved interactivity to the point that it is good enough to be a credible experience (assuming services are targeting a typically specified feature phone and aiming for modest level of richness in visual experience). From the point of view of the interactivity enabled, AJAX could be likened to an early MIDP 1.0 Canvas-based application on a typical interpreted virtual machine.

The analogy with MIDP 1.0 doesn’t stop there.

The current mobile AJAX environment has many similarities with those early Java ME days: there are maturity issues (e.g. only one or two implementations, no common behavioural specification or precise API specification); ecosystem issues (eg a developer community naively believing that desktop implementation approaches will transfer seamlessly to mobile); and market issues (a broken value chain as it relates to the proliferation of technology enablers). The painful failure of early attempts to use Java ME as a service delivery platform should be a clear warning to the new generation of web 2.0 service providers aspiring to extend to mobile.

The key parallels, however, are in the level of platform integration offered.

Much of the mobile AJAX discussion has focussed on interactivity and connectivity aspects; but the problem is that the services that extend effectively to mobile will be those that successfully harness the mobile platform and its capabilities.

Some of these include SMS/MMS, multimedia capture, interactive multimedia playback, location, Bluetooth, etc. To implement these features, we require access to the platform i.e. device APIs.

Real mobile apps are not simply a thin projection of an interactive interface to a web-based application.

One of the main reasons for the failure of MIDP1.0 was that none of the key platform capabilities was exposed to the java programmer.

Many – nearly all – potential mobile applications, even if 99% implementable in Java ME, turned out not to be viable because of a critical dependency on some platform feature that simply wasn’t accessible in the Java ME environment.

The Java ME community realised this early on and sought to address it by extending the scope of the platform.

Unfortunately, this is where the problems really began.

Unilaterally defined APIs (in the case of MIDP1.0, this was primarily audio and security) were made by manufacturers and also by operators; and the community process later created formally standardised APIs.

Several years on we have platform APIs that have functionality gaps and are inconsistently implemented; further, there is no common policy for the deployment of APIs, either between operators, within a single operator, or even among the devices of individual manufacturers.

The resulting fragmented environment and ecosystem problems are well documented.

The key point is that Sun, to its credit, set out very deliberately to ensure that the java platform did not get fragmented and tried to put in place every technical, legal and commercial measure to implement its strategy – and it still failed.

Implementation interoperability must be addressed proactively

The current desktop browser market contains a small number of players with comparatively well-understood differences. Content authors can ensure that content is interoperable by coding directly to cater for those differences. Basic market dynamics force browser providers to fix problems and keep functionality in step with the market leaders.

The mobile browser market is different.

For one thing, it is still not following the full web browser standards. Also, there are multiple providers and already some fragmentation in respect of functionality; scripting interoperability is especially limited as a result of weak (or nonexistent) DOM implementations underlying many mobile browsers.

There are also few market pressures to correct this – operators are not (yet) mandating full browser functionality (such as AJAX); much of the functionality is not formally specified by W3C or another body; there are no independent conformance or interoperability tests.

Simply leaving this implementation interoperability issue to market forces to address will hinder mobile AJAX substantially. The operators have a position in which they could either improve or inhibit interoperability.

Possibly the worst of all outcomes is in fact the most likely, which is that a requirement to support XMLHttpRequest and certain scripting functionality is made mandatory, without the detailed technical specification and conformance backup needed for manufacturers to do it reliably; the result will be all manufacturers scrambling to incorporate weak but technically compliant implementations, stalling all efforts for genuinely functional and interoperable implementations.

This interoperability challenge should not be underestimated.

Contrast the browser environment with Java ME in which API specifications are developed under an open and formal process, there are tens of thousands of conformance tests, conformance is mandatory under the license terms for the technology, etc – and still interoperability is poor.

The definition of platform and extension APIs must be decentralised

The Java ME strategy is to define all APIs through an open, formal and consensual process which is centralised. When a requirement for a particular API is identified – location-based services, say – the various stakeholders (operator, device manufacturer, content developer, technology provider, etc) form an expert group to develop the API and associated resources and make it available to the industry. The aim, of course, is to avoid the fragmentary effects of there being multiple independent and competing APIs.

However, the centralised nature of this approach is one of its biggest problems.

First, consensus takes a long time and APIs arrive too late to be useful.

APIs become over-engineered because they not only have to meet the immediate need but also any other foreseeable future needs and edge cases – because once defined they can rarely be extended.

The process, in certain cases, also becomes mired in the competing technical and commercial agendas of expert group members; and the business model surrounding the resulting reference implementations and conformance test suites are problematic, which delays uptake, or stops it altogether.

Ironically, these issues then themselves become the cause of much fragmentation.

Due to cost and the risk of delay, manufacturers and operators do not incorporate new APIs unless there is a clear commercial need; and when they do, they all make different choices as to which capabilities to include.

Prior to standard APIs being available, operators and manufacturers still create private APIs, which must then be supported on an ongoing basis and contain a slightly different feature set from the standard so content cannot easily migrate to use a new API.

What’s needed is a decentralised process which allows platform owners and service providers to define and implement their own APIs.

Although at first sight this would appear to create fragmentation, it doesn’t provided that there’s also a way of writing and deploying libraries or wrappers that can implement one API on top of another.

It’s analogous to using WSDL to specify web services – there doesn’t need to be a centralised definition of any given API because the relationship between alternative APIs is explicit and users of those APIs can react by writing wrappers that implement one in terms of the other, or write their own higher level abstractions that can sit on top of either.

The proliferation of widgets in desktop web apps shows the power of this decentralised approach. The potential role of widgets in mobile web apps is something Ajit discusses extensively in his book.

How to make it happen?

None of these issues requires new technology – the industry has the capability to do all of it. But it will only happen if the market incentivises the relevant parties – the browser providers and device manufacturers – to make it happen. The operator, in principle, is sufficiently resourced and has sufficient control to do this – but so far the operator community doesn’t seem to have realised the significance of the opportunity, let alone confronted the issues that have to be resolved.

Comments

  1. Alex Russell says:

    hey Ajit,
    So I think the elephant in the room, from the perspective of web developers and browser vendors, is that the W3C needs to be rehabilitated or dispensed with. There’s a fundamental navigation issue (how do I get to my app/page quickly?) to be solved, and having a non-standard “widget” format can’t be the right answer. Also, making apps that are quick and can be used in the context of what users are doing or are trying to get done is a serious barrier given how little access to the hardware the browser are currently exposing. You’re point about web devs not getting that their current Ajax tools won’t transfer is entirely correct. Unfortunately there isn’t much else in mobile browsers that seeing enough invention/creativity to make a serious dent.
    Regards

  2. Veek the Vote 2006 (www.veekthevote.com), a project that enables people to use the cameras in their mobile phones to express themselves and document Election Day in near real-time.
    Veek The Vote represents something wholly new in the history of election coverage. Anyone with a mobile phone equipped with a camera-—there are over 70 million of them in the U.S.–can send a photo or video to vote@veeker.com. No registration is requried. No special software is needed.
    Fifteen to sixty seconds after a photo or video is sent, it will appear in a embedded player at veekthevote.com. This player, in turn, can be taken by anyone and embedded anywhere on the web: on blogs, MySpace pages, etc. Veek the Vote generates a completely open mobile video communication network, enabling complete democratization of election coverage. We take in video from anyone, and allow anyone to display it on their website.
    We’re very excited about the prospects for Veek the Vote. It empowers Americans to be more than a statistic captured by exit polls on Election Day. Whether they’re taking to the streets in protest, waiting patiently (or impatiently) in line at the polls, or stuck behind a desk, Veek the Vote 2006 lets America show and see Election Day in a way never before possible.
    Any help that you all might be able to give in helping us get this story out would be very much appreciated. The more people that know about Veek the Vote, the more powerful it will be.
    Please don’t hesitate to get in touch if you have any questions. I can be reached at: rraderman@veeker-corp.com
    Kindest regards,
    Rodger Raderman