Fragmentation also exists in browsers, especially for rich sites. Any major brand will usually test their site on the leading handsets within each target country.

As far as I know, fragmentation in J2ME, or more specifically MIDP and its various add-on APIs is usually an artefact of the API implementation to the underlying native APIs. After all, this is how J2ME works.

The bottom line is that the industry is a mobile *telephony* one with some general purpose computing APIs tagged on the side, with the exception of ground-up mobile operating systems. Hence, overall, the ecosystem isn’t really in place to ensure a reliable, robust and consistent mobile *computing* ecosystem.

Mobile handsets are not designed, sold or bought whatsoever on the basis of how well they implement MIDP. Within that context, it remains a messy business, but the technology is still solid in my opinion.

Another critical issue is the lack of after-sales upgrades and fixes. This is actually what tends to iron out a lot of issues in the computing world. This is why we can find handsets of the same model and make displaying different MIDP behaviours – the underlying firmware was “fixed” or “tweeked” from one to the other.

Currently we are building ‘hybrid’ apps that attempt to dance around the difficulties of both browser and on-device applications and provide the user with a cogent and satisfying experience.

The J2ME app will not require continuous (or even any) data access from the phone, but will obviously be restricted to the handsets it runs on (though as little as possible) compared to the mobile web app.

The mobile web app will retain all the functionality, with as similar a UI as possible, and hit most phones out there through use of WURFL and it’s WALL page adapter, but it will require a data access plan of some sort on the phone of course.

By doing both, I hope to offer the app to more users, who can pick which one suits them best. Given the limited functionality required for this app, the user experience is actually very similar on both platforms.

Alex
CEO
phonething.com

Though you do need to still support a few different client versions for X flavours of J2ME and Symbian, and then also learn about how different mobile browsers render your mobile web content.

I’ve been working at Bluepulse recently and they put it nicely (I think it was Heidi who coined it) when they say that mobile phones are like snowflakes: at arm’s length they look pretty similar, but up close, they’re all very different.

Bluepulse is seeing good adoption through having the whole product feature set available and rendered well on a broad range of browsers. But what’s key is having the *whole* product experience functional in the browser, not just a subset of features seen on the J2ME client or the desktop browser version.

It still amazes me how many “mobile” apps ask you to go to a desktop computer to sign in and create an account. Can you imagine how slowly Hotmail would have grown if when you visited the site for the first time, it said, “now go to your daily newspaper, cut out, complete and send in the coupon you find there and we’ll send your login details in the mail”?