Big Picture: How This App Works

This app has four important files, and each one has a specific job:

• PreferencesManager.kt: reads/writes raw values in DataStore
• DataStoreViewModel.kt: exposes those values as StateFlow for UI
• DataStoreScreen.kt: displays settings and sends user actions to ViewModel
• MainActivity.kt: applies app theme and hosts the screen

When a user changes a setting, the data path is:

1. User taps a control in DataStoreScreen.kt (the Composable UI).
2. The screen calls a function on DataStoreViewModel.kt (for example updateDarkMode(...)). That function is not suspend, so it cannot block the UI thread.
3. The ViewModel starts a coroutine with viewModelScope.launch { ... } and inside that coroutine calls PreferencesManager.kt.
4. PreferencesManager runs dataStore.edit { ... }, which writes the new value to disk and makes DataStore emit a fresh preferences snapshot.
5. The Flow that reads dark mode in PreferencesManager emits the new boolean. The ViewModel had already turned that Flow into StateFlow with stateIn, so darkMode updates for all observers.
6. Compose screens that use collectAsState() on that StateFlow recompose: text and switches show the new value, and MainActivity.kt can rebuild MaterialTheme so colors actually change.

Example walkthrough

Suppose the user turns dark mode on.

Step 1 — DataStoreScreen.kt: the user acts, and the screen forwards the request

The settings screen has two jobs at once. First, it shows the latest values from the ViewModel so the switch and labels match what is saved. Second, when the user changes something, it tells the ViewModel to save the new value. For dark mode, the screen collects darkMode from the ViewModel and wires the switch so a tap calls updateDarkMode with the new on/off value (it).

val darkMode by viewModel.darkMode.collectAsState()

Switch(
    checked = darkMode,
    onCheckedChange = { viewModel.updateDarkMode(it) }
)

collectAsState() is how Compose listens to the ViewModel. When the value changes later (after DataStore updates), this line causes the screen to redraw so the switch and text stay correct. The Switch line does not save anything by itself; it only calls the ViewModel. Saving happens in the next steps.

Step 2 — DataStoreViewModel.kt: run the save off the UI thread

The function updateDarkMode(enabled) is written so the Composable can call it from a click handler without waiting. It uses viewModelScope.launch { ... } to start a coroutine: a piece of work that can run while the UI stays responsive. Inside the coroutine it calls preferencesManager.updateDarkMode(enabled), which actually talks to DataStore.

fun updateDarkMode(enabled: Boolean) {
    viewModelScope.launch {
        preferencesManager.updateDarkMode(enabled)
    }
}

viewModelScope is tied to the ViewModel's lifetime. If the user leaves the screen and the ViewModel is cleared, work started here is cancelled so you do not leave stray background tasks running. launch means "start this work; return right away from updateDarkMode" so the main thread is not blocked.

Step 3 — PreferencesManager.kt: keys, file, read path, and write path

This class is the only place that knows how DataStore is set up. It defines keys (like DARK_MODE) and gets a single DataStore instance via preferencesDataStore(name = "simple_preferences"), so all reads and writes go to one private file for this app on the device (see Where the file lives and how to see it for how to open that folder in Android Studio).

Reading uses dataStore.data, which is a Flow: whenever preferences change, a new snapshot is emitted. The code maps that snapshot to a boolean and supplies a default if the key was never set (?: false), so the first launch behaves predictably.

val darkMode: Flow<Boolean> = context.dataStore.data.map { preferences ->
    preferences[PreferencesKeys.DARK_MODE] ?: false
}

Writing uses dataStore.edit { ... }. That block is a small transaction: you get a mutable preferences object, set the key, and when the block ends DataStore commits the change safely. If several keys were updated in the same block, they would commit together. edit is a suspend function, so it can do I/O without blocking the UI thread when called from the coroutine the ViewModel started.

suspend fun updateDarkMode(enabled: Boolean) {
    context.dataStore.edit { preferences ->
        preferences[PreferencesKeys.DARK_MODE] = enabled
    }
}

After edit finishes, DataStore updates storage and dataStore.data emits again. That is how the “read” Flow learns the new value automatically; you do not call read and write as two separate manual steps in the UI.

Step 4 — DataStoreViewModel.kt again: from Flow to StateFlow

The PreferencesManager exposes darkMode as a Flow<Boolean>. Flows are great for storage, but the UI layer wants a value that always has a “current” setting and updates in one place. The ViewModel converts the Flow into StateFlow using stateIn(...): it collects the Flow in viewModelScope, uses SharingStarted.Lazily so collection starts when something needs it, and passes an initial value (here false) until DataStore delivers the first real read.

val darkMode: StateFlow<Boolean> = preferencesManager.darkMode.stateIn(
    viewModelScope,
    SharingStarted.Lazily,
    false
)

When step 3’s edit completes and the Flow emits, this StateFlow updates. Both DataStoreScreen and MainActivity observe the same StateFlow, so they stay in sync without duplicating DataStore code.

Step 5 — DataStoreScreen.kt and MainActivity.kt: the UI catches up

When the StateFlow updates, any Composable that used collectAsState() on viewModel.darkMode recomposes. In DataStoreScreen, the switch position and the “Dark Mode: Enabled/Disabled” text refresh.

MainActivity does the same collection for theme: it reads darkMode, picks darkColorScheme() or lightColorScheme(), and wraps the app in MaterialTheme(colorScheme = ...). That is what actually changes backgrounds and colors app-wide. The project also uses SideEffect with WindowCompat so status bar icons stay visible against light or dark backgrounds (import androidx.core.view.WindowCompat in the real file).

val viewModel: DataStoreViewModel = viewModel()
val darkMode by viewModel.darkMode.collectAsState()
val colorScheme = if (darkMode) darkColorScheme() else lightColorScheme()

SideEffect {
    WindowCompat.getInsetsController(window, window.decorView)
        .isAppearanceLightStatusBars = !darkMode
}

MaterialTheme(colorScheme = colorScheme) {
    DataStoreScreen(viewModel = viewModel)
}

Putting it together: step 1 sends the new boolean to the ViewModel; steps 2–3 persist it; step 4 pushes the new value through StateFlow; step 5 redraws the settings screen and the whole theme. One toggle both saves to disk and updates what you see.

Where the file lives and how to see it in Android Studio

When PreferencesManager calls dataStore.edit { ... }, DataStore updates a binary preferences file under your app’s private internal storage on the device or emulator. The file is not part of your source tree next to PreferencesManager.kt; it is created at runtime when the app first saves data.

For this demo, the delegate uses preferencesDataStore(name = "simple_preferences"). On disk, Preferences DataStore typically stores that as a file named like simple_preferences.preferences_pb inside a datastore folder under the app’s files directory.

To show students the file in Android Studio (use an emulator or a debuggable device for the simplest path):

1. Install and run the app so it has written at least one preference.
2. Open View → Tool Windows → Device File Explorer (or Device Explorer in some Android Studio versions).
3. Select your emulator or device, then navigate to: /data/data/<your.package.name>/files/datastore/ (replace <your.package.name> with the app’s application ID, for example com.example.datastoredemo).
4. Look for simple_preferences.preferences_pb (or a similarly named .preferences_pb file). You can confirm the file exists and that its timestamp or size changes after you change settings in the app.

The file is not plain text (it is a protobuf-backed format), so you will not show students readable key-value lines inside it. The point of the demo is to prove that persistence is a real file on the device, not that you edit that file by hand. Browsing /data/data/... is easiest on the emulator; access on physical devices may be restricted.

What to Test in This App

1. Change user name, font size, dark mode, and notifications
2. Close the app fully
3. Open the app again
4. Verify all values are restored from DataStore
5. Verify dark mode still controls the app color scheme after restart
6. Optional: in Device File Explorer, open .../files/datastore/simple_preferences.preferences_pb and confirm the file exists after the app has saved settings