Avoid storing frequently changing values in `UserDefaults`

[defagos]

The Commanders Act SDK (version 5.4.12) stores multiple values in UserDefaults, including identifiers, version information, and timestamps. This practice can introduce unintended side effects, such as unexpected behavior and performance issues in applications.

User Defaults

UserDefaults are designed to store non-sensitive user preferences, such as:

• Preferred color scheme.
• Preferred language for video content.
• Email list display style.

However, UserDefaults should not store frequently changing data, such as:

• Data fetch timestamps.
• Playback positions.
• Passwords.

Change Observation

Applications can typically respond to user default changes in two ways:

• Key-Value Observation (KVO).
• Global notifications.

For settings managed by a settings bundle, KVO is not supported. In such cases, only global changes can be observed.

Commanders Act SDK Behavior

The Commanders Act SDK updates UserDefaults frequently, especially when calling TCServerSide.execute(_:), which triggers updates to time-related variables via TCPredefinedVariables.computeTimeChangingVariables(). As a result, each event or page view sent through TCServerSide causes a UserDefaults mutation.

The Problem

Each event or page view sent through TCServerSide leads to a user defaults mutation which, depending on how an application (or other SDKs it uses) are implemented, can lead to unrelated work being performed each time an event or page view are sent.

This can lead to undesired view refreshes or potential performance issues, depending on the total amount of work an application performs in response to such mutations.

Commanders Act SDK, as stated in its documentation, should have a minimal footprint. User defaults mutations can lead to uncontrolled additional work and are therefore not aligned with this goal.

Code Sample

Here is a sample project showing how this can be an issue. The contained app provides a button which sends a Commanders Act event. The app also listens to user default changes, performing significant work on the main thread in response (simulated with a 1-second sleep).

To understand why this is an issue:

1. Run the project, on device or with the simulator.
2. Click on the Send event button several times in a row. Observe that the UI freezes.

This example exacerbates performance issues but in general those can be much subtler and difficult to identify. In most cases, though, they will go mostly unnoticed but might lead to small hitches, like the ones we identified with media players, tracked using Commanders Act, added to scrollable views.

Possible Solution

The Commanders Act SDK should be updated to avoid misusing user defaults. A separate preference storage could be introduced. Parameters that change fast (e.g. timestamps) should be moved to this separate storage. Only essential, rarely changing parameters should be kept in user defaults.

As a result, running the sample project attached to this issue with the updated SDK should not freeze the UI anymore.

[CommandersAct]

Hello !
You're totally right about that. Little by little we added more things and we need to make some changes.
We'll keep you updated when we have a new better version