G-Maps Mobile by Chris Warren 2005
Update: The current alpha version can be tried by pointing your phone at:
I found myself with three things which I knew belonged together in a menage-a-trois of usefulness; one Bluetooth GPS receiver, one mobile phone, and finally a deep respect for the coolness that is Google Maps.
The one annoyance of Google Maps and Google Local is that where it's at its most useful, it's at its most difficult to use, i.e. when you're out on the streets. Yes, whilst a lucky few enjoy the luxury of access to WiFi hotspots, here in the UK they are few and far between. Chances are when you're out and suddenly overcome by an urgent craving for a fine caffeinated beverage or a 5-star Indian meal, you won't have access to the Internet. Other services exist such as Scoot or Yell which will SMS you nearby locations of interest, but in this day and age, why can't they be displayed on a map on your mobile?
The answer seemed obvious, a Java Midlet interface to Google Maps and Google Local, and whilst at it, how about allowing a Bluetooth GPS receiver to automate searches at your current location and enable it to be used as a driving guidance tool (you know, the whole "Turn Left in 50 yards..." thing).
Google do offer a basic mobile interface for Google Local, but it just doesn't quite live up to the expectations set by it's bigger DHTML brother. I wanted what we all know and love; those smooth scrolling maps which you can pan around at your discretion and zoom in and out, and the on-device plotting of a route.
Development started with working out how a geolocation mapped to a 128x128 tile, and then using the 'remainder' to find the pixel coordinate within the tile. Once this was done, it was a simple task to write a threaded system where tiles around your location are queued and downloaded via whatever the fastest data connection you have on your phone. Once they're fetched (and you've not scrolled away from the area) they're painted on the screen - very similar to what you see when you scroll around Google Maps at high speed. I made a quick improvement to the algorithm here by queuing tiles in a spiral fashion out from the centre - this way you get the square of most-significance first, and those just off-screen last - just how far off-screen it pre-fetches is set in the options.
The other important thing I do is cache the tiles on the memory stick in my phone so we don't need to expensively (my mobile provider charges and arm and 3 legs per MB) and slowly (no EDGE for me) download them every time we scroll over an area. I'm still investigating the best way to limit the cache. I have options of percentage of total size and leave x-MB free, and delete in a LILO fashion apart from when a location is bookmarked in which case it preserves a radius around the bookmarked location. As well as the tiles, the XML results are also cached for x-days unless they form the results of a bookmarked search, in which case they hang around for longer. I'm still pondering the logic of this, if you bookmark something you're doing it because you plan to use it again and again, so do you want the repeated search to be as fast as possible or to always reflect the current results from Google? As far as I can tell the Google Local results don't change that often, so caching a copy for speed and cost seems to make sense.
What else is there? Well, searches are "position-sensitive", i.e. a search always returns results near the current position of the map, which can be centred by; panning, a postcode/address search, cycling through search results, cycling through driving directions or by automatically tracking your position by GPS. This is the same with driving directions, you can find directions "from here" or "to here", "here" being the centre of the map.
Other useful timesavers include lists of most-recent used terms in the "goto" or "nearest" screens and the ability to reload saved searches (bookmarks) or jump to bookmarked locations.
For those that want to know, this has all been developed for Sony Ericsson's K750i - the first of their phones to both support JSR-82 (access to Bluetooth from Java) and JSR-75 (allows access to the filesystem) and provide enough storage space (via a memory stick) to allow caching of data.
If you're from Google and want me to stop my tinkering with this (please, please don't) or want to see it in action, then send an email to ten.nolaxi@sirhc reversed and I'll reluctantly/gladly oblige.
Anyway, enough talking, here's some screen grabs from the development environment for my phone:
