Is there value in persistence beyond offline functionality? I reckon with how well view models are ...

# android-architecture

[Christopher Mederos]

Is there value in persistence beyond offline functionality?

I reckon with how well view models are handled with most navigation and DI libraries today, there wouldn't be too much of a performance benefit to storing/fetching all your data to a database like room or sqldelight first.

I'm curious if others forgo persisting data that is time-sensitive and wouldn't be valuable when offline anyways?

[curioustechizen]

Persistence is not only for offline functionality. It is also for storing data that should be available across process restarts.

[curioustechizen]

Secondly, I don't see persistence as a performance benefit. It also has implications for correctness.

[curioustechizen]

Finally, it often happens that multiple ViewModels depend on a single source of truth for data and that is often convenient to be implemented using persistence (not always, but often).

[Christopher Mederos]

Thanks - those points have gotten me thinking about the topic some more 👍

For your third point - what are some alternatives to using persistence for a single source of truth for multiple viewmodels? I'm curious if we get something useful from kotlin libraries without having to introduce something more complex like the various sqllite libraries

[curioustechizen]

An alternative is just an in-memory "repository" implementation (it could just be a List or Map or whatever depending on your data). Multiple ViewModels can depend on this Repository.

[curioustechizen]

For completeness, SQLite is not the only way to persist data. Depending on the size and structure of your data, you could use other alternatives like SharedPrefs, File storage etc.

[Christopher Mederos]

Thanks @curioustechizen - very helpful talking through all the architecture options!

[alaershov]

For me, persistence should be driven by user experience. In my scooter sharing app the information about the current trip is updated very often, and it would seem that it's not suitable for persistence - the trip cost and distance will be outdated in minutes. But users often have their phone in the pocket, and the probability of process death during the ride is high. And if they open the app again and have to wait for all the data about the current trip to load, it's a waste of their time. Because of that we persist the data about an ongoing trip, so the user can instantly see their trip, and load the most recent data later.