Case study

Goibibo testing HyperTrack to power live tracking for its intercity cars platform

This is a guest post by Raj Gupta, Product Manager, Goibibo

Goibibo offers goCars, a safe & reliable way to book intercity cars & airport transfers. As an all-encompassing platform, goCars enables users to cover their city-to-city journeys in shared or exclusive cars. Continue reading

Standard
Technology

Are stops important in the world of location tracking?

We had trips on our mind when we first built HyperTrack. We assumed that developers would start tracking a user when they expected the user to be on their way to get some place and stop when they had reached. The assumption failed. Obvious in hindsight, developers expected us to tell them (and not the other way around) when the user was on the way and when they had stopped. All they wanted to do was switch us on or off, and hand over control to HyperTrack to automatically figure out trips and stops in the life of the user. They would keep HyperTrack on through the day, through the week, or just switch it on and leave it on forever. HyperTrack was expected to notify developers about the start and end of these trips and stops, besides other useful events along the way. This led to a re-architecture of our stack that we rolled out with HyperTrack v3 in March. Continue reading

Standard
live location tracking features
Technology

Why building live location features requires more than maps APIs

The next generation of location-based services uses live location to make assignments, track orders, track miles, personalize experiences and power great product experiences. A fleeting glimpse by product managers and developers might lead to a false view that maps platforms are sufficient to build these features. This post covers what maps do and don’t.

Say you want to build an in-app tracking view of an order. It needs to be a smooth experience (think animated icons) with accurate location (route polylines maybe), live ETA (that updates every minute), user/order information (a drawer to reference) and trip status (why is it stuck there). To build this, what can developers count on maps for and not? Read on for the answers.

Continue reading

Standard
streaming live location data
Technology

The pitfalls of using location streams as an interface for building live location features

Developers build live location features in their product because it is core to their business. In the process, they end up having to build infrastructure. Developers who have built and operated this underlying infrastructure on their own have a deeper experience of the pains involved. Often, this is the first time they start questioning if that part of the stack is core to their business and if there is an API for that. In the chance that they find HyperTrack as that API they were dreaming of, a new problem arises.

In many in-house location stacks, the de facto interface at which the infrastructure stops and the feature begins is the location stream. You generate the location stream on the device, log/store it on the server, and then consume it in the product. For enterprises using vehicle tracking systems (VTS) and GPS chips, there is a legacy reason to go down this path. When other teams and software modules in the stack are consuming this stream, it is hard to imagine ripping it out and replacing it with HyperTrack SDKs and APIs.

And then begins: “But it does solve a bunch of things we are dealing with”, “Hey they seem obsessed with it and we are not, they must know something we don’t”, “Let’s deploy it on that new feature or new set of users in that new project”, “Let’s run this in parallel with our stack and compare the results before phasing it in”, etc.

It is then that one of the two questions comes up:

  1. “Can we provide our location stream as input to your API and get your location stream as output?”
  2. “Can we use your location stream as input to our API and everything upstream will start working better?”

Tl;dr – Bad idea. Using location streams as the interface is architecture debt. Pay it off.

Continue reading

Standard
Technology

Battery Efficient Real-Time GPS Tracking

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

Standard
Technology

How we ditched HTTP and transitioned to MQTT!

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

Standard
Technology

Problem: location/maps APIs are inadequate for developers to build location tracking features

Over the past year, we have interacted with thousands of developers from over 30 countries and as many industries. These conversations have helped us understand the use cases that compel developers to build location tracking features into their products. Turns out, they are forced to build and operate complex location tracking infrastructure to make the features work.

HyperTrack APIs have been built to enable these use cases such that developers can focus on features that are core to their business and not have to worry about the infrastructure. In this post, we draw a distinction between location tracking features and infrastructure, and propose a better primitive to solve the problem. In the next post, we walk through the HyperTrack API framework and how the building blocks work for your use case.

Continue reading

Standard