HyperTrack is the fastest way to build live location features into your application, with our plug-and-play location stack allowing for easy integration with your existing workflow and business. We’ve built our stack to be quick to integrate, scalable and reliable, and providing real-time filtering while maintaining battery efficiency. Now, we’ve made it even easier with the open sourcing of our HyperTrack Live Android app.
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.
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:
- “Can we provide our location stream as input to your API and get your location stream as output?”
- “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.
Testing your API connections are extremely important before putting your implementation in place, and can save you a lot of trouble and duplicated effort. Here at HyperTrack we use Postman to perform this task, and we’ve found it so useful that we put together a collection so that you too can use it. Over the next few minutes we’ll be walking you through how to test your API credentials and queries for accessing HyperTrack and see what data will be coming back.
Here at HyperTrack we value working with our customers to implement our plug-and-play location stack into their existing applications and workflows. It is also very fulfilling when we can come alongside them to experience firsthand their challenges and work together to create solutions. OkHI is one of those companies.
With OkHi their mission is to enable the 4 billion people in the world that don’t have a physical address to be included in the same services enjoyed by the rest of the world. Their solution gives them an “OkHI address”, complete with a GPS tag and photo of the house’s gate.
HyperTrack allows for building location features into your application without needing to worry about all of the headache of managing that infrastructure. This frees up your developers to do what they do best – developing awesome solutions for your customers.
Our friends at Hotline, a FreshDesk product, have a leading in-app chat platform currently in use by many consumer apps like Zomato, Swiggy, HolaChef, and more. These apps use Hotline to provide seamless customer support experiences. One of the challenges that their customers were feeling was that their customer support teams were getting consistent queries like “where is my order?” or “when will the driver reach my place?” which would leave the support agent scrambling to provide timely answers.
As we reviewed dashboard V2 while working on V3, state management showed up as the biggest issue. For example on our live page we show the last know location of all the drivers. This UI state would need to refresh based on multiple actions – selecting a fleet, selecting status tabs, selecting a driver or explicitly hitting the refresh button at the bottom of the map. Because the state could be altered by so many events, it became difficult to handle race conditions and edge cases to provide a consistent view. Continue reading