Currently, geolocation code only fire events when starting and stopping the geolocation provider. It would be very useful to provide more feedback, allowing for example to fire mozChromeEvent notifying that we are waiting for a geolocation fix, then notifying of a fix, etc. Providing access to NMEA data might also be very useful (see http://developer.android.com/reference/android/location/LocationManager.html).
What is the specific use case?
As I said, a first one would be better notification of the geolocation status to the user via the statusbar icon, with the ability to see if it is waiting for a fix or if it has been acquired.
Alexandre, do you have any thoughts on the design of such a callback?
Nothing specific, for having been a user of Android's API, I found it pretty good, and nothing pops into my mind that say « this part of the locationmanager api is really a bad idea ».
Adding info on this one. A couple of weeks/months ago I had to debug GPS on Nexus S to add a notifiction when we get the real fix. Turns out that very accurate satellites infos and others are available in two callbacks in file dom/system/gonk/GonkGPSGeolocationProvider.cpp: - GonkGPSGeolocationProvider::StatusCallback(GpsStatus* status) - GonkGPSGeolocationProvider::SvStatusCallback(GpsSvStatus* sv_info)
This should either: 1) be marked a duplicate of bug 904986, in which case we agree this should be a web standard interface to this information (the plethora of apps on Android/iOS that show information about the GPS is evidence of this) 2) get further statements as to why we shouldn't do (1), and explain why using mozChromeEvent is a more reasonable approach.
(In reply to Garvan Keeley [:garvank] from comment #6) > This should either: > 1) be marked a duplicate of bug 904986, in which case we agree this should > be a web standard interface to this information (the plethora of apps on > Android/iOS that show information about the GPS is evidence of this) > 2) get further statements as to why we shouldn't do (1), and explain why > using mozChromeEvent is a more reasonable approach. I'd rather mark bug 904986 as the one being a dupe since my bug was file before.