After two big announcements from Google, i.e. OpenSocial and Open Handset Alliance/Android .. I believe that the third missing announcement is Google gears on mobile. Google gears on mobile devices would solve a key problem for the Mobile Web and I have blogged about it’s potential almost as soon as the announcement was made.
With Android, Google has not gone RIA (Rich Internet Applications) but for a large measure, the rest of the world has already gone RIA for mobile browsers. If you accept that technologies like Mobile Ajax are now becoming mainstream just within two years after my now well publicised blog about the same topic Mobile web 2.0: AJAX for mobile devices – why mobile AJAX will replace both J2ME and XHTML as the preferred platform for mobile applications development – Part two , then it is indeed time to address offline browsing in tandem with Mobile Ajax.
The acceptance of common standards between the Web and the Mobile Web is a good thing and while Gears is not a ‘standard’ – it is open sourced – and it’s acceptance on the Web would definitely help to promote it on the Mobile Web. As far as I can see, the only other group/body addressing this problem is HTML5 and even those efforts appear to be mainly to be for the Web(and not the Mobile Web)
While I am a big fan of standards, W3C etc .. in this case, I think Google is leading the way. And if they do the same as they have done in case of Android(An alliance rather than ‘doing it Google’s way’) – then we have the potential of a truly interesting service.
The most logical way to implement Gears on browsers is through a plug-in such as the Netscape plug-in API followed by Mozilla, Opera and most major players(except Microsoft). I am a bit unsure about Mobile browser plugin standards(as opposed to Web browser plugin standards) but I hope to find out soon. Google may well opensource Gears on mobile just as it does on the Web creating a de-facto standard if one does not exist.
Soon, I see Mobile development to be dominated by two open source products: Google Gears and the OHA. And that is a good thing because it allows other players in the industry(including Operators, device manufacturers etc) to have a role.
For instance, If vendors like Nokia, Opera and others support Gears in their respective Rich Web browsers – then we have a good way to overcome the fragmentation issue that has ailed the industry from the outset . Furthermore, it is an alliance founded on the basis of Open source with each party playing to their respective strengths.
The one additional bit missing here is security .. as a study of Google Gears on the web demonstrates. The implementation of Google gears on the Web gives some clues of the issues involved and we can expect the same issues on Mobile devices(plus security and device APIs unique to mobile devices)
As per the Google gears architecture on the web, some of the issues involved include ..
a) The lack of a data layer: For instance, AJAX calls can originate from anywhere within the code without an interim data layer. This is fine for existing Ajax applications since the only source is the server. However, when we also have local storage, there are potentially two sources (the server and the local storage). Hence, a common data layer is needed(which currently does not exist)
b) Features available offline: Not all features may be optimal offline – for instance rapidly changing stock quotes are best accessed from the server than offline
c) Modality – Managing the transition process i.e. switching between online and offline modes(explicit or user driven)
d) Synchronization: explicit, in the background etc
And then there is security .. a major topic in itself. According to the Google Gears site
, Gears follows the same origin policy
and security at the file system level is enforced by the Operating system.
However, when it comes to Mobile devices, there is a lot more in relation to offline storage and security. For instance
• Can the browser access content from removable media?
• Can the browser read/write data from the terminal’s file system programmatically?
• What restrictions are placed on personal data(stored in the cache) for ex data types like SIM contact data, Phonebook contact data, Diary elements etc which are normally protected but can now be cached.
To conclude, sqlLite is part of Android. It is also a part of Gears. Google could easily use a similar architecture and experience gained from Android to solve the problem of persistence in Mobile Ajax applications. A problem whose resolution would help the industry and encourage the growth on Mobile Ajax/Rich Internet Applications on mobile devices.
Comments welcome as usual
update from Stefan at intomobile
Actually Nokia is already implementing something called the Web Runtime with their next edition of S60 that will allow devices to do what you just said: http://www.intomobile.com/2007/11/27/widgets-the-s60-web-run-time-what-is-it-and-how-can-i-use-it.html
Motorola, in their next version of Linux, is also working on a web runtime.
What you want requires platform level support, something that even the mighty google will have a hard time with unless they pull a Yahoo 2 Go and build a mobile application platform in which developers work.
Who knows, too early to tell, but I agree with your basic logic that Google Widgets + Open Social + Google Gears for Mobile makes the most sense. The key is the implementation.