Email, Group Calendar, Contacts, Instant Messaging, and File Storage

Zimbra on Ulitzer

Subscribe to Zimbra on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Zimbra on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Zimbra Authors: David Balaban, Louis Nauges, Kevin Benedict, RealWire News Distribution

Related Topics: RIA Developer's Journal, SOA & WOA Magazine, Java Developer Magazine, AJAX World RIA Conference, Zimbra on Ulitzer

RIA & Ajax: Article

Will "Mobile AJAX" Dominate Web 2.0?

Mobile AJAX Will Replace Both Java ME and XHTML, says Ajit Jaokar

Walled Gardens, Open Gardens in the Context of the Above Approach

Now, to my favorite topic – walled gardens and open gardens.

There are two types of walled gardens - firstly the extreme case - like '3' - which blocks access outside their sites completely - and there is not much you can do about that (but I don’t give that model a lot of time to survive either!)

However, the other case is an operator like Vodafone .

Vodafone live IS a walled garden(and I have no problems with that) BUT Vodafone itself places no restrictions to accessing the web from the browser.

The overall approach outlined above based on Ajax could be a way to overcome the walled gardens problem because the lowest common denominator shifts to the browser (and hence it is cross operator).

Indeed, current browser technology is also cross operator – but with the Ajax based approach as outlined above, for the first time, we have the opportunity to create compelling applications and have access to device APIs from the browser through the platform. Thus, this approach increases the target audience for any given application.

This means, if the browser experience is improved - we could write browser based apps for most operators- which could access a much larger user base

How Does This Approach Contrast with Java ME, Symbian, etc
The Ajax platform-led approach closes the gap between browser-based applications and downloaded applications. Thin client applications will always be impacted due to the need to remain connected in a mobile environment. But in spite of that, the user interface is improved, access to the device is possible – most importantly – the potential target audience increases and development cost decreases.

Ajaxhas better deployment models and leans more towards open source (since AJAX components are open-source). Java (MIDP) is more deployed and better specified (for now at least). Symbian/WinMobile offers more phone integration, but is not portable and completely proprietary. Adobe Flash is another interesting alternative, but unlike the other technologies has already proved to work with Ajax on the desktop. Hence it's an enhancer - and not only a competitor - to Ajax.

Mobile Gaming
In my previous article, I used the example of mobile gaming. I used porting price statistics from a source which I quoted in the article. Thomas Landspurg has been kind enough to send me updated statistics which he believes are more accurate.

According to Thomas, the price/binary (of porting) is around 300 to 600 (but most of the time between 500 to 600). But we have around 80 different binaries for 250 supported handsets, including the different languages.....But this is only for a single technology (typically Java) and a common version for this technology.

This does not include a Brew version for instance. One of the big cost factor is the support of MIDP1.0 handsets. Another view is that you can add from 100 to 150% to the development cost as porting costs. Again, this might change a lot depending of the game (2D/3D) the type of content, etc....

I am not an expert on gaming – and Thomas is. Hence, I am grateful for these stats. However, isn’t it a pity that mobile applications have been reduced to games/ entertainment in most cases? Where are the applications (i.e. useful mobile applications such as ‘find my nearest’ etc) – as opposed to games?

And as regards mobile games themselves, I am not the only one who feels that the current state of affairs is fundamentally broken. See for example the article Games elite tackle fragmentation.

At present, mobile games development is hamstrung by the fact that one game needs to be tweaked potentially hundreds of times for different handsets. These devices all implement Java differently and have a variety of screen sizes, keyboard lay-outs and user interfaces. The cost and time implications are enormous.

It's the 'hundreds of times' which is significant. A thriving industry undeniably exists in game porting .. so .. the basic principle is valid. If WORA (Write Once Run Anywhere) were true, it should be relatively cheap to ensure that the game runs across devices and across operators – but it’s not!. In fact, companies like babel media derive a significant part of their income from ensuring that mobile games conform to standards set by publishers and operators.

Finally, it’s critical that games developers have a viable business model – without which the industry can’t survive and there can be no innovation. This is especially true of small developers who need a viable per unit cost of development, access to distribution channels and the possibility to make a decent return(i.e. margins that they can build a business with). These factors are much more important than a pretty face (a ‘rich’ interface).

The browser model as outlined above provides the ability to overcome these issues which currently plague the gaming industry. Currently, we have a ‘rich’ interface at the expense of a revenue model. I believe that it’s not necessary to have a rich interface to develop a successful mobile game. In fact, successful games can be developed using very basic technology such as SMS. Increasingly, casual games are becoming significant .

Mobile gaming is different from console/PC gaming and applying concepts from PC/console gaming to mobile gaming(such as the necessity of a rich interface provided by native applications) – would be missing the point. It’s far more important to foster a revenue model and / or community – both of which are possible via the browser model.

Why Mobile Ajax Will Replace Both J2ME and XHTML as the Preferred Platform for Mobile Applications Development

This same headline got considerable attention when I used it i my last article. Let's put this statement in perspective: I said ‘replace as the preferred platform for mobile applications development’ – which is not the same as ‘it will replace’ – the operative words being ‘preferred platform’.

Let me elaborate more using an example. My first job, fresh out of college, was as a software developer. At college, we learnt C programming and UNIX. Our project team at my first job often had lunch together and the topic of conversation was often the same. It was started by the team leader, a veteran of many years of software development. He was obsessed about ‘Is AS400 the VAX killer or is VAX the AS400 killer?’ (In other words – which platform is better?) I would listen fascinated as technical arguments flowed back and forth.

When someone would care to listen to me, I would ask ‘What about Unix?’. ‘Oh – those are PC systems Ajit’ was the dismissive reply I often received – and off they would go on with AS400 vs. VAX.

Just a few years on – things have changed dramatically.

Both the VAX/VMS and the AS400 are still around, but by no means are the preferred modes of application development – in the sense that if you wanted to develop a new application you are unlikely to think of these as your first choice. However, note that they have not been ‘replaced’ by newer applications. Also, note that it's not a technology issue but rather a commercial issue.

In retrospect, the whole issue was like ‘Dodo vs. Dodo.’

Hopefully, this should clarify that I mean browsing Ajax will be the preferred mode of development and not the only mode of development.



I believe that if our industry has a patron saint – it should be Jerry Maguire (Show me the money!) . The revenue model is the key. Any technology or application that enables the players in the value chain to make money will thrive.

Ajax, Mobile Web 2.0 and widgets reduce time to market, encourage innovation and enable a larger target market. By potentially having the ability to develop for the web and the mobile browser at the same time, widgets offer a better value proposition to developers. If widgets can ‘call’ other widgets – powerful applications could be developed from simple components

The biggest factor in favour of Ajax today is the support of small application developers. Developers who stand to make money from widgets. Widgets which could potentially have a large target audience.

In mobile Ajax, Java ME has a credible option. While Java ME is looking to address some of these drawbacks – I believe that the momentum behind Ajax will lead to the emergence of a virtuous (and disruptive!) cycle which will cause Ajax based mobile applications be a credible alternative to Java ME.

Let me conclude with an observation. At forumoxford (Oxford university’s next generation mobile applications panel – which I chair) , Walter Adamson asked me this question ‘And who bought the last round of "browser only" PCs? No one, including you.’

That’s true. I didn’t buy a ‘browser only’ PC at that time. But the point is – NOW I would. Already, my e-mail, calendar and other applications are on the web. Using Web 2.0 applications like Writely , I can store all my documents on the web. All I need is a browser. One client to rule them all!

Thus, today I would use a ‘brower-only PC’ – would you? What does that say about mobile applications?

Image source for bowling image on page one:

More Stories By Ajit Jaokar

Ajit Jaokar is the author of the book 'Mobile Web 2.0' and is also a member of the Web2.0 workgroup. Currently, he plays an advisory role to a number of mobile start-ups in the UK and Scandinavia. He also works with the government and trade missions of a number of countries including South Korea and Ireland. He is a regular speaker at SYS-CON events including AJAXWorld Conference & Expo.

Comments (7)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.