Android SharedPreferences and Jetpack Preferences Datastore

This article dives into the traditional SharedPreferences and the more recent Jetpack Preferences Datastore. It provides insights into their setup, usage, and key differences, culminating in a demonstration app that showcases both.

💡 Indeed, this article is my cheat sheet because I normally only have to implement once per app project, and I always forget the implementation afterwards.

Introduction to SharedPreferences and Jetpack Preferences Datastore

SharedPreferences

SharedPreferences has been the go-to solution for storing simple key-value pairs in Android applications for years. Its ease of use and straightforward implementation made it a favourite among developers for small-scale projects.

⚠️ While SharedPreferences is suitable for light and simple use cases, it’s important to note that it operates on the main thread, which can lead to performance issues and potential ANRs (Application Not Responding errors) if misused, especially with large sets of data or frequent access.

Jetpack Preferences Datastore

Enter Jetpack Preferences Datastore, a modern, asynchronous solution to overcome SharedPreferences’ limitations. It offers a more scalable approach to managing user preferences, leveraging Kotlin’s coroutines for non-blocking data operations. Unlike its predecessor, Datastore doesn’t immediately return the result upon data retrieval. Additionally, while Datastore does not directly tell us which key-value pair has changed, the design encourages a more reactive programming style, where UI components observe data changes and update accordingly.

⚠️ One major benefit of Datastore over SharedPreferences is its resilience to data corruption and support for transactional data updates, which ensure data consistency.

Implementing SharedPreferences

Minimal code is required to implement SharedPreferences. One initialises it using the application context and defines a listener to track preference changes.

This approach facilitates straightforward read and write operations through its edit() method, allowing for immediate updates to preferences.

Despite its simplicity, we are cautioned against excessive use, which could lead to performance bottlenecks.

Sample code snippet

The SharedPreferences code snippet provided outlines a basic setup for reading from and writing to SharedPreferences:

In this setup, sharedPref is initialised with a specific preference file name and mode. The OnSharedPreferenceChangeListener listens for changes to the preferences, updating the corresponding Flow or state holder when changes occur.

Reading a preference, such as a string or boolean, is done directly through sharedPref.getString or sharedPref.getBoolean, etc., with a default value for cases where the preference does not exist.

Updating a preference involves using the edit() method, followed by putString, putBoolean, etc., and applying the changes with apply().

The simplicity of SharedPreferences is evident here, with direct, synchronous access to preferences. However, the need for manual management of preference listeners and potential issues with synchronous operations on the main thread are noteworthy.

Implementing Jetpack Preferences Datastore

Transitioning to Jetpack Preferences Datastore involves a shift towards an asynchronous model, incorporating Kotlin coroutines for data operations.

The setup requires a bit more boilerplate than SharedPreferences, but it’s a small price for the benefits of asynchronous programming and improved scalability.

Dependency

// Preferences DataStore (SharedPreferences like APIs)
dependencies {
    implementation("androidx.datastore:datastore-preferences:1.0.0")

    // optional - RxJava2 support
    implementation("androidx.datastore:datastore-preferences-rxjava2:1.0.0")

    // optional - RxJava3 support
    implementation("androidx.datastore:datastore-preferences-rxjava3:1.0.0")
}

// Alternatively - use the following artifact without an Android dependency.
dependencies {
    implementation("androidx.datastore:datastore-preferences-core:1.0.0")
}

Sample code snippet

This approach involves defining a DataStore<Preferences> within the context, and using Kotlin's coroutines to fetch and observe preference changes asynchronously. The dataStore.data flow emits preference updates, which are collected and used to update the UI or application state accordingly.

Writing to the Datastore is performed within a coroutine context, ensuring the operation does not block the main thread, with edit { } providing a transactional way of updating preferences.

Architectural Considerations

Adopting MVVM and Clean architecture, both SharedPreferences and Jetpack Preferences Datastore can be integrated seamlessly, ensuring a decoupled, testable codebase.

By abstracting data source implementations behind repository patterns and leveraging dependency injection (e.g., Dagger Hilt), applications can maintain a high degree of flexibility and scalability, irrespective of the underlying preference management system.

Comparison and conclusion

• SharedPreferences offers simplicity and immediacy, which is ideal for small-scale applications or those with minimal preference data. However, its synchronous nature and potential for misuse underscore the need for careful, limited application.
• Jetpack Preferences Datastore represents a more modern, robust approach, catering to larger, more complex applications requiring asynchronous operations and a reactive programming model. While its setup and usage are slightly more complex, scalability and performance benefits are undeniable.

In summary, the choice between SharedPreferences and Jetpack Preferences Datastore hinges on specific application needs — simplicity and speed versus scalability and modern architecture.

🧑‍💻 For developers seeking a hands-on demonstration, my demo app, FusedUserPreferences, showcases the implementation of both systems and provides a practical reference for integrating user preferences into Android applications.