The usecases branch? I wouldn’t recommend it as “best practice” for sure, even the comments say it’s the complete opposite of the recommendations.

Look:

/** Concrete implementation to load tasks from the data sources into a cache. To simplify the sample, this repository only uses the local data source only if the remote data source fails. Remote is the source of truth. */

Which is the opposite of the recommendation outlined by Yigit Boyar, where if you are using a Reactive data layer (which this sample doesn’t — despite the official Jetpack recommendation that says you should), then your disk is the source of truth.

We’re also talking of the same Github repo where they had 1 Activity per each Fragment, and even the Navigation Drawer was using CLEAR_TASK | NEW_TASK to kill the current Activity and load the new one.

It should really not be looked at as some sort of “best practice guide”, manual, nor holy grail.

My favorite tidbit was that a bug in the MVVM samples was masked away by making the boolean completed; field mutable, despite the comment saying this is an immutable class, because the Repository had a bug where it did not update the list properly with new items.

You can find more architecturally interesting samples in https://github.com/android/architecture-components-samples/ they are typically much better in quality.