Why choose DataStore over SharedPreferences for a toggle?
This tests your grasp of modern Android storage safety beyond syntax. A strong answer names DataStore's async coroutines API, type safety, transactions, and migration support. A red flag is claiming SharedPreferences is simpler while ignoring ANR risk.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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.
A 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.
Interview question
Why is it risky to choose SharedPreferences for a single boolean toggle simply because the data size is small?
- a.SharedPreferences is simpler to use, so the reduced boilerplate justifies ignoring potential thread-blocking issues
- b.SharedPreferences.apply() is asynchronous enough to avoid ANRs when saving tiny values
- c.DataStore is designed only for large or complex data, so using it for one boolean is unnecessary overhead
- d.SharedPreferences still performs synchronous disk I/O that can block the UI thread and trigger an ANR regardless of payload sizeCorrect
Why? this is the answer
SharedPreferences performs synchronous disk I/O on the calling thread, so even a single boolean can trigger an ANR. Claiming apply() is asynchronous enough is wrong because it still queues work to the UI thread and risks lost writes.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles