Browsers versus apps...

Currently, the architecture of the two approaches is very different. With apps, all the processing logic is on the device. With browsers, especially WAP ones, only display logic is on the device - the business logic is on the server. Whilst it is tempting to think that a fast and reliable link between the client and server does away with difference, that is not the case. Apps are based around programming languages, whilst browser services are built around mark-up languages for historical reasons i.e. browsers are originally built around a document-centric model, not an app-centric model. Actually, "application" in an increasingly generic term that can cover web and embedded use cases, but let's use it in its historical sense.

The efforts of the Web Application 1.0 group recognises the limitations of the docu-centric model and are trying to introduce features into the web world that allow a richer app-centric set of use cases to be realised in the browser model. This work is the driving force behind the Opera Platform.

Now, let's not forget the main concern that the Web world has always been interested in, although we tend to forget it, which is the portability problem, which has been quite rightly pointed out is the thorn in the side of MIDP programmers. A browser is a universal client - one client for many services (i.e. Amazon, Google, etc.). This has never been the case with apps, where there is really one app per service (Excel for spreadsheets, Word for docs, etc.)

To do some really interesting stuff with mobiles, eventually one has to start playing around with the kinds of enabling services and user data that are currently tied very tightly to the device, such as the phone itself (i.e. "telephony API"), the phone book, the text messages and the "messaging API" itself, the call records, the SIM card, the calendar, the Bluetooth stack, the media player, the file system and so on.

Until now, these embedded services have been of interest to the traditional apps community, who concern themselves mostly with APIs. The browser community has not taken much notice of this, except with some vague ideas or proprietary solutions here and there.

The Opera Platform is concerned with these embedded services and has sought to abstract the native APIs from the browser via a set of Javascript APIs via an extended Document Object Model (DOM), which is perhaps now a misnoma and should be renamed POM - Phone Object Model (although people don't know what to call these personal devices anymore - see other threads in this forum).

Now, there is a bit of slight of hand with what Opera are doing, because whilst they are correctly claiming "open standards" approach - by which they mean ECMAscript, XHTML, CSS and Web Application 1.0 generally, an app programmed in this environment will only run on the Opera Platform, which is obviously what they want.

Even if this effort by Opera become successful, whether through their own efforts or by other players (because there must surely be a response, and I don't believe Opera has gone far enough yet to embrace "next gen" mobile use cases) - the progamming model is still not rich enough to support some apps like games, although it could, in principle, be made rich enough via other "open standards" that could address the rendering issues that are at the heart of any game app.

My prediction is that something like Opera platform will become standard across devices and wilfully so, as the operators eventually will seek to enforce a single "standard platform" (of course, there will always be more than one, but not the "hundreds" of variants that plague MIDP implementation). The increasing size of trans-national operators will allow this to become a reality. Operators aren't really there yet because their revenue models aren't centered upon apps, so resources simply aren't focussed on this issue.

Buy my book (Amazon US/UK)
Join my email list
Subscribe to my "100 Mobile Product Ideas" free e-book