Discover more from MB_Coder Newsletter
Benefits of DataStore over SharedPreferences in Android
DataStore Vs SharedPreferences
A Jetpack-recommended solution for asynchronous data storage, SharedPreferences has several weaknesses which is why DataStore is a replacement for SharedPreferences.
offer some async support but only for getting updates on changed values via its listener.
provides a fully asynchronous API for retrieving and saving data, using the power of Kotlin coroutines and Flow, while reducing the risk of blocking your UI thread.
SharedPreferences API supports synchronous work out of the box
sharedPreferencesEditor.commit() // used for storage synchronously
its synchronous commit function for modifying persisted data may appear safe to call on the UI thread, but it does in fact perform heavier I/O operation
DataStore doesn't offer ready-to-use synchronous support. DataStore saves the preferences in a file and under the hood performs all data operations in the background, unless specified otherwise, keeping your UI thread unblocked.
SharedPreferences can throw parsing errors as runtime exceptions, leaving your app vulnerable to a crash.
DataStore provides a way of catching any exception coming your way when reading or writing data by relying on flow's error-signaling mechanism.
using map key-value pairs for saving and retrieving data doesn't offer the type of safety protection.
proto DataStore you can define a schema for your data model and get the added benefit of full type safety.
SharedPreferences don't guarantee data consistency in a multithreaded environment.
DataStore is a fully transactional API that provides strong consistency guarantees, as the data is updated in an atomic read, modify, write operation. It also provides read after write consistency, reflecting the fact that all updates that have been completed will be reflected in reading values.