Why choose DataStore over SharedPreferences for a toggle?

WHAT THIS TESTS: The interviewer wants to know if you evaluate APIs based on thread safety, type correctness, and error handling rather than just ease of use. Even for a single boolean, the choice reveals whether you understand the footguns in SharedPreferences and the production benefits of structured concurrency.

A GOOD ANSWER COVERS: First, call out the threading model. DataStore uses Kotlin coroutines and Flow, so reads and writes are asynchronous by default and do not block the UI thread. SharedPreferences performs synchronous disk I/O on the calling thread and can trigger ANRs. Second, mention type safety. DataStore Preferences offers typed getters and setters, while SharedPreferences relies on string keys and raw primitives with no compile-time guarantees. Third, highlight transactional consistency. DataStore edits are atomic and survive process death cleanly, whereas SharedPreferences commit and apply can leave data in inconsistent states or silently fail. Fourth, note migration and error handling. DataStore provides built-in exception propagation and a migration path from SharedPreferences, which throws no exceptions on parse failures and can corrupt files.

COMMON WRONG ANSWERS: Saying a boolean is too small to matter is a major red flag because SharedPreferences scales poorly and the API design flaws exist regardless of payload size. Claiming DataStore is only for large or complex data misses the point; the API is intentionally lightweight for small key-value sets. Another trap is stating that apply is asynchronous enough; apply merely queues work to the UI thread message queue and still risks ANRs and lost writes.

LIKELY FOLLOW-UPS: The interviewer may ask how you would migrate existing SharedPreferences users to DataStore without losing data, or when you would still use SharedPreferences, such as in legacy inter-process communication or very old minSdk requirements. They might also ask about Proto DataStore versus Preferences DataStore, or how you would expose the dark mode setting as a StateFlow in a ViewModel.

ONE CONCRETE EXAMPLE: Imagine a user toggles dark mode during a configuration change. With SharedPreferences, a synchronous read in Activity onCreate blocks the main thread while the disk is busy, and an apply call might race with process death. With DataStore, you collect a Flow of Boolean in a lifecycle-aware coroutine scope, the read is non-blocking, the write is atomic, and you can handle IOException gracefully instead of silently swallowing it.

Source: developer.android.com