Archive for January, 2011

Geolocation Gotcha

I’ve been working on an Air for Android app for the past month or so and I’ve been finding some significant little holes in the current version of the Air/Android SDK. I’ll start with the latest fist-shaking issue I’ve come across. The Geolocation class, only supported on Mobile applications, is a small, straightforward class with a quirk or two up it’s sleeve.  The following code example snippet comes from Adobe’s livedocs for the class (slightly modified): 1 2 3 4 5 6 7 8 9 10 if (Geolocation.isSupported) { geo = new Geolocation(); geo.setRequestedUpdateInterval(100); geo.addEventListener(GeolocationEvent.UPDATE, geolocationUpdateHandler); } else { trace( "No geolocation support." ); } This is a pretty straightforward way to use the Geolocation class. Check to see if Geolocation is supported on the mobile device, if it is, create a new Geolocation instance, set the interval of how long you want it to check the GPS sensors and update your GPS coordinates (every 100ms in this example), and add an event listener/handler function listening for when those coordinates have been updated. The problem here is: What happens when you have a mobile device that HAS gps capabilities, but the user has disabled the GPS for privacy/security reasons? Geolocation.isSupported returns TRUE because the phone does in fact have Geolocation capabilities. But your code will never reach the geolocationUpdateHandler function because the user has disabled GPS Geolocation. You will not receive an error, you will not hear a peep from your app, you will not pass Go and you most certainly will not collect anything near $200. There is one more significant check we need to do that should have been added to Adobe’s example to make it complete. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19   if (Geolocation.isSupported) […]

Read More…