Engineering
Countly SDK Development Updates: What's New and Improved?
Last updateD on
September 23, 2024
2024 has been a year of intense development for the Countly SDKs, with numerous major and minor releases making it easy to lose track of all the changes (which more than justifies our self-proclaimed title, SDKshians). If you're looking to understand the core themes behind the recent developments without sifting through countless GitHub release notes, this article is for you.
With time, the new becomes old, and the old becomes a relic of the past. As newer technologies and hardware are adopted, analytics tools inevitably follow the trend. To support upcoming and trending technologies, Countly SDKs constantly go through a rework of existing features. One of these reworked features is the Views.
SDKs are leaving behind the simplicity of single-view tracking and introducing simultaneous view tracking to the mix. While it is still possible to track a single view, SDKs* now support starting, stopping, pausing, and resuming simultaneous views. Moreover, now you can add segmentation to these views at any time during their life cycle.
(*Currently supported by Android, iOS, Flutter, Java SDKs, Unity SDK)
We identified some issues with session handling, including excessively long session durations (over 20 days) and sessions showing no duration (0 seconds). These problems affected the accuracy and reliability of session tracking, leading to inconsistencies in how sessions were recorded, especially in background processes.
To resolve this, we've implemented several improvements. Sessions are now prevented from starting in the background, ensuring they consistently end across different scenarios. We've also ensured that sessions start as expected under all conditions, with fixes to improve session duration accuracy for more precise tracking.
Previously, developers had to manually call a specific method to send user properties to the server, which could lead to problems. If the method wasn't called, user properties wouldn’t be sent, causing data mismatches with later events.
Additionally, calling the method too frequently, even when unnecessary, could result in higher data usage and wasted server resources.
With our latest updates in the SDKs*, user properties are now automatically saved during key actions, such as recording an event, updating a session, or changing a device ID. These enhancements eliminate the need for manual calls, simplifying the integration process and making it more efficient overall.
(*Currently supported by Android, iOS, Flutter, and Unity SDKs)
Similar to the developments in Views, explicit control over a feature while keeping its simplistic origins is becoming increasingly common among SDKs. The latest additions to this formula are the Remote Config and A/B Testing features.
Previously, users enrolled in an A/B test whenever the SDK downloaded Remote Config values from the server if they were eligible. While easy to use, this method introduced some issues. If a value was downloaded but not used, the user was still included in the calculations for that test. Now, you can explicitly enroll a user using a specific value to avoid this pitfall with most SDKs*.
(*Currently supported by Android, iOS, Flutter, Java, and Web SDKs)
Server-side tracking is also getting more heat from the improvements in Java and Windows SDKs. These SDKs offer a unique ‘Backend Mode’ where you can have total control over the device ID (at Windows, even the app key) of the SDK requests, making it suitable for server-side tracking. The previous implementation with event and session tracking support has now extended to view tracking and crash reporting features. It has brought server-side tracking to a more feature-complete position.
While most of these reworks intend to increase feature options and extend the usability of the SDKs, with Application Performance Monitoring (APM), we did the opposite. APM is a resource-heavy feature that can increase the data points on your dashboard immensely if unchecked. To prevent extensive performance tracking, we have disabled all of its automatic tracking features by default. To track a specific metric in automatic mode, you need to turn it on explicitly.
A recent addition to the SDK feature set is the "Server Config," which allows you to disable tracking or networking directly from your Countly server. Supported SDKs* can check during initialization whether to turn off tracking completely (acting as if no consent was given) or continue tracking but block server communication, keeping data on the client device. This is still an experimental feature we're refining for optimal results.
(*Currently supported by Android and iOS SDKs)
Plenty of SDKs have some improvement or extension to their capabilities:
Some of our SDKs (iOS, Android, Flutter, React Native, and Unity SDKs) include push notification functionality. Still, this feature has dependencies that can sometimes clash with other components in your project. These conflicts can lead to integration challenges, particularly in environments with multiple dependencies.
We’ve developed no-push versions of our SDKs to address this, allowing for easier integration without dependency conflicts. Our lovely Flutter SDK already has no-push versions available, and we’ve recently released a no-push version for React Native. Also, a no-push version of the Unity SDK is coming soon.
Recently, many bug fixes have been aimed at maintaining the feature parity, addressing issues that arose as we worked to bring all SDKs up to the same standard.
We focused on ensuring feature parity across all SDKs, particularly in critical areas such as:
Our goal is to provide a consistent experience regardless of the platform. This alignment ensures a consistent experience and functionality across different platforms, making it easier for developers to work with different platforms without worrying about inconsistent behavior.
When faced with unusual data or user behavior on your server, it is hard to avoid pondering where the problem might be. When a change in user behavior can not be explained easily, it is inevitable to consider that issues might reside at the SDK or the server side. To alleviate this guessing game, we have introduced some new measures that can provide more information about the internal state of the SDK.
‘Health Checks’ is one of these new measures. SDKs* with this feature would send a report to the server during the SDK initialization, delivering the SDK error count and the latest network error message (if any) indicating whether there is a problem with the SDK.
(*Currently supported by Android, Flutter, React Native, and Web SDKs)
Other measures include providing more information to the requests the SDK generates to distinguish each one without effort. Now, the app version and remaining request count are added to each request to separate a request from an older app version from the rest and to see any issues with overflowing request queues, respectively.
Looking ahead, we remain dedicated to enhancing our SDKs to boost their functionality and user-friendliness. Our upcoming goals include developing a content builder to streamline content management and expanding our server configurations for greater control over SDK settings.
We plan to expand our server configurations by controlling more SDK config options from the server. For now, we are starting with simple Boolean and numeric values. We aim to introduce additional interfaces that will enhance ease of use and customization.
We are also focused on consolidating experimental features into a single framework, facilitating quicker testing and refinement of new ideas.
As we (SDKshians) always say, providing the most secure SDKs with minimum overhead is our never-ending quest. But for changes similar to these and much more, stay tuned for the upcoming changes in the new quarter!
.svg)
