Over the years, Android has introduced several scheduling APIs for jobs that need to be scheduled outside the scope of an application’s lifecycle. Most of these come along with features that improve battery life & optimise resource utilisation. The choice of one suitable API, the inflexibility of switching between them and the amount of boilerplate code required for setting up makes it difficult to use these APIs. On top of this, API changes with varying Android API versions and most of the APIs not being backward compatible makes scheduling a headache. Continue reading “Scheduling tasks in Android made easy”
One question we frequently get asked is “How real time is your tracking experience?” When we respond saying it’s near real time (~4 second latency) the follow up is “You must be collecting GPS locations very frequently, what’s the impact on battery life?” The fact is we only consume ~5% of battery per hour of tracking. So your fully charged phone can last full day of tracking without breaking a sweat. This blog is a deep dive on how we achieved close to real time tracking with minimal battery usage – two things that are perpetually in tension with each other in the smartphone tracking world. Continue reading “Battery Efficient Real-Time GPS Tracking”
“You can’t sacrifice partition tolerance” – is one of the more influential articles that I have read on distributed systems design. It talks about applying the CAP theorem: in any distributed system design, choosing between consistency, availability and partition tolerance is a trilemma – you can only choose two of the three.
Theoretical computer science aside, the point it makes is that any practical distributed system needs to have partition tolerance built in. Remote nodes will die, networks will be flaky, and message packets will get lost – and that is how the world is.
Continue reading “Designed to be offline-first”
In the field of location tracking there needs to be lot of back-and-forth communication between devices and the backend. Device transmits location stream and health information (battery level, network strength, etc.). Backend processes this information, applies business logic on top and sends configuration commands back to devices in order to orchestrate tracking. These configuration commands determine when to start/stop tracking, frequency at which to collect GPS data (time and distance), frequency at which to transmit GPS data and so on.
In a world with patchy mobile networks making all this communication robust is quite a task. It is important to choose the right network protocol and design the communication semantics to get maximum benefit of the protocol’s capabilities. We recently switched a large part of our device-backend communication from HTTP to MQTT. This blog is about how we achieved it and our learning from it so far.
Continue reading “How we ditched HTTP and transitioned to MQTT!”
Celery is an asynchronous task queue/job queue based on distributed message passing. We are big fans of Celery and it’s an important part of our stack. As with any distributed system, Celery comes with it’s own set of challenges. In this post, I specifically want to discuss how we use Celery to push webhooks to our customers and the race conditions caused because of using database transactions. Continue reading “Dealing with database transactions in Django + Celery”
One of the major problems that affects the operation of real-time location tracking is patchy mobile network connectivity. Our users trust our SDKs by plugging them into their apps that are out in the big bad world. We guarantee uninterrupted operation of the app regardless of network connectivity. Our SDKs are built to be offline-first. Collecting and handling location data on the smartphone is resilient against bad network. As a result, it is considered to be the source of truth for all data including time – a crucial dimension for real-time location tracking.
Continue reading “Solving true time at HyperTrack”