Last week at both Mobile Web Megatrends and the CTIA Mobile Jam Session a major theme using the browser and mobile web technologies as a replacement for Java, BREW and native mobile applications.
Many of the developers attending both events who have been doing Java and native applications expressed frustration with the economic and technical inefficiencies of the mobile application model. They mentioned platform fragmentation that requires hundreds of versions of an app to support even a fraction of the market, deployment and support issues, and the difficulties of marketing applications – both through the carriers and off-portal. A number of different groups in the mobile industry, not just developers but also device manufacturers and carriers are looking to the browser to solve this problem.
As a mobile web guy all of this is music to my ears. But but as Michael Mace pointed out at the Jam Session, two requirements need to be met before browser based technologies are capable being a general replacement for applications:
- They need to be functional offline. The ability to edit a document can’t depend on the availability of a network signal.
- There needs to be access to core phone features like the phone book, calendar, camera and location.
There are at least two cross platform initiatives dedicated to solving these problem, Google’s Gears and the OMTP’s BONDI project. There are undoubtedly others but Gears and BONDI are the most visible.
Gears is an open source project originated by and supported by Google. It is licensed under a BSD license. Gears is currently available for Windows Mobile 5 and 6 devices as a plug-in for Internet Explorer Mobile. Opera has announced that future releases of Opera Mobile 9.5 will include Gears. Android will also include Gears but probably not in the initial release.
At this point Gears does not include everything an application developer might want. There is no access to PIM data or the phone camera for example. What Gears does provide on mobile is online storage and data synchronization, a geolocation API and asynchronous background proceesing. Google has espressed commitment to aligning the Gears APIs with the evolving W3C HTML 5 and WebAPI standards for offline data, synchronization and location.
Gears security uses a same-origin and permission based security model. Same-origin means that a script can only access an online resource via its own domain, protocol and port, in other words cross-site scripting is blocked. At the device level the plug-in prompts the user when an application using the Gears API attempts to access local resources. The user can grant or deny access. Gears can persistently store the permissions granted to a particular domain and API function so that the user is not prompted each time. For access to native functions Gears is ultimately limited by the device’s own security features.
Bondi is named after the famous Australian surfing beach and aims to provide great, but safe surfing. It defines interfaces and API’s that allow web based application access to device features and user data in a standard, controlled and secure manner. BONDI is a draft proposal of the Open Mobile Terminal Platform (OMTP), a non-profit mobile industry group founded by eight mobile operators. OMTP membership currently consists of over 35 companies including carriers, device and chip manufacturers, developers and content publishers. The OMTP’s goal is drive standardization and inter-interoperability accross mobile platforms. OMTP hopes that BONDI will find it’s way into handsets sometime next year.
In summary, Gears and BONDI have similar goals but are quite different in both scope and security.
Gears is shipping today with limited functionality, BONDI is very comprehensive in scope but availability appears to be many months away. I suspect that Gears will continue to gain more functionality and that BONDI will initially launch with a subset of its proposed APIs.
A more fundamental difference is in the way the two projects approach security. Gears extends to mobile the traditional web and PC model: inform the user of risks and trust him or her to act in their self interest. BONDI takes the paternalistic approach that users can’t be trusted to make wise choices. The platform itself must enforce security through verification and certification.
Security is always a trade off betwen user empowerment and safety. The BONDI approach undeniably does a better job of protecting both user data and network security. But it also creates more barriers to entry for developers and vendors, tending to reduce innovation. An open approach such as Gears’ enables greater innovation with some increase in risks for users and networks. There is a place for both approaches. Carriers and Enterprise IT will demand a secure verified application environment for the devices they sell and support. Open source developers, power users and new hardware makers without access to carrier distribution channels will appreciate the opportunities and low barriers to entry of the more open model. I support both. Together they will help to define a new era of web based mobile applications.
CTIA: Mobile Jam Session
Content is King on Mobile Too
Google Gears Opens Up Mobile LBS
Google I/O Wrapup
I love you site
WrapYourApp.com is a service that gives web apps a way to be sold in App Stores. All we need is the URL of the web app and we can put it in the iPhone App Store, Android Market, Palm Catalog (when it opens to general 3rd party apps) and desktop apps on Mac, Windows and Linux.
Prices start at $149.
Mobile web app authors maintain their own code and hosting – while being able to update their application without resubmitting the app to each store.
Hi. Yes, but more important, it is Yahoo!-specific. I’m writing an article on developing a widget using Blueprint as we speak; will let you know when it is out.
@C. Enrique Ortiz
I like Blueprint. It’s far less ambitious than Gears or BONDI, lacking, as you point out, access to handset APIs.
But it’s easy to code for, completely cross-platform and Blueprint widgets can run inside Yahoo Go 3.0 AND on the mobile web within Yahoo’s Beta person portal. By year end you should be able to compile the widgets as Java, S60 3rd and Windows Mobile apps as well.
The main downsides I see to Blueprint is that it’s yet another scripting langauge, incompatible with anything else and that it lacks offline storage and device access.
“What about Yahoo BluePrint. Has anyone compared Gears, BluePrint and BONDI?”
Blueprint provides a way to author mobile apps (widgets, snippets, and feed-viewers), using the Blueprint XML, that can be targeted at different platforms running the Blueprint Runtime; but no client-side scripting, or runtime access to handset APIs, at least not the current version..
Pingback: Smoothplanet » Blog Archive » Mobile web app vs. native app
What about Yahoo BluePrint. Has anyone compared Gears, BluePrint and BONDI?
Pingback: On Mobile Browser Based Applications | About Mobility
Flash has a chance but I think Adobe missed the window of opportunity by trying to charge end-users for the mobile runtime.
Also, the trend is away from proprietary single vendor platforms. after being burned by Qualcomm over CDMA, carriers and device manufactures don’t want to be dependent on a single supplier who can jack up royalties when the platform achieves critical mass.
What about flash lite, do you think that has a future to play in browser/downloadable applications?