Android: MVVM + Single Source of Truth Pattern

Reading from android docs of the new Architecture components, I found a new (for me it is new) pattern when using MVVM pattern.

The single source of truth says that: our ViewModel should have only one source of data, and that source should be Room Database (SQLite, or some local database).

It works best with:
ViewModel
LiveData
Room Database

Because ViewModel keep your data from some View layer configuration changes (and more), LiveData let your ViewModel watch for data changes in your database, and Room because it works well with LiveData and RxJava.

Seeing the image, we can understand that: when data is required, we expect it to come from our local database (the source of truth). At the same time, we will get the data from our external server, as soon as we had the data from the server, we sent it to the local database.

The main concept is:

Your local database is the single source of truth and you synchronize data with remote APIs whenever network connection is available.

Because we are using ViewModel + LiveData, our view will be notified without having to do anything. I forgot to mention that we should check for data failure (which we should never forget), and if there is, notify the user, about such failure.

There is also the final diagram, when using the recommended architecture, from Google:

Image by (Google Developers)

Looking at the image, we see that the control and management of the only true source must be done in the Repository layer, because it is the meeting point of the local database and the server.

UPDATE: there is a note that I want to leave here to clarify more about a single source of truth, taken from the official website. After the discussion in the comments:

Single source of truth

“ It’s common for different REST API endpoints to return the same data. For example, if our backend has another endpoint that returns a list of friends, the same user object could come from two different API endpoints, maybe even using different levels of granularity. If the UserRepository were to return the response from the Webservice request as-is, without checking for consistency, our UIs could show confusing information because the version and format of data from the repository would depend on the endpoint most recently called.
For this reason, our UserRepository implementation saves web service responses into the database. Changes to the database then trigger callbacks on active LiveData objects. Using this model, the database serves as the single source of truth, and other parts of the app access it using our UserRepository. Regardless of whether you use a disk cache, we recommend that your repository designate a data source as the single source of truth for the rest of your app”.

Being sincere, I tried and I did not find this implementation easy, but I think it’s worth it. Let me know in comments, what you think about it. Do not forget to read from official site (link bellow).

Read more here:


More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.