Web-On-Cell’s API Trojan Horse

OK, first things first: Web-On-Cell isn’t a new acronym or standard or catch phrase or anything like that.

I made it up.

But it kind of has a nice ring to it (oh boy, there’s a pun now too)….

What I mean by Web-On-Cell is really two things: one, the growing momentum around using wireless devices to access the Web, and just as importantly, 2) the movement of technologies from the Web world onto the mobile device.

The first trend seems undeniable. There appears to be real interest by users in surfing the “real” Web on a phone.trojan-horse.jpg

Enabling trend one, of course, is trend two – better on-phone technologies.

It starts with better Web browsers, which I’ve chronicled previously. Apple, Microsoft, Opera, Mozilla and a slew of other vendors are working to bring desktop-style browsing to the phone.

But it doesn’t stop with Web browsers. Flash Lite is already on the phone; embedded Web-based Flash –which powers YouTube and other Web sites – is on its way as well. Next-generation browsers will also better support AJAX and Javascript, not to mention support desktop plug-ins (such as Firefox add-ons) of all sorts. On the Web, developers have combined all these technologies to create new “widget-style” programming – small, network-driven apps – an app development style that fits well on mobile phones as well. Just today, Yahoo unveiled OnePlace, new bookmark/content sharing application that slides into its Yahoo on the Go mobile widget platform.

Another interesting trend are so-called “off-line” technologies that are now migrating not only to the desktop but to the phone.

Just today, Microsoft announced its Silverlight platform will be included on several Nokia phones. Platforms like Silverlight and Adobe’s AIR make it possible to run rich, desktop-like applications anywhere, anytime, whether connected to the network or not (much the same as Java, of course).

We haven’t even mentioned the Apple iPhone SDK or the Google Android SDK, both of which enable fairly open, Internet-style application development on mobile devices.

In another intriguing offline development today, Google Gears – the technology that enables Google’s Web-based apps to run in a disconnected state – became available for the first time on a mobile device, in this case, Windows Mobile. Telecom blog Open Gardens dug a bit into the Google Gears code to note that the technology can enable lot more than just off-line browsing – including providing location and secure file system access APIs.

And don’t forget GPS-like location enablers, such as Google’s MyLocation or similar technology from Navizon, which use combinations of cell-tower triangulation and other approaches to provide location data to mobile application developers.

The Telco2 blog is noting similar trends, pointing to a Nokia-targeted developer that shortened its app development cycle to three weeks using Web-based development styles. In fact, the whole idea of Web versus native mobile apps seems to be making the rounds in the blogosphere (see: Mobile Applications, RIP and Sounding the Death Knell for Native Mobile Apps).

Slowly but surely – Trojan Horse-style – device-level capabilities and APIs are finding their way into the wireless world. None of these APIs have anything to do with service provider IP Multimedia Subsystem (IMS) roll-outs, IP-based Service Deployment Platforms (SDPs) or even device-maker OS/deck combos. But bring them together and developers can begin to build powerful, online/offline, location-aware applications.

This is a significant change in the balance of power between the Web 2.0 players and telcos, since you don’t need a special (telco-issued) digital certificate or pre-installation for web applications.

Whether this is a good or bad thing, of course, depends on how wireless service providers are positioned to take advantage of, contribute to and even enable such development trends.

In a few weeks, Verizon will be laying out its open network plans at a developer conference, including not only device requirements but application APIs and capabilities as well. Will those specs dovetail will Web-based mobile developments or work against them?

The answer to that question will start to lay the path – or paths – forward for mobile application developers.

UPDATE: This blog post over at the NYTimes echoes many of the thoughts above and is worth a read:

The Battle Today for What you Can on Your Phone Tomorrow

Leave a Reply

You must be logged in to post a comment.