DataStore — small settings

Three numbers do not need a filing cabinet

Focus Flow has exactly three settings: how long a focus round lasts, how long a break lasts, and whether the screen should stay awake.

You could store those in Room. You would define an entity with one row, a DAO to read that one row, a database to hold that one table, and a migration every time you add a fourth setting. It would work, and it would be ridiculous.

Settings are small, few, and always read all at once. They want a different tool.

What DataStore replaced

Android's old answer was SharedPreferences, and it had three problems that were never fixable.

It could block the main thread — the first read of a preferences file happens on whatever thread asks, and a slow disk froze the screen. It reported errors by not reporting them: a failed write returned false, or nothing at all, and most code never checked. And it gave you values one at a time, so you had to ask again every time you wanted to know if something had changed.

DataStore fixes all three. Writes are suspend functions, so they cannot block. Failures throw. And reading gives you a Flow that keeps delivering.

Declaring the store

One line, at the top level of a file — not inside a class:

1private val Context.store: DataStore<Preferences> by
2  preferencesDataStore(name = "settings")

This adds a property called store onto every Context in the file. The by preferencesDataStore(...) part means it is created once, the first time anything reads it, and reused forever afterwards.

That "once" is not a nicety. Two DataStores open on the same file is an error, and declaring it as a top-level property is the mechanism that makes it impossible.

Typed keys

Every setting gets a key, and the key carries the type:

1private object Keys {
2  val FOCUS = intPreferencesKey("focus_minutes")
3  val BREAK = intPreferencesKey("break_minutes")
4  val KEEP_ON =
5    booleanPreferencesKey("keep_screen_on")
6}

intPreferencesKey produces a key that only ever reads and writes an Int. Reading Keys.FOCUS as a Boolean is not a runtime surprise; it is a compiler error. There are matching functions for String, Long, Float, Double and Set<String> — and that is the complete list of what Preferences DataStore can hold.

Reading: a Flow of your own type

The raw flow gives you a bag of key-value pairs. Nobody wants to work with that, so the repository turns each bag into a proper Kotlin object:

The type it produces is an ordinary data class with the defaults written twice — once here, once in the class — which is the one small ugliness of this pattern:

1data class AppSettings(
2  val focusMinutes: Int = 25,
3  val breakMinutes: Int = 5,
4  val keepScreenOn: Boolean = false,
5)

Writing

1suspend fun setFocusMinutes(value: Int) {
2  store.edit { prefs ->
3    prefs[Keys.FOCUS] =
4      value.coerceIn(FOCUS_RANGE)
5  }
6}

edit is suspend, takes a block, and writes the whole file atomically when the block finishes — so a crash halfway through cannot leave half a setting behind.

coerceIn(FOCUS_RANGE) is the interesting line. FOCUS_RANGE is 5..90. The rule about what counts as a sensible focus length lives here, next to the saving, not in the screen. Any future screen — a widget, a voice command, a restored backup — gets the same protection for free.

Getting it to the screen

Nothing new — this is Lesson 4.3, unchanged:

1val settings: StateFlow<AppSettings> =
2  repo.settings.stateIn(
3    scope = viewModelScope,
4    started = SharingStarted
5      .WhileSubscribed(5_000L),
6    initialValue = AppSettings(),
7  )

initialValue = AppSettings() is why the settings screen never flashes blank on open: the defaults are drawn instantly, and the saved values replace them a few milliseconds later.

The same flow also reaches the timer, which watches it and adjusts its lengths. One store, two screens, no message passing.