I spent Monday at the Google HQ in London, listening in on, and catching up with an old friend and college from a previous life, Dick Wall. As an early podcaster (check out Java Posse) and Java heavyweight, he has more recently become known as a technology evangelist for Googles Android programme. As he was passing through London, he gave a technical seminar on getting started with Android. Android is essentially a custom JVM (called Dalvik), written on top of Mobile Linux v2.6 (see Nick Herriots blog for more on this), together with a Java application framework and libraries to provide a Java-based embedded run-time environment for mobile devices.

The framework has a technical elegance that would make Spock weep. You do not so much write programs to run on Android, as create processes (Activities) that will come in and out of user focus at any point in the Systems lifecycle. This focus may be user initiated or event (Intent) triggered, from other Activities resident or remote to your device. In doing so, an Intent carries its state in a Bundle (a data-map). Activities are started and stopped as needed to run an applications components (ie: the OS/JVM rules) moving your Activities through a set of state transitions. For those of you with an enterprise architecture background, this is a kind of mini-ESB inside a mini-SoA.

Location-wise, Android offers two relevant Java class packages, Location and Maps:

• Location provides access to the location and bearing of the device, if the underlying hardware supports this. There is very slick emulator integration with a KML file, so that you can create a predefined path in Google Earth, and have your Android application follow this emulated path from within the Eclipse plug-in.
• Maps provides access to a rendered map (MapView), as in Google Maps Mobile, allowing your application to control the position, zooming and overlay of content, as though the map was a part of your own Android application.

Android is currently emulator-ware, and will remain so until H2-2008, when Google is promising the first Android driven device, most likely from HTC. Finally, to paraphrase the It is beautiful, but is it art? in my title, Google currently has a naming problem. If you are coding on a custom JVM, and not including the full Java library set, you are going to want to avoid the issues that Microsoft went through in 1996 by calling it Java, until you have Suns blessing. Until such time, the statement is that Android uses the Java language. Over time I imagine this may ultimately manifest as another mobile profile variant of Java, optimised for a certain class of device.

Google are obviously getting into mobile. It fits well with their mission statement: ?To organise the world?s information and make it universally accessible and useful?. Although Google are famous for keeping their product strategy close to their chest, it is easy enough to derive something of their plans for mobile applications from recent history:

1. Mobilse existing properties: Search, Mail, Maps, Calendar, Chat, Checkout, YouTube and others to add a mobile channel to existing products.
2. Add a mobile context: Innovate and design for the mobile experience beyond straight ?porting? by embracing the personal, always on, portable nature of mobile.

For step 1: Google obviously needs to initially partner with operators to get its properties visible on existing mobile channels. Vodafone has recently integrated Google Search into Vodafone Live! and provided mobile access to YouTube and Google Maps as part of its own Mobile Internet initiative earlier this summer.

For step 2: The most obvious mobile context is the user?s current location, which provides an intimate degree of personalisation. Vodafone is working with Google to provide real-time location to Google Maps Mobile, by integrating with our location services for all devices in a number of countries, or separately with GPS devices, and Google has been working on Mobile Local Search for some time. This linkage of Search, Maps and current location makes life a lot more interesting.

Mobile should be treated as a distinct channel, not just another method of access to the exact same application. Searching for ?pizza? on a mobile probably means you are looking to immediately connect with a pizza delivery business nearby, and not looking for ?the definition of" or a discussion of healthy pizza ingredients, as you might expect over a fixed Web interface. Mobile Search should lead you to actionable content, a list of names and telephone numbers ? overlaid onto a map - being the obvious response: The mobile equivalent of the printed Yellow Pages.

Veteran Google-watcher John Battelle?s excellent 2005 book ?The Search? cites research from Kelsey Group that "as much as 25 percent of all searches are local, and most of those are commercial in nature (looking for a dentist, a restaurant, a plumber)". He later makes the claim that although the US Yellow Pages is currently a $15B business: Within one generation, however, the yellow pages will be viewed as a dead industry.
Now, before you tell me that flipping through a printed directory is far more convenient than turning on your computer and punching in some search terms, let me remind you that local search, as it's called in the search industry, is still in its very early stages, and that the platform for local search - the PC-based Web - will not be the only, or even the primary, platform for this particular search-driven revolution. There will be about 1.7 billion mobile phone handsets in by the year 2006, and most of these will have Internet access.In a wider context, News, Weather, Photo?s, Guides, Public Calendar?s could all similarly benefit from real-time location over a mobile channel.

The combination of mobile Search and Maps, combined with real-time mobile location certainly makes a potent advertising platform. The Mobile Map will be the new advertising marketplace, fighting for screen space and relevance as targeted web banners and sponsored links do today.

No, I haven?t just discovered moisturising crème for plastic: The Nokia N95 (see sidebar link for a review) is fast becoming the European poster child for an emerging market in GPS based navigation in mobile devices. Leveraging their acquisition of the German firm Gate5 in August 2006, Nokia launched their GPS device hardware with mapping and route planning in February 2007 and mobile advertising on the roadmap.

I was therefore surprised that it suffered the same Achilles heel of more traditional (non-mobile) GPS devices - a Time To First Fix (TTFF) of well over a minute, which certainly inhibits spontaneous street use. This First Fix is performed by measuring the distance - as observed by the time difference in transmission and reception of a GPS signal (then using Distance = Constant Speed x Time Difference) between itself and at least three other satellites. The transmitted GPS data also provides each of the satellite's current positions, so with a bit of intensive maths, the receiver can derive its own position in 3D space (latitude, longitude and altitude) from these surrounding reference points.

To cut a long story short, unlike traditional GPS devices (which typically only receive data), the fact that the N95's GPS chip sits inside a mobile device can help, as it can create a data connection for other agents to "assist" in the satellite data gathering and computation, so reducing the TTFF. It can quickly ask some bigger static servers (which are constantly aware of the position and velocity of the constellation) which ones it should be talking to, do the bulk of the maths and then tell it the answer.

This is the essence of Assisted-GPS or A-GPS. So, a recent Nokia press release stating that they have issued a firmware upgrade to add (among other things) A-GPS to the N95 caught my interest.

So, how should it talk to these servers? The N95?s original technical specification does not mention implementation of the OMA?s Secure User Plane Location PDF] (SUPL) protocol (unlike that of the later Nokia 6110 Navigator) which defines the various exchanges, and this is what lies at the heart of the recent N95 upgrade. SUPL is a Secure (TLS), User Plane Location protocol (based on XML) to exchange the GPS assisting data between a SUPL Enabled Terminal (SET: ?Mobile Phone?) and a SUPL Location Platform (SLP).

Although well placed to do so, the SLP need not be (and in these early days, more likely ?is not?) provided by the Mobile Network Operator. Nokia hint at the creation of a partner network in their press release:The service operates in tandem with a technical framework that allows third parties, such as service providers, to provide their own regional A-GPS services, making fix times even faster in certain areas- to the benefit of their subscribers
I do not know if there is a default SLP provider configured into the firmware upgrade, and without such a provider in place you will not see any TTFF benefit. Note that your operator may charge for the SUPL data exchange over their access network (Vodafone now flat rate their data), and that the SUPL protocol accommodates a charging function, allowing the SLP provider to potentially charge for their assistance if they wish.

Here in Newbury (home to the Vodafone HQ), our local council have a potentially useful scheme to report graffiti, burnt out vehicles, fly tipping, dumped supermarket trolleys and the like. You just send an email to streetcare@westberks.gov.uk to report the incident, and they will schedule a trip out to collect and/or clean up.

I wonder how much take up they get. Just supposing I did take a note of the email address from a local poster, what are the chances of connecting the next aquatic trolley while I?m out-and-about to the act of firing up the PC and sending in an email describing it?s location and supermarket owner back to local council offices?

Enter the mobile phone. I can send an MMS to an email address, so I could set up a contact with the street care address, and the local council is suddenly armed with a mobile eye: CitizenCam; but do I really have to enter my location into the email each time I send in a photo? The same mobile operator who is routing this MMS knows where my phone is at the time of dispatch. Can?t they geotag the MMS on its way to the destination? That way the council can see what needs to be dealt with, when the photo was taken and where it is ? and all I did was snap a photo, MMS it to a contact and walk on.

Services like Flickr would be so much simpler if the photo were implicitly geotagged on upload. I?m not alone in wanting this, but solutions are so far bespoke upload clients rather than generic operator support.

Empowering the community to capture and report incidents via mobile as they happen is becoming an increasing part of daily life. How much more effective could crime reporting be if the police started receiving multiple timestamp, location, photo/video and witness telephone numbers within seconds, by sending to an MMS shortcode (?999??).

If the same technology that facilitates happy slapping could be used for social good, potential criminals would have to fear the whole community, any of whom might just catch a picture of a face running from the scene or the registration of a car. However, recent legislation in France is going the other way. In an effort to stop the slapping, they are making it an offence to distribute images of violence, though officials say common sense will be used to filter good intentions from bad.

In talking to a mobile developer community about developing location services, I know that I will very quickly get the question ?I can extract the Cell-ID out of the phone, so where is that??

Wouldn?t it be great to give the operator a Cell-ID in exchange for a geo-spatial reference of some kind (Lat/Long, OSRef, PostCode etc). However I hope you appreciate the sensitivity of this. It would then be quite easy to run through the Cell-ID range and reverse engineer our physical network. This information could be useful for competitor analysis, or to those that might do harm to our physical sites.

However, why not make an open, shared, editable Gazetteer of your own, using a community of mobile application users. Having extracted the Cell-ID, pass this to your online Gazetteer (filtered by Operator), to return previously entered geo-references against this cell. You could list existing, or add new references (perhaps incentivised by a ?top ten cell explorers? list).

Over time, your community of users will have reverse engineered their own multi-operator Gazetteer, and this can then be used as an open platform for multi-operator location services (such as resolving the geo-ref against Points of Interest). It will of course require ongoing maintenance as operators adjust their network - which you might like to accomodate in your database retrievals.

A close variation on this theme is provided by Yahoo! Research. Check out Zonetag.