This post summarizes the six most common use cases associated with using GPS and location services on an Android device. It also continues the series on using the open source GPSTester tool to build better location aware Android apps. So not only can you read about what works and what doesn’t you can also try various scenarios out yourself using the tool rather than having to build code from scratch.
I’m striving to make this information freely available because adding location to your apps can be fun, and it can also be an important part of the applications that you build. By taking into account these six use cases you will be able to build applications that better meet your requirements and make for a more enjoyable end user experience.
Use Case 1 – Cold Start. Application launches from a completely stopped state. Cached GPS and Network location values may be unreliable. As a developer you don’t really have any control over this but you need to plan for it. The screenshot from the GPSTester tool below shows a typical cold start where the cached network location has better accuracy than the most recent GPS location. You can see from the timestamps that even though the GPS location is more recent than the network location, it’s the network location that has better accuracy.
Use Case 2 – Warm Start. Application launches from a minimized state. Cached GPS values may be reliable depending on how much time has passed since application was last running, and the total distance traveled away from when the app was last used. Like the cold start, the user that decides how and when to start the app and you just have to plan for this use case. The screenshot below represents a typical warm start scenario where the cached GPS result has better accuracy than the cached network provider.
Use Case 3 – Minimized. Requirements may call for location listeners to continue to run in the background, or to be shut off when the application is minimized. There is also the option of using what’s called passive listeners which rely on other applications to call location services. Note, if you listen for location changes in a minimized state you typically won’t benefit from this information until the application is opened again. In my previous posts I’ve stated that if your target demographic uses retail and social media apps this use case may be of benefit if the person uses the device constantly during the day. Many retail and social media apps access location. However, in many commercial use cases using passive location listeners may provide less than desirable results since there is much less of a chance of another application using a location service.
Pros: Running location services while app is minimized can speed up acquisition time when app starts, but only if your requirements call for always-on accuracy at a moment’s notice. If you shut off location then you will save battery life.
Cons: If active location services are left on in a minimized state this can sap the battery without the user really knowing it.
Use Case 4 – Snapshot. Application only needs to hit a minimum level of accuracy before shutting off location services. The screenshot below shows that it took approximately 2 minutes for the device to reach an accuracy of 12 meters. Yep, you heard that right…2 minutes! Also note how much the latitude and longitude of the different providers wandered around the map. The blue dot indicates network locations and the red dot indicates GPS locations. This is just a reminder that consumer-grade Android devices may or may not be accurate enough for your unique requirements.
Pros: Maximizes battery life.
Cons: May cause user interface delays if user needs to refresh the location during a single application session.
Use Case 5 – Continuous duty. Location services need to be constantly on while application is running. The screenshot below shows a use case of the user being in a downtown area with lots of tall buildings, the apps was run for about 10 minutes, then minimized briefly, then opened again for a warm start. The accuracy didn’t change much even after 10 more minutes of testing. As you can see, the GPS provider accuracy has suffered significantly at 153 meters, while the network provider is offering 45 meters of accuracy.
Pros: Best for constant, up-to-date, always on accuracy. Accuracy available instantly (after the device has ‘warmed up’).
Cons: Huge drain on the battery, but you can adjust the minimum distance property needed to trigger a location update.
Use Case 6 – Intermittent duty. GPS is only needed to run at intervals. To test these types of scenarios you can adjust various settings from within the GPSTester Tool’s preferences. Specifically you can modify the GPS and Network properties for minimum update time and distance. This is very powerful as you can easily toggle these settings to test various settings on-the-fly versus have to write custom code.
Pros: Depending on your use cases such as delivery driver tracking application, this can provide a good compromise on battery usage and accuracy.
Cons: You will have to write algorithms to constantly adjust the location service settings to meet the users movement patterns. This may also involve cycling the location services on and off to maximize battery life.
A few comments on testing your use cases. In the GPSTester tool there are a number of settings you can use to adjust how the device will receive location information.
You have full control over which providers are being used whether it’s GPS, Network or Critera.
Location provider indicators on the main screen will show which providers are being used. You can also see which provider is providing the best accuracy as determined by comparing available providers.
There is a list of available providers available on the GPSTester tool as well as table row showing what the device considers to be providing the best accuracy.
References
Android GPS Testing Tool
GPSTest Tool Github Repo
How accurate is Android GPS Part 1 – Understanding location data
How accurate is Android GPS Part 2 – Consuming real-time locations
