Most apps today require detecting the location of the user, to be able to intelligently serve context aware content and actions. There are many methods of detecting location, however the challenges are in being accurate all the time and consuming less battery power for doing this. Having built mobile apps similar to Ola / Uber, where certain notifications are triggered when drivers are approaching towards you (entering your vicinity), I have noted my learnings and observations on how we can solve the above challenges optimally.
Deciding when to start and stop listening for updates has a direct impact on accuracy and battery-efficiency. An app need not be continuously fetching location co-ordinates, else it will drain the phone’s battery and also make unnecessary GPS calls even when there is no movement. So, the first thing to optimize is check for a minimum displacement / movement, say 10 meters and then if there is movement update the location. If needed, you can also check for location updates at an interval, say every 10 seconds. The movement or time interval, can be decided based on the app’s needs.
User’s location can be fetched in multiple ways, from multiple sources:
However, when the user is continuously in movement, between places or in conditions with fluctuating access to location data (say, when a user moves inside underground tunnels or when it rains heavily access to gps is limited); we would need to have a fallback mechanism to ensure the co-ordinates are accurately received. This is one of the key challenges in building realtime, location aware and geofencing apps.
GPS, CellPhone network, and Wi-Fi network can all give locations. Determining which one to use needs to be decided based on which is more accurate, fast, and battery-efficient.
That said, location data coming from each of these location sources is not consistent in accuracy. Location obtained 10 seconds ago from one source (say, GPS) might be more accurate than the current location from another or at times the same source. These are challenges every app using location, will have to accept and work around. This is where our fallback mechanisms can help.
Below table indicates the challenges with various location providers in terms of accuracy, coverage and battery efficiency:
Google has introduced Google Play services location API called FusedLocationApi. This API addresses the challenges that were there in LocationManager and gives better accuracy and battery-efficiency.
Developers now need not fetch locations from all the providers and keep choosing the best out of them.
Best part is – it uses the User activity recognition service and takes a sharp edge out of accuracy and battery-efficiency.
Please note: It doesn’t make sense to call for a location update when the device is in “STILL” state.
Not always, for all use-cases you’ll need a high accuracy mode. Detection at an area level or a locality level, may be sufficient for some use cases in the app. Below are the various options – high, medium, low energy modes you can choose from depending on what you intend to do with the data.
Choose the “energy mode” wisely when you’re requesting location, as this can significantly improve battery efficiency.
HIGH_ACCURACY mode: Could be used in applications which are primarily location driven (with maps and navigations) and need to be highly accurate (say, military apps, navigation apps). Since maps are running on foreground battery drain is fine.
BALANCED_POWER mode: Could be used in applications which are not dependent on accuracy of the co-ordinates, say a Weather app. BALANCED_POWER doesn’t use GPS instead it uses CellPhone network, and Wi-Fi to get the location.
NO_POWER mode: This mode is useful when your app doesn’t need to pro-actively detect location, but just act on demand basis or use the location data already fetched by other apps on the user’s phone.
Below priority matrix (presented by Google), shows how these priorities are handled by the location recognition algorithm.