A few years ago, HyperSense was asked to develop a user security and SOS application for iOS and Android, that would allow users to continuously send their location through an end-to-end encrypted channel to web hosted servers. All users were monitored by security personnel, and in case of any emergency, security staff could be dispatched to their location ASAP.
The location tracking mobile app we developed included the following features:
- near real-time location tracking;
- SOS/panic button and covert gesture for activating it without opening the application;
- end-to-end encrypted chat;
- end-to-end encrypted communication between the handheld device and the server;
- audio recording and streaming when SOS mode was enabled;
- SMS and email notifications;
- and many other features – more details about the application can be found in our Portfolio.
One of the most important features we were asked to deliver was a low energy consumption because users would not use the app if it drained their batteries. We achieved a stunning result: an average of 0.3% battery consumption per hour while continuously tracking the user, with high accuracy. The average location tracking accuracy was around 80 meters.
While the algorithm falls under HyperSense IP, we want to share a few key aspects to consider while developing a location tracking mobile app. We spent more than 5000 development hours and test drove more than 10000 kilometres to refine the algorithm. We hope these key points will help others find their way faster while developing similar applications.
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.
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.
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.