Android Preferences DataStore vs Existing Room Implementation

Question

I’m new to Android development and I’m about to implement simple Preferences for my app. It appears SharedPreferences is a dead end and has lots of warts, so I’m looking at DataStore (non-Proto) vs Room. Since I ALREADY heavily use Room and LiveData (yes, I know Flow is the new hotness) in my app for other things, is there any benefit to using DataStore too? I understand Room is recommended for large or complex data as I’ve already reviewed the following, but I’m hoping a more seasoned developer can further hit this home for me:

https://android-developers.googleblog.com/2020/09/prefer-storing-data-with-jetpack.html

https://proandroiddev.com/lets-explore-jetpack-datastore-in-android-621f3564b57

https://medium.com/better-programming/jetpack-datastore-improved-data-storage-system-adec129b6e48

Thank you.

Mandle

Why would you be considering a relational database for user preferences at all? – Clerihew

source for “SharedPreferences is a dead end and has lots of warts”? – Intercellular

@Clerihew Because I already have one and I can quickly add one more simple table to store these things versus the datastore libraries? I don’t know if this is the right answer, but this is my current train of thought. – Mandle

@squirrel, see the first URL I posted: * SharedPreferences has a synchronous API that can appear safe to call on the UI thread, but which actually does disk I/O operations. Furthermore, apply() blocks the UI thread on fsync(). Pending fsync() calls are triggered every time any service starts or stops, and every time an activity starts or stops anywhere in your application. The UI thread is blocked on pending fsync() calls scheduled by apply(), often becoming a source of ANRs. ** SharedPreferences throws parsing errors as runtime exceptions. – Mandle

@Mandle an ineteresting observation about fsync(), but I'm not sure what the alternatives are. as the app can get killed right after onStop(), you have to ensure that you are done with your writes. in the unlikely event that the data didn't make it to disk already, isn't ANR preferrable to losing it? also, an alternative to runtime exceptions are checked exceptions; not sure how exactly these would be better – Intercellular

Answer 1

The official blog post you linked has a section specifically about Room vs DataStore:

If you have a need for partial updates, referential integrity, or support for large/complex datasets, you should consider using Room instead of DataStore. DataStore is ideal for small , simple datasets and does not support partial updates or referential integrity.

User preferences almost always fall into the 'small, simple datasets' that can be easily expressed as key/value pairs (or something more complicated if you want to use the Proto DataStore) that do not need the overhead of a table schema, SQL queries, custom parsing, or the 'relational' part of a relational database.

Clerihew

I'm aware of what's in the post. I read it to say don't use Room unless you have a specific reason to do so. What is not clear to me is, if I'm already using Room for something else, should I just take advantage of it? Does it make sense not to add all the libraries for DataStore since I'm already leveraging Room in my app? – Mandle

Just because you have a hammer does not make every problem a nail. Choosing the right tool for the job is an important skill to have. – Clerihew

Understood. So, if I understand you correctly, you say it makes more sense to add a second "DataStore" technology to handle just a couple dozen key value pairs even though I already have a data store (Room) that will handle this without issue? – Mandle

You should use the right tool for the job yes. If you look up "SQL vs NoSQL" you'll see the same discussion about not forcing one system into the other. – Clerihew

@Mandle how did you solve your problem and did you regret the choice you made, afterwards? I have exactly the same dilemma now: I already use Room for storing large datasets, and I have to decide whether I should add more dependencies just for storing user preferences. – Dank

@Dank I am simply using Room. At this time, I don’t regret my choice as my needs are simple in this regard. That said, ianhanniballake is the authority here. The only reason I have not yet accepted his answer is because I wanted to hear from another seasoned developer first. – Mandle

@Mandle Now that it's been over a year, mind if I ask for another update? I just had the same decision, and I'm currently going to use Room (as I'm already using it). I'm going to use a static key for a single row. I just think that 2 persistence solutions really doesn't make sense, especially because things like migrations would be fragmented. Any thoughts from the past 1.5 years of experience? – Gadgetry

From the answer, it says DataStore is good when you do not need the overhead of a table schema, but I think adding in another solution would be significantly more overhead by itself, though I agree with ian that choosing the right tool for a job is important. – Gadgetry

Hey @Nathan. Sorry for the delay. In recently coming across buttondown.email/hillelwayne/archive/…, which discusses using the "wrong" tool for the job, it reminded me of your comment. Since my needs for this app are simple, and I don't expect them to grow much, I'm happy with the Room solution. In the future, with a different app perhaps, I might take the DataStore route depending on what's planned for the app. In addition, if I was working with a team, I'd also probably go down the DataStore route. Hope that helps a bit! – Mandle

Thanks @Bink! It's definitely strange using essentially one row for config, but working well for me. I do heavily agree with @Clerihew that "Choosing the right tool for the job is an important skill to have", but think that has to be balanced with increased complexity in your stack with various systems for persistence and migrations. I don't think there's an objectively correct answer here either way, though for a professional app with many developers DataStore likely has many benefits if you're willing to bite the complexity cost. – Gadgetry

Answer 2

The problem with datastore is you cannot just fetch or update a part of data from a list like you can with SQLite libraries such as Room. This is true for both Proto and Preferences version. So if you have 10 thousand elements and you save them to DataStore and then you want to update 2 of them based on a condition you'll have to fetch the entire list, manipulate it and put it back. Here Room (or any DB solution) will be a way to go

But if you just want to save user preferences or small data it would be an overkill to use a DataBase - here DataBase Proto will actually be the perfect choice

Basle