Starting with the 1.6.0 release, we will be rolling out some requested changes to the Geolocation module for Android. While these changes put more control in the hands of you application developers, there is also greater responsibility placed on you since there are structural code changes that will need to be made in order to utilize this new flexibility in a safe manner.
So first, let’s talk about the new features. Once 1.6.0 is released you will have control over the lifecycle of your geolocation listeners rather than them being removed automatically upon pause / destroy states. The primary thing to keep in mind with the new 1.6.0 change is that you are responsible for handling the addition / removal of the geolocation listeners in response to lifecycle events.
There is only one event that MUST be handled by any application registering for geolocation events. When an application receives a “destroy” event the application should remove any listeners that have already been added. Keep in mind that the pause, resume and destroy events mentioned here are fired by the actual onPause, onResume and onDestroy provided by Android OS.
Beyond the required handling of the “destroy” event, there is the optional handling of the “pause” and “resume” events where the new flexibility comes into play. While a background listener can be useful, significant thought should be given to whether a listener actually needs to run in the background since geolocation services like GPS can use a significant amount of battery when actively used on the device.
In general, if it is not important to get location updates when an application is paused, the developer should remove the listeners when “pause” events are received and then add them back on when a “resume” event is received. If a developer deems that the cost in leaving the geolocation listeners running when paused is worth it then the “pause” / “resume” event handling can be avoided. In either case, an application must ALWAYS remove any added geolocation listeners when the “destroy” event is received.
So, based on the previous description we have an example pulled from the 1.6.0 Kitchen Sink that shows how to handle the scenario where a developer doesn’t want to leave the geolocation event listeners running when the app is paused.[gist id=821688]
The other main change to Geolocation in 1.6.0 is automatic location switching. Android OS can make a determination on the ideal location provider based on specified criteria such as the “preferredProvider” property that can be set on the module. If the current provider no longer matches the suggested provider from the OS, the location provider being used will be changed to the suggested provider.
The result of this is that if your current provider (such as GPS) becomes unavailable then the next best provider will be used to provide location updates without any interaction from the application itself. Following the previous example, if GPS was to become available again and the OS saw GPS as the “best” provider then the location provider would then change again and location updates would be fed from the GPS.
We look forward to seeing the cool stuff the community does with the new changes