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:
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.