Home » Low Power Location Tracking App Development Tips

Low Power Location Tracking App Development Tips

by Andrei Neacsu
7 minutes read
Key Points Building Location Tracking App HyperSense

A few years ago, HyperSense was tasked with creating a user security and SOS app for iOS and Android. This app needed to enable users to continuously transmit their location through an end-to-end encrypted channel to web-hosted servers. Security personnel would monitor all users, and in case of an emergency, they could dispatch assistance to the user’s location promptly.

The location tracking mobile app we developed boasted the following features:

  • Near real-time location tracking
  • SOS/panic button with covert gesture activation, eliminating the need to open the app
  • End-to-end encrypted chat
  • Secure communication between the handheld device and the server
  • Audio recording and streaming during SOS mode
  • Geo-fencing capabilities
  • SMS and email notifications

For more details about the application, visit our Portfolio.

One critical feature we had to deliver was low energy consumption, as users would avoid using the app if it drained their batteries. We achieved an impressive result: an average of 0.3% battery consumption per hour while continuously tracking the user with high accuracy (approximately 80 meters).

See also
Top Mobile App Distribution Channels Explored

Though the algorithm is part of HyperSense’s intellectual property, we want to share several essential aspects to consider when developing a location tracking mobile app. With over 5,000 development hours and 10,000 kilometers of test driving, we refined our algorithm. We hope these insights will help others develop similar applications more efficiently.

1. Properly define what real-time means

Even though the term “real-time” is often used, it doesn’t actually mean real-time, but rather regular updates at specific time intervals. This should be a general consideration in any software development process: specificity. For our algorithm, we updated the user’s location every 180 seconds when moving and 900 second when stationary. This was more than enough to cover our two goals: continuous tracking and low power consumption.

2. Write your own code for location tracking handling and server communication

When dealing with very specific requirements and performance expectations, don’t rely on 3rd party code even if it’s highly used. We’ve seen reputable 3rd party code behave in unexpected ways or have improperly documented small issues. There is another common issue that 3rd party software is not extremely comfortable with: changing specs. Our recommendation is to rely on your own experience, do proper research and write your own code.

3. Understand how the location hardware works. Let the hardware power off.

At first, when we started to work on the location tracking module, we polled the location every 30 seconds. Everything worked as a charm, but during tests we saw high power consumption from the GPS/location tracking related hardware. After a few more tests, we discovered that the location tracking related hardware was kept powered ON 30 seconds after we stopped using it. Considering that we polled the location every 30 seconds, the location related hardware was kept continuously ON, draining the battery as if we were using it continuously. Our advice is to implement an algorithm that allows the location tracking hardware to power off for a while, thus reducing overall battery consumption.

See also
Hypersense and Kotlin programming language

4. Understand how the network related hardware works

We encountered the same issue as in the location tracking hardware, with the network one. Mainly, it was an issue with the cellular data related hardware, that would remain powered ON for a while after we stopped using it. To reach our goals, we used in-memory caching and synchronizations with the server at specific time intervals.

5. Implement a stationary mode detection algorithm and refresh the location at longer time intervals

Considering our specific goals, we decided that tracking the user while stationary at longer time intervals would help lower the battery consumption even more. Therefore, we used the motion detection hardware to establish whether the user is moving or not. When the user was stationary, we only tracked his location every 900 seconds. This implementation was supported by the fact that most of the users were stationary most of the day.

6. Define the target accuracy for the location tracking

At first, we tried to rely on cell tower and WiFi location tracking, but it didn’t provide the needed accuracy (the target accuracy was 100 meters). There was also another issue to consider, the fact that some users would use the application in remote areas where WiFi coverage is low or non-existent. Setting a threshold for the location accuracy was required by both the ability to accurately locate the user and reduce the battery consumption (when the app gets a location that complies to this requirement the location polling is stopped).

7. Use simple server communication protocols

Don’t rely on standard HTTP communication with the online services, as HTTP brings a lot of overhead. We tested both custom socket implementations and AMQP. We ended up using AMQP when needed, as it provided less battery consumption compared to the custom socket implementation.

See also
8 Engaging Mobile App Animation Styles to Enhance User Experience

8. Disk writes are battery consumers as well

Unexpectedly, disk writes were another issue to overcome in our endeavour to reach 0.3% battery consumption per hour, while continuously tracking the user. In our tests, in-memory caching provided the best results.

9. Make sure 3rd party frameworks comply to your location and network access patterns. Don’t trust them, use the debugger to make sure they comply.

When you must use 3rd party frameworks, properly test them against your standards. In our case, we had to use Google Analytics, and it caused a significant increase of battery consumption due to both network and disk usage on both iOS and Android. We ended up developing our own custom analytics solution that complied with our own network and disk usage policies.

10. Make use of silent push notifications to wake the mobile application

This issue refers mostly to iOS and it doesn’t allow applications to continuously run in the background. Whenever the server detected that a mobile device was late with the location updates, a silent push notifications was sent to wake up the device. For similar situations, you can also make use of the significant location change functionality available on iOS.

If you have any questions, or if you would like to develop a location tracking mobile app, please Contact Us.

How useful was this post?

Click on a star to rate it!

Average rating 5 / 5. Vote count: 201

No votes so far! Be the first to rate this post.

Related Posts