ViewModels and LiveData: Patterns + AntiPatterns

Jose Alcérreca
Sep 12, 2017 · 8 min read

Views and ViewModels

Distributing responsibilities

Image for post
Image for post
Typical interaction of entities in an app built with Architecture Components

Ideally, ViewModels shouldn’t know anything about Android. This improves testability, leak safety and modularity. A general rule of thumb is to make sure there are no imports in your ViewModels (with exceptions like). The same applies to presenters.

❌ Don’t let ViewModels (and Presenters) know about Android framework classes

Conditional statements, loops and general decisions should be done in ViewModels or other layers of an app, not in the Activities or Fragments. The View is usually not unit tested (unless you use Robolectric) so the fewer lines of code the better. Views should only know how to display data and send user events to the ViewModel (or Presenter). This is called the Passive View pattern.

✅ Keep the logic in Activities and Fragments to a minimum

View references in ViewModels

ViewModels have different scopes than activities or fragments. While a ViewModel is alive and running, an activity can be in any of its lifecycle states. Activities and fragments can be destroyed and created again while the ViewModel is unaware.

Image for post
Image for post
ViewModels persist configuration changes

Passing a reference of the View (activity or fragment) to the ViewModel is a serious risk. Let’s assume the ViewModel requests data from the network and the data comes back some time later. At that moment, the View reference might be destroyed or might be an old activity that is no longer visible, generating a memory leak and, possibly, a crash.

❌ Avoid references to Views in ViewModels.

The recommended way to communicate between ViewModels and Views is the observer pattern, using LiveData or observables from other libraries.

Observer Pattern

Image for post
Image for post

A very convenient way to design the presentation layer in Android is to have the View (activity or fragment) observe (subscribe to changes in) the ViewModel. Since the ViewModel doesn’t know about Android, it doesn’t know how Android likes to kill Views frequently. This has some advantages:

  1. ViewModels are persisted over configuration changes, so there’s no need to re-query an external source for data (such as a database or the network) when a rotation happens.
  2. When long-running operations finish, the observables in the ViewModel are updated. It doesn’t matter if the data is being observed or not. No null pointer exceptions happen when trying to update the nonexistent View.
  3. ViewModels don’t reference views so there’s less risk of memory leaks.
Typical subscription from an activity or fragment.

✅ Instead of pushing data to the UI, let the UI observe changes to it.

Fat ViewModels

Whatever lets you separate concerns is a good idea. If your ViewModel is holding too much code or has too many responsibilities consider:

  • Moving some logic out to a presenter, with the same scope as the ViewModel. It will communicate with other parts of your app and update the LiveData holders in the ViewModel.
  • Adding a Domain layer and adopting Clean Architecture. This leads to a very testable and maintainable architecture. It also facilitates getting off the main thread quickly. There’s a Clean Architecture sample in Architecture Blueprints.

✅ Distribute responsibilities, add a domain layer if needed.

Using a data repository

As seen in the Guide to App Architecture most apps have multiple data sources, such as:

  1. Remote: network or the Cloud
  2. Local: database or file
  3. In-memory cache

It’s a good idea to have a data layer in your app, completely unaware of your presentation layer. Algorithms to keep cache and database in sync with the network are not trivial. Having a separate repository class as a single point of entry that deals with this complexity is recommended.

If you have multiple and very different data models, consider adding multiple repositories.

✅ Add a data repository as the single-point entry to your data

Dealing with data state

Consider this scenario: you’re observing a LiveData exposed by a ViewModel that contains a list of items to display. How can the View diferentiate between data being loaded, a network error and an empty list?

  • You could expose a from the ViewModel. For example, could contain information about whether the data is currently loading, has loaded successfully or failed.
Image for post
Image for post

You can wrap the data in a class that has a state and other metadata like an error message. See the Resource class in our samples.

✅ Expose information about the state of your data using a wrapper or another LiveData.

Saving activity state

Activity state is the information you need to recreate a screen if an activity is gone, meaning the activity was destroyed or the process was killed. Rotation is the most obvious case and we’ve got that covered with ViewModels. State is safe if it’s kept in the ViewModel.

However, you might need to restore state in other scenarios where the ViewModels are also gone: when the OS is low on resources and kills your process for example.

To efficiently save and restore UI state, use a combination of persistence, and ViewModels.

For an example, see: ViewModels: Persistence, onSaveInstanceState(), Restoring UI State and Loaders

Events

An event is something that happens once. ViewModels expose data, but what about events? For example, navigation events or showing Snackbar messages are actions that should only be executed once.

The concept of an Event doesn’t fit perfectly with how LiveData stores and restore data. Consider a ViewModel with the following field:

LiveData<String> snackbarMessage = new MutableLiveData<>();

An activity starts observing this and the ViewModel finishes an operation so it needs to update the message:

snackbarMessage.setValue("Item saved!");

The activity receives the value and shows the Snackbar. It works, apparently.

However, if the user rotates the phone, the new activity is created and starts observing. When LiveData observation starts, the activity immediately receives the old value, which causes the message to show again!

Instead of trying to solve this with libraries or extensions to the Architecture Components, it should be faced as a design problem. We recommend you treat your events as part of your state.

✅ Design events as part of your state. For more details read LiveData with SnackBar, Navigation and other events (the SingleLiveEvent case).

Leaking ViewModels

The reactive paradigm works well in Android because it allows for a convenient connection between UI and the rest of the layers of your app. LiveData is the key component of this structure so normally your activities and fragments will observe LiveData instances.

How ViewModels communicate with other components is up to you, but watch out for leaks and edge cases. Consider this diagram where the Presentation layer is using the observer pattern and the Data Layer is using callbacks:

Image for post
Image for post
Observer pattern in the UI and callbacks in the data layer

If the user exits the app, the View will be gone so the ViewModel is not observed anymore. If the repository is a singleton or otherwise scoped to the application, the repository will not be destroyed until the process is killed. This will only happen when the system needs resources or the user manually kills the app. If the repository is holding a reference to a callback in the ViewModel, the ViewModel will be temporarily leaked

Image for post
Image for post
The activity is finished but the ViewModel is still around

This leak is not a big deal if the ViewModel is light or the operation is guaranteed to finish quickly. However, this is not always the case. Ideally, ViewModels should be free to go whenever they don’t have any Views observing them:

Image for post
Image for post

You have many options to achieve this:

  • With ViewModel.onCleared() you can tell the repository to drop the callback to the ViewModel.
  • In the repository you can use a WeakReference or you can use an Event Bus (both easy to misuse and even considered harmful).
  • Use the LiveData to communicate between the Repository and ViewModel in a similar way to using LiveData between the View and the ViewModel.

✅ Consider edge cases, leaks and how long-running operations can affect the instances in your architecture.

❌ Don’t put logic in the ViewModel that is critical to saving clean state or related to data. Any call you make from a ViewModel can be the last one.

LiveData in repositories

To avoid leaking ViewModels and callback hell, repositories can be observed like this:

Image for post
Image for post

When the ViewModel is cleared or when the lifecycle of the view is finished, the subscription is cleared:

Image for post
Image for post

There’s a catch if you try this approach: how do you subscribe to the Repository from the ViewModel if you don’t have access to the LifecycleOwner? Using Transformations is a very convenient way to solve this. lets you create a new LiveData that reacts to changes of other LiveData instances. It also allows carrying over the observer Lifecycle information across the chain:

Transformations example [source]

In this example, when the trigger gets an update, the function is applied and the result is dispatched downstream. An activity would observe and the same LifecycleOwner would be used for the call.

✅ Whenever you think you need a Lifecycle object inside a ViewModel, a Transformation is probably the solution.

Extending LiveData

The most common use case for LiveData is using in ViewModels and exposing them as to make them immutable from the observers.

If you need more functionality, extending LiveData will let you know when there are active observers. This is useful when you want to start listening to a location or sensor service, for example.

When not to extend LiveData

You could also use to start some service that loads data, but unless you have a good reason for it, you don’t need to wait for the LiveData to be observed. Some common patterns:

❌ You don’t usually extend LiveData. Let your activity or fragment tell the ViewModel when it’s time to start loading data.


Do you need guidance (or opinions) on any other topic related to the Architecture Components? Let us know in the comments.

Android Developers

The official Android Developers publication on Medium

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store