Architecture Components: How to use LiveData with Data Binding?

Photo credits: flickr.com

This post was published in Android Weekly #290 issue

Hi! As you may know, in the newest version of Android Studio, Google introduced support for LiveData with Data Binding. Today I’d like to show you briefly how to use it in your project. Let’s start!

Some of you may have seen this topic, where Yigit Boyar made a promise to add support for LiveData in our projects with Data Binding:

And here it comes a cool news — with the newest Android Studio 3.1 Canary 6 version it’s possible! Hooray! 👏🥂🎉

This release includes change in Data Binding that allows you to replace your ObservableField with LiveData in the data binding expressions.

Here’s a step-by-step tutorial on how to do it. You can also check the whole code of this post here:

pszklarska/LiveDataBinding

Setup

What do you need to do? At first, you need to get the newest canary Android Studio version. Then you need to upgrade your Android Gradle plugin version:

buildscript {
    dependencies {
        classpath 'com.android.tools.build:gradle:3.1.0-alpha06'
    }
}

If you use Kotlin, you need to also change databinding compiler version:

kapt 'com.android.databinding:compiler:3.1.0-alpha06'

And that’s it, you’re ready to go!

How to use it?

Now you can replace all your ObservableField with LiveData classes. That was before:

val kittyName = ObservableField<String>()
val kittyAge = ObservableInt()

init {
    kittyRepository.receiveNewKitties {
        kittyName.set(it.name)
        kittyAge.set(it.age)
    }
}

And this is after:

val kittyName = MutableLiveData<String>()
val kittyAge = MutableLiveData<Int>()

init {
    kittyRepository.receiveNewKitties {
        kittyName.postValue(it.name)
        kittyAge.postValue(it.age)
    }
}

To make it work, we need to also tell binding class who’s the LifecycleOwner, so it can track lifecycle properly:

val binding: ActivityMainBinding = ...
binding.setLifecycleOwner(this)

Voilà!

Ok, but what does it change?

You can read more about LiveData in my previous post. In general, with LiveData we don’t need to worry about lifecycle. Data is sent to the UI only when it’s active. In the previous approach (without LiveData) if we wanted to show the data on the UI, we should previously check if it still exists. With LiveData we don’t need to worry about it because data will be posted only if Activity is at least started (so in started or resumed state).

For example, we can set logs both for creating data (e.g. in init() block from MainViewModel class):

init {
    kittyRepository.receiveNewKitties {
        Log.d("MainViewModel", "Generating kitty name: " + it.name)
        ...
    }
}

And the second log for updating data on the UI (e.g. some TextWatcher in MainActivity class):

kittyNameText.addAfterTextChangedListener { Log.d("MainActivity",
    "Showing kitty name: " + it) }

Now, if we’ll put the app without LiveData in the background, we would see:

D/MainViewModel: Generating kitty name: TIGER
D/MainActivity: Showing kitty name: TIGER
D/MainViewModel: Generating kitty name: FLUFFY
D/MainActivity: Showing kitty name: FLUFFY

It means that UI is updated even after the activity is paused. It’s unnecessary, and that’s where LiveData takes care of us. Now if we’ll run the application and put it in the background with the LiveData we’d see:

D/MainViewModel: Generating kitty name: PUMPKIN
D/MainViewModel: Generating kitty name: TIGER

Data is generated, but UI is not updated because the activity is not started or resumed. Great!

That’s it! I hope you liked this post. If you did, don’t forget to 👏 Bye!

In this series there are also:

Android Architecture Components: Room — Introduction

Android Architecture Components: Room — Relationships

Android Architecture Components: Room — Custom Types

Android Architecture Components: Room — Migration

Android Architecture Components: ViewModel

Android Architecture Components: LiveData