DataStore & Preferences

Android Development — Architecture & Data

Course 2 · Chapter 7 · DataStore & Preferences

💾 DataStore & Preferences

Room (Chapter 3) is for structured, queryable data — a list of tasks, notes, users. For small, simple settings (a theme preference, "has the user seen onboarding," a saved username), Jetpack DataStore is the modern tool — Flow-based, coroutine-native, and the direct replacement for the older SharedPreferences API.

📛 Why Not SharedPreferences?

SharedPreferences was Android's original key-value storage API — still seen in older code, but with real problems DataStore was built specifically to fix:

No Built-In Observability

Reading a value is a synchronous, one-time snapshot — there's no native way to observe a value changing over time without a separate, manually-registered listener callback.

apply() vs commit() Confusion

commit() writes synchronously (risking a main-thread stall); apply() writes asynchronously but silently swallows any failure — neither is a genuinely safe default, and it's easy to pick the wrong one without realizing it.

🔑 Preferences DataStore — A Flow-Based Key-Value Store

val Context.dataStore: DataStore<Preferences> by preferencesDataStore(name = "settings")

object PreferencesKeys {
    val USERNAME = stringPreferencesKey("username")
    val DARK_MODE = booleanPreferencesKey("dark_mode")
}
        

// Reading — as a Flow, exactly like a Room query
val username: Flow<String> = context.dataStore.data
    .map { prefs -> prefs[PreferencesKeys.USERNAME] ?: "Guest" }

// Writing — a suspend function
suspend fun saveUsername(context: Context, name: String) {
    context.dataStore.edit { prefs ->
        prefs[PreferencesKeys.USERNAME] = name
    }
}
        

Context.dataStore by preferencesDataStore(...) reuses Kotlin Intermediate Chapter 4's property delegation again — this creates a single DataStore instance tied to the app's Context, following the same one-shared-instance idea as Chapter 3's Room database and Chapter 4's Retrofit client. .data is itself a Flow<Preferences> — every read is inherently observable, with no separate listener API needed, and every write is a genuine suspend function rather than a fire-and-forget apply() call.

⚠ String Keys Are Still Just Strings

Preferences DataStore is a real improvement over SharedPreferences, but it's still fundamentally a loosely-typed key-value bag underneath — stringPreferencesKey("username") and a typo'd stringPreferencesKey("usrname") elsewhere compile fine and silently create two unrelated keys. This is exactly the problem Proto DataStore, next, solves properly.

📐 Proto DataStore — A Real Typed Schema

Proto DataStore stores a single, strongly-typed object (defined via a .proto schema file and Protocol Buffers code generation) instead of loose string-keyed values:

// user_prefs.proto
syntax = "proto3";

message UserPreferences {
  string username = 1;
  bool dark_mode = 2;
}
        

A Gradle plugin generates a real Kotlin class (UserPreferences) from this schema at build time — reading and writing become fully type-checked, with no string-keyed lookups anywhere, and no possibility of a typo'd key silently creating a second, unrelated value.

Preferences DataStore vs Proto DataStore

	Preferences DataStore	Proto DataStore
Schema	None — loose string keys	Defined in a .proto file
Type safety	Per-key, easy to typo	Fully typed generated class
Setup complexity	Low — no extra build step	Higher — needs the Proto Gradle plugin
Best for	A handful of simple, independent settings	A larger, structured preferences object

For most small apps, Preferences DataStore is the pragmatic default — Proto DataStore's extra setup pays off once there's a genuinely complex settings object worth modeling with a real schema, similar to reaching for Room over a flat file once data gets structured enough to need it.

🔌 Wiring DataStore Into the Existing Pattern

This slots into exactly the same repository/ViewModel/Hilt pattern already used for Room and Retrofit:

class SettingsRepository @Inject constructor(
    @ApplicationContext private val context: Context
) {
    val username: Flow<String> = context.dataStore.data
        .map { prefs -> prefs[PreferencesKeys.USERNAME] ?: "Guest" }

    suspend fun setUsername(name: String) {
        context.dataStore.edit { prefs -> prefs[PreferencesKeys.USERNAME] = name }
    }
}

@HiltViewModel
class SettingsViewModel @Inject constructor(
    private val repository: SettingsRepository
) : ViewModel() {
    val username: StateFlow<String> = repository.username
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), "Guest")

    fun updateUsername(name: String) {
        viewModelScope.launch { repository.setUsername(name) }
    }
}
        

Every piece here — @Inject constructor (Chapter 5), a Flow exposed as StateFlow via .stateIn(...) (Chapter 3), viewModelScope.launch (Chapter 6) — is a direct repeat of the architecture already established for Room. DataStore is simply another data source feeding the exact same pipeline.

DataStore vs Browser localStorage

	Browser localStorage	Android DataStore
API shape	localStorage.setItem(key, value) — synchronous	dataStore.edit { } — suspend, async by design
Reading reactively	No built-in mechanism (storage event is limited)	.data is a Flow — inherently observable
Value types	Strings only, manual JSON.parse/stringify for anything else	Typed keys (Preferences), or a real schema (Proto)

💻 Coding Challenges

Challenge 1: A Preferences DataStore Setting

Set up a preferencesDataStore named "app_settings", a booleanPreferencesKey for "notifications_enabled", and functions to read it as a Flow<Boolean> (defaulting to true if unset) and to write a new value via a suspend function.

Goal: Practice the basic Preferences DataStore read/write pattern.

→ Solution

Challenge 2: A Settings Repository with Hilt

Wrap Challenge 1's DataStore logic in a SettingsRepository with an @Inject constructor (taking @ApplicationContext Context), exposing notificationsEnabled as a Flow<Boolean> and a suspend setNotificationsEnabled(enabled: Boolean) function.

Goal: Practice wrapping DataStore access in a properly-injected repository, following Chapter 5's pattern.

→ Solution

Challenge 3: A Settings ViewModel

Write a @HiltViewModel SettingsViewModel exposing Challenge 2's notificationsEnabled as a StateFlow<Boolean> via stateIn, plus a toggleNotifications() function that reads the current value and writes its inverse via the repository.

Goal: Practice the complete DataStore → Repository → ViewModel chain, end to end.

→ Solution

💡 Course 2's Data Layer Is Now Complete

Room, Retrofit, and DataStore cover the three data sources a typical Android app actually needs — structured local data, remote data, and simple settings — all wired through the identical repository → Hilt-injected ViewModel → StateFlow → Compose pipeline established since Chapter 3. The final chapter pulls all of this together into one cohesive architecture.

🎯 What's Next

Next chapter — the final chapter of Course 2: MVVM Architecture — the repository pattern, clean architecture basics, and separating concerns across everything built so far.