Over the last couple of years, we have seen a massive range of smartphones and similar personal devices released onto users. The inherent problem that faces us as developers is constructing solutions that will reach the largest amount of people – therefore, solutions that operate on the most popular platforms.

Let’s look at an example: Let’s say your client (or you) has had this great idea to release a mobile app into the wild – it will help your users navigate by keeping track of their distance from, say, their home. Clearly there are some device-specific requirements here – you are going to need to keep track of their location, so you are going to need some form of geolocation support in the device. Since you are developing for the mobile market, it should also be quick and easy to use, and look relatively pretty. Now, here is the crucial point – traditionally, at this point, you would be getting out your favourite IDE, and working out that iPhone apps are really popular at the moment, so lets build one of those – OK, so you are going to need the iPhone SDK from Apple, and you will probably also need to learn some Objective-C.

As you can see, it is so easy with mobile development to move rapidly from simple requirements analysis to getting bogged down in hardware, platform and SDK issues and considerations, which can take longed to get straightened out than the time required to actually build your project.

Here is when the newcomer enters the field – using a technology that has been in wide use for more than a decade, is easily expandable, customizeable, and understood – HTML. Well, not exactly HTML, but a combination of 3 key technologies that any web developer should be familiar with – HTML (or XHTML), CSS and Javascript. Thanks to a few platform builders (Apple, Android, Nokia/Symbian and Blackberry) getting in behind the W3C’s Geolocation Specification (http://www.w3.org/TR/geolocation-API/#api_description), getting access to platform-specific functionality such as GPS and Accellerometer support has been abstracted away from the device itself to the point where a few Javascript functions can open up a whole new world of location-based services that operate entirely on the world wide web. Why use a propriatary native application, when you can leverage a series of technologies that already have wide use and support?

This is what we have come to realize at 3Months – in most cases (the exception being a requirement to closely tie-in with the platform software or device hardware), either now or very soon, there is a way of accessing a wide range of device functionality from a normal webpage.

The key to developing a successful mobile web application to leverage this kind of functionality to access the information or device capabilities that you need is to use the most abstracted form possible – in this way, you can target a broader range of platforms (and therefore users), with the least stress.

Let me give you an example of why abstraction is good in this case. Let’s say you have been developing your mobile web application quite happily, carefully targeting iPhone users (because it seems everyone has an iPhone these days) – since you have been testing on an iPhone, you have done your Googling and noticed that you can use the <code>navigator.geolocation> class to access the phone’s location information. There is just one problem – this should work on the iPhone fine, as well as several platforms (The <code>navigator.geolocation</code> access method is the most common), but NOT Android – this could be quite a problem as more and more Android-based phones get released. Android actually uses its own system to access geolocation data from the phone – its called Google Gears (It’s also available as a browser extension for PC’s). Now, <code>navigator.geolocation</code> will not work for Andriod, but will work for iPhone – and, conversely, a Google Gears geolocation call will work for Android, but not for iPhone. Now we are almost back at the issue that we were trying to solve in the first place – being tied to just one or two platforms.

The solution to this is actually really simple – all we need to solve this is a Javascript that will make whichever call is actually going to return the user’s location. We ended up using this method to construct a very nice location-based web service, that quite happily should grab the user’s location (with the user’s permission, of course) from: iPhone, Android, Blackberry, Palm and Symbian thanks to our script to find the right function call (e.g. <code>navigator.geolocation</code> or Google Gears), and it even behaves exactly like a native app, thanks to liberal use of the jQuery and jQuery UI libraries to give us smooth transitions between elements and dynamic content, and AJAX to grab the content from our server-side application as we need it.

Useful Links:

• W3C Geolocation Specification: http://www.w3.org/TR/geolocation-API/#api_description
• Google Gears Homepage: http://gears.google.com/

Joshua McArthur is a Summer Of Code developer at 3months.