Sunday, November 8, 2009

Android Location APIs and why they anger me

The problem lies in the fact that as a end-developer I have to care about the various location inputs on a phone. I have to think about GPS vs Wifi vs Cell Tower LocationProviders in order to really take advantage of the phone's location capabilities. What basically happened was that my algorithm for picking a users location based on incoming location updates caused more accurate but out of date location updates to be preferred over slightly less accurate but much more recent updates.

I basically have to deal with the fact that I might get location-from-gps after I get location-from-wifi-tower OR i might  get location-from-wifi-tower after I get location-from-gps so that the Last Known location may in some cases return a more or less accurate location than what the phone is really capable of reporting just because I wanted to be able to get a quick-kind-of-accurate-lock while I was trying to accquire a accurate-as-possible sort of lock.

How would I make this better?

I could see an API where instead of registering with individual location providers, you would query the system for a set of location updates. You would define that you want FINE location, but will accept COARSE updates first. You would have a getBestKnownLocation instead of a getLastKnownLocation that would return a location based on heuristics you might define when registering your location provider.  Visually, the updates you'd receive would look something like the growing/shrinking circles you get in the gmaps app when honing in on a location. Maybe the developer would request a "HyperLocalWhileWalkingAround" strategy that could be swapped with "PassiveUpdatesWhenLocationIsSignificentlyChanged." both of which could have knobs for controlling specifics of the strategy.

In short, I want to abstract away the code I have shown as an example above. As a end-developer, I don't care where the location comes from, just that I get a location but I do care, what the data looks like.