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.

SharedPreferences

offer some async support but only for getting updates on changed values via its listener.

DataStore

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

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

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

SharedPreferences can throw parsing errors as runtime exceptions, leaving your app vulnerable to a crash.

DataStore

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

SharedPreferences don't guarantee data consistency in a multithreaded environment.

DataStore

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.