Control SDK configurations to manage movement tracking frequency
The HyperTrack SDK generates movement data in the form of location, activity and device health using the various sensors and OS APIs on the device. The SDK has configurations that manage frequencies at which this data is collected and transmitted to the server. Developers build movement-aware applications using this data after further processing on the server.
The SDK comes with a default set of configurations to balance accuracy, realtime-ness and battery efficiency when generating movement data. These configurations consist of constants and device-level rules.
SDK configurations controlled by the server
Our stack is designed such that the server can control the SDK configurations for each device we track. We built this capability so our patent-pending variable-frequency model for battery-efficiency could dynamically control the SDK configurations based on server-based rules around consumption, map context, use case, device hardware, OS version and more.
We encountered several situations where we needed to bypass the server-based rule engine and directly control the configurations for certain accounts, users or use cases.
Now you can control SDK configurations
We are now opening some of these SDK controls to our customers! In this post, we share reasons that led us to do this, give you a peek under the hood and share how you can take advantage of this with great power.
Why?
Default configurations work but I need more
Default configurations work for most developers but some need more control, especially to balance realtime-ness and battery efficiency without compromising on accuracy. For example, some use cases involve sub-second latency (or realtime-ness) all the time and other use cases require minimal battery consumption while tracking through the day. Customers who have one primary use case built with HyperTrack want direct control and choose to skip our automatic controls based on parameters that include use case and consumption.
For instance, battery drain reduces by half if you are willing to live with a minute of latency to get the data on the server without losing accuracy.
Different devices and users need different configurations
OS versions and device hardware is highly fragmented on Android. Each device behaves differently in a peculiar way. HyperTrack wants to be sophisticated about controlling SDK configurations based on OS and hardware idiosyncrasies but we are not there yet. Now imagine a fleet that predominantly uses a device with a custom Android version that kills all background tracking processes using a certain OS API. It is far easier to bypass our rules and get going with a configuration that works.
Minimize SDK upgrades
SDK upgrades are painful. We know. Upgrades involve a lot of moving parts in your engineering test and release cycle, and your user distribution and adoption cycle. We want to be least disruptive to your business even as you continue to take advantage of all new features and capabilities that we work hard to bring to you. We definitely do not want you to upgrade just because we need to change the value of some constants hardcoded in the SDK.
How?
A default configuration is created for your account when you sign up. This configuration is stored in cache for quick fetch when needed. When you integrate the SDK into your app and initialize it, we fetch the configurations assigned to your account. This invokes our rule engine in the SDK, which evaluates the rules sent by the server and changes the SDK behavior.
We have added a settings page on your HyperTrack dashboard for you to control certain SDK configurations. Should you choose to change these configurations, we will update them on the server and notify the SDK about the change using silent push notifications.
Rule engine and its evaluation
We created a simple rule engine that takes in a set of rules and evaluates them along certain parameters. Let us take a look at the structure through a snippet from our config file:
The structure starts with the type of rules that need to be evaluated. In this case, it is the rule to transmit data from the SDK to the server. This consists of a list of predicates in order of priority for evaluation. Each predicate has a result which is enforced if the rule returns true after evaluation. If none of the rules return true after evaluation, then the default rule is applied.
We convert every rule to a prefix expression, which is then evaluated in the SDK. If “a, b, c” is the expression, then a is an operator, b and c are operands and `,` is the delimiter.
Consider this example:
and,eq,health.power.charging_status,charging,gte,health.power.battery,30
In code, these rules get evaluated in the following way:
This is one of the simpler rules that I have shared for the purpose of this blog. There are more intricate rules that control the behavior of our SDK.
Preset configurations
With this release, we have exposed two preset configurations on your dashboard that will apply to all users in your account.
Real-time
I want near real-time data at all times.
Battery saver
I am okay with a minute of latency.
Team members : Aman Jain (Android SDK), Ravi Jain (Backend)
Looking forward to your suggestions on the approach that we have taken for sdk configurations. Like what we are doing? Sign up for HyperTrack and build movement-aware applications!
