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

Real-time location tracking with near-zero battery impact

The HyperTrack SDK is active on thousands of devices through 100+ apps across the globe. Users represent all 6 inhabited continents, 2 major smartphone Operating Systems, several tracking use cases and markets, and a variety of network and GPS conditions. We implemented a way for the SDK to record overall battery consumption on the device during the time it was active. This is our first battery benchmarking exercise at a reasonable scale. This goes beyond small scale tests we had done with dozens of users in controlled setups. Turns out, we are able to deliver real-time location tracking with near-zero battery drain.

In this post we share the data that implies that HyperTrack delivers real-time location tracking with near-zero battery drain. We go on to list the battery optimization techniques we used in order to get there.

Continue reading

Standard
location tracking service professionals
Tutorial

Build location tracking of at-home service visits in Android

Location tracking is driving forward thinking services businesses around the world to build mobile marketplaces that connect freelance and in-house service professionals with local consumers. Services like home healthcare, beauty, auto mechanic, laundry, cleaning services, handyman, pickup and delivery are booked with the tap of a button and serviced by professionals who use an Android or iOS app to manage the visits. Live location of such service professionals can be useful to assign jobs based on location, track the visit, measure productivity, share location with customers for a better product experience and track miles for expense management. Service aggregators around the world and across industries use HyperTrack to build live location use cases.

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