Local caching and offline functionality is a core part of the Android ecosystem, and now they’re available for your feature flags as well. With Split’s updated Android caching feature, you can cache feature flags and also take advantage of the automated cache updates that are native to the Android OS. What does this mean for your app? All of your Android users will now have access to the personalized experience you intend for them, at a speed that will keep them engaged, wherever they are, regardless of their data connection.
This is a big win for Android developers because it allows flags that control exposure to your new features, improvements, and bug fixes to be regularly updated and stored in the cache for instances when connectivity might not be available. Let’s talk more about how Android caching will work for your feature flags.
Local Caching on Android
By caching your app data locally on each device you allow your end user to have access to its functionality, even when they don’t have Internet access. This is great for your users who travel internationally or are otherwise frequently outside of their data service area. It also speeds up load time in areas where connectivity is limited, as the app can load from the cache while awaiting updates from a slower-moving data connection.
Bottom line: The caching mechanism on Android devices allows for a much faster end user experience with your app.
Android Caching for Feature Flags
We improved Android caching for feature flag updates to take advantage of the same benefits. By automatically caching feature flags, and pulling updates for those flags every fifteen minutes, your newest changes will be reflected for your users, regardless of their connectivity at the time they run your app.
This allows you to differentiate between different SDK statuses and gives you more granularity to handle the flow of your app to fit your use case.
The data refreshes every 15 minutes automatically — no human intervention or extra code needed. This is great for connectivity issues. Every 15 minutes, the Android SDK will try to synchronize Split data in the background. Because this relies on core Android functionality, it will occur regardless of whether the user has your app open.
This means that you as a developer can release features of your app through your flags, and those will be automatically released to your Android users — regardless of whether or not they have connectivity. This means that if you had to rollback or just kill a feature, the SDK will pick that up too, so next time the user opens the app, they won’t get access to the problematic feature.
Android Caching in the Wild
Let’s look at an example. Say you’re a developer supporting a travel app, when your Android users book a trip on your app and have to travel by air, they are likely to find themselves without Internet connectivity for some period of time. Now, let’s say you release updates that would be relevant to them during that time. Once they land and regain connectivity, either through local wifi or their data plan, they will receive your updates automatically, even if they don’t launch your app. In the instance of an international traveler who may often be outside data connectivity after they leave the airport or Starbucks, they’ll receive the updated app experience you intended for them, whenever they do launch your app, just as if they were connected to the Internet.
The gif below demonstrates the user experience you can expect from this updated functionality.
On the first mobile device, you see a normal connection receiving feature flag data, just as your app always has with Split. On the second device, you see a slow connection pulling data first from the recently updated cache, before switching over to the live version of your app. This allows for a seamless and speedy user experience, even when connectivity is degraded. On the third mobile device, you see that even with no network connection you are getting feature flag data from the cache at speed. Where before your user would have either experienced a timeout or stale data, now they have fresh data.
How Does the Split Android SDK Support Local Caching?
To take advantage of local caching for feature flags, we’re using the Android Work Manager, a Google Library for Android devices, which enables us to scale the updates in the background.
In the background, Split’s Android SDK is talking to the Android API on your users’ devices for stats and connection info so they can get the latest feature flag updates without negatively impacting the performance of their phones.
Previously, there was only one event that triggered when you opened an app managed with Split feature flags. Users simply had to wait for Split’s Android SDK to load. This pattern was dependent on a stable connection to get data from the cloud, and we would only fetch the flags configuration once the app was open and connected. If there was no connection, it would disrupt the flow of the app and it would use the cached info.
This is a common approach because checking the cache directly is quicker than checking for new data.
Here’s some of our default Android configuration, which you could tweak to your needs when instantiating the SDK. Read more in our documentation.
| Configuration | Description | Default Value |
|---|---|---|
synchronizeInBackground | Activates synchronization when application host is in background. | false |
backgroundSyncPeriod | Rate in minutes in which the background synchronization would check the conditions and trigger the data fetch if those are met. Minimum rate allowed is 15 minutes. | 15 |
backgroundSyncWhenBatteryNotLow | When set to true, synchronize in background only if battery level is not low. | true |
backgroundSyncWhenWifiOnly | When set to true, synchronize in background only when the available connection is wifi (unmetered). When false background synchronization takes place as long as there is an available connection. | false |
Now, as long as this is not the first time the user is running your app on the device, they will have the most up to date user experience. They won’t need to have the app open and connected to receive your feature updates.
Learn More about Experimentation and Mobile Feature Flags
Excited about this expanded Android caching functionality? We are too, and we’ll be bringing it to our iOS feature flags for dev teams soon.
If you’re interested in learning more about feature flags and experimentation, we’ve got some suggestions for you:
- Measuring server side changes, and why “hope” is not a strategy
- Experimentation and progressive deliver at Walmart Grocery
- You might not need continuous deployment
Get Split Certified
Split Arcade includes product explainer videos, clickable product tutorials, manipulatable code examples, and interactive challenges.
Switch It On With Split
The Split Feature Data Platform™ gives you the confidence to move fast without breaking things. Set up feature flags and safely deploy to production, controlling who sees which features and when. Connect every flag to contextual data, so you can know if your features are making things better or worse and act without hesitation. Effortlessly conduct feature experiments like A/B tests without slowing down. Whether you’re looking to increase your releases, to decrease your MTTR, or to ignite your dev team without burning them out–Split is both a feature management platform and partnership to revolutionize the way the work gets done. Switch on a free account today, schedule a demo, or contact us for further questions.