In six months of being live in public Beta, we have been amazed by the number of industries, countries and use cases for which developers want to build dynamic location-based services. We have learnt a lot from their usage and continue to evolve the HyperTrack platform to be useful to them. We find companies of all sizes rolling out apps for their internal users and customers, and they seem to have a natural desire to build features that require a continuous understanding of their users’ location. This needs to be achieved with high accuracy, low latency, efficient battery consumption and managed costs of 3rd party web services. The current location-based services of the smartphone Operating Systems fall short and developers end up having to build and operate a bunch of infrastructure to power such features. HyperTrack exists to solve this problem.
We announced the first Beta version of our dashboard in April 2016 when we had a few developers in private Beta who were generous enough to bet on us when we had no product to offer. We announced the second Beta version in September 2016 when we had a few more developers through our public Beta who were generous in sharing their feedback about their usage. It is now time to announce our third Beta version as more developers across industries and countries start using HyperTrack as part of their daily usage. Here are the salient features. Continue reading
The HyperTrack SDK powers location features, like live tracking, real-time delay alerts, and metering distance traveled, in apps all over the world. The SDK is built to collect and transmit a battery-efficient stream of location data. The SDKs for Android and iOS are fully native to access the core platform level location and network APIs.
Our SDK users build their apps on a variety of native and non-native platforms. The need for better location features is not limited to native Android and iOS apps — apps that are built on React Native, Cordova, Ionic, and Xamarin are also starved for better location APIs. Continue reading
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
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
“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.