Advanced Data Binding in Android: Observables
Learn how to use the Data Binding Library to bind UI elements in your XML layouts to data sources in your app using LiveData and StateFlow.
Version
- Kotlin 1.5, Android 4.4, Android Studio 2020.3.1

The Data Binding Library was built with observability in mind, a pattern that’s become quite popular in mobile app development.
Observability comes as a complement to data binding, whose basic concept just considers your view and data objects. However, it’s through this pattern that your data can automatically propagate its changes to the view. This removes the need to manually update your views whenever new data is available, thus simplifying your codebase and reducing boilerplate code.
In this tutorial, you’ll learn how to bind observable data sources in your layout. You’ll build the registration screen for SweatBar, a gym app. During the process, you’ll learn how to:
- Set up observable data sources with both
LiveData
andStateFlow
. - Make different types of data observable, including simple types, collections and objects.
- Transform data from other sources and expose them to your layouts.
Getting Started
Download the materials using the Download Materials button at the top or bottom of this tutorial. Open Android Studio and import the starter project.
Take a moment to familiarize yourself with the code. The main files are the following:
-
MainActivity.kt: An
Activity
where the user inputs their information to register. You’ll find this class in the livedata and stateflow packages. Both files are mostly the same, and you’ll only run one of them at any given time during this tutorial. -
MainViewModel.kt: A
ViewModel
that contains the UI’s data. Similar toMainActivity
, you’ll find this class in the livedata and stateflow packages. Both files are mostly the same, and you’ll only use one of them at any given time during this tutorial. - Session.kt: An Enum class with the different types of sessions a user can register for.
- PhoneNumber.kt: A model that represents a phone number.
- activity_main_*.xml: A layout file with the registration fields.
Build and run. You’ll see a screen where the user can input information to register. The UI doesn’t do much at the moment. You’ll work on improving that in the next sections!
Observing Data Sources
When the Data Binding Library was shipped, it included observable classes for simple types, like ObservableBoolean
, ObservableInt
and ObservableDouble
, as well as the generic ObservableField
. These observable fields came with lifecycle-aware observability baked into them, as the Data Binding Library only updated View
s when they were active.
Years later, the Jetpack Architecture components introduced another observable class, LiveData
. In addition to being lifecycle-aware, it also supports transformations and other Architecture components, like Room and WorkManager, which is why using LiveData
instead of the observable fields is now recommended.
Enabling Data Binding
You’ll now enable data binding in the project. Open the app’s build.gradle file. Inside the buildFeatures
block, replace // TODO: enable data binding
with the following:
buildFeatures {
...
dataBinding true
}
Click Sync Now to sync the project with the Gradle file. You’re all set up!
Observing With LiveData
Start by setting up data binding in the Activity
and XML layout.
Open activity_main_livedata.xml. Remove the TODO
at the top of the file, then wrap the root ScrollView
in a layout
tag and import MainViewModel
, which you’ll use for data binding:
<layout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools">
<data>
<variable
name="viewmodel"
type="com.raywenderlich.android.databindingobservables.livedata.MainViewModel" />
</data>
<ScrollView...>
</layout>
Also, remove the following lines from the ScrollView
as they are provided by the layout
tag:
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
Open MainActivity.kt, and replace // TODO: Set up data binding
with the following:
val binding = DataBindingUtil.setContentView<ActivityMainLivedataBinding>(
this,
R.layout.activity_main_livedata
) // 1
binding.lifecycleOwner = this // 2
binding.viewmodel = viewModel // 3
Finally, make sure the following imports are at the top of the Activity:
import androidx.databinding.DataBindingUtil
import com.raywenderlich.android.databindingobservables.databinding.ActivityMainLivedataBinding
The code above sets:
- The content view of
MainActivity
. -
MainActivity
as theLifecycleOwner
to use for observing data in the binding. This controls when observing data starts and stops. - The variable
viewmodel
of typeMainViewModel
you defined above in the layout file.
With this set up, you’re now ready to connect the app’s data sources to its UI!
Observing Simple Types
Simple types include primitive types such as Boolean
, Int
and Float
as well as String
. They aren’t observable by default, but an XML layout can observe them by simply wrapping them in LiveData
. Emitting a new value through LiveData
propagates it to the UI layout.
The registration form includes fields for the user’s first name, last name and email, which are all String
s. You’ll add corresponding data sources for them in MainViewModel.kt. Open MainViewModel.kt and replace // TODO: Add first name, last name and email
with:
val firstName = MutableLiveData(DEFAULT_FIRST_NAME)
val lastName = MutableLiveData(DEFAULT_LAST_NAME)
val email = MutableLiveData(DEFAULT_EMAIL)
Now, open activity_main_livedata.xml and use these newly created observable fields in the EditTexts with the matching ids below:
<EditText
android:id="@+id/firstNameEditText"
...
android:text="@={viewmodel.firstName}" />
<EditText
android:id="@+id/lastNameEditText"
...
android:text="@={viewmodel.lastName}" />
<EditText
android:id="@+id/emailEditText"
...
android:text="@={viewmodel.email}" />
In the code above, you’re binding the value of the user’s first name, last name and email, respectively, to MainViewModel‘s firstName
, lastName
and email
fields. This means that, for example, as the user updates their first name on the registration form, the value of firstName
updates at the same time. The opposite is also valid: If firstName
‘s value changes, it’s reflected in the UI. This is called two-way binding.
Omitting the =
sign and only writing @{viewmodel.firstName}
makes it a one-way binding instead, going from the firstName
field to the UI. This means that as the user updates the first name on the registration form, firstName
‘s value remains the same.
Observing Collections
Usually, collections hold data in an app. Think of lists of users or products and dictionaries of key/value preferences. Making a collection of data observable is similar to simple data — you just wrap it in LiveData
.
The registration form you’re building should let the user pick the sessions they plan to enroll in. The Session
enum class defines the different possible sessions users can pick from. If the user is an early bird and selects the MORNING
session, you’ll store this information in a map: {MORNING: true}
. When the user finishes the registration, this map will contain the sessions the user opted into and out of.
Open MainViewModel.kt, and replace // TODO: Add sessions
with the following:
val sessions = MutableLiveData<EnumMap<Session, Boolean>>(
EnumMap(Session::class.java)
).apply { // 1
Session.values().forEach { value?.put(it, false) } // 2
}
If the IDE hasn’t done already, import these classes:
import java.util.EnumMap
import com.raywenderlich.android.databindingobservables.model.Session
Here’s what is happening doing in the code above:
- A map with keys of type
Session
and values of typeBoolean
is created.EnumMap
is a map optimized for enum keys. - The map is populated with all the possible sessions and setting their value to
false
, since by default the user isn’t enrolled in any sessions.
Next, bind sessions
to the UI. Open activity_main_livedata.xml, locate the session Chip
s at the bottom of the file and update them as follows:
<com.google.android.material.chip.Chip
android:id="@+id/morningSessionChip"
...
android:checked="@={viewmodel.sessions[Session.MORNING]}" />
<com.google.android.material.chip.Chip
android:id="@+id/afternoonSessionChip"
...
android:checked="@={viewmodel.sessions[Session.NOON]}" />
<com.google.android.material.chip.Chip
android:id="@+id/eveningSessionChip"
...
android:checked="@={viewmodel.sessions[Session.EVENING]}" />
<com.google.android.material.chip.Chip
android:id="@+id/nightSessionChip"
...
android:checked="@={viewmodel.sessions[Session.NIGHT]}" />
In the code above, you’re binding the state of Chip
, whether it’s checked or not, with the sessions
field. When the user selects MORNING
, the value of the key MORNING
in the sessions map is set to true
. Its value becomes false
when the user deselects MORNING
.
Before moving on, you may have noticed a compile error. This is because the XML layout doesn’t recognize the Session
enum. To fix this, import the enum into your XML layout file as follows:
<data>
<import type="com.raywenderlich.android.databindingobservables.model.Session" />
...
</data>
Once the enum is imported into the layout, the errors will disappear since it now knows what Session
is referring to.
Observing Objects
An object isn’t observable by default. Even if you wrap it in LiveData
, it still isn’t observable, meaning that if any attribute in that object changes, it doesn’t trigger the LiveData
to emit the change. For an object to notify its observers when its attributes change, it must implement the Observable
interface.
The Data Binding Library provides BaseObservable
, a convenience class that implements the Observable
interface and makes it easier to propagate changes to the class’s properties. This makes them usable directly from a layout file.
As part of the registration, the user must provide their phone number, which contains two parts: the area code and the rest of the number. This data structure is represented by PhoneNumber
.
The first step to make PhoneNumber
observable is to have it extend the BaseObservable
class. Open PhoneNumber.kt, and update it as follows:
class PhoneNumber: BaseObservable() {
...
}
You’ll also need to import the following if the IDE hasn’t informed you:
import androidx.databinding.BaseObservable
Whenever any of the class’s properties change, it must notify its observers. Replace the TODO
in this file with the following:
class PhoneNumber : BaseObservable() {
@get:Bindable // 1
var areaCode: String = ""
set(value) {
field = value
notifyPropertyChanged(BR.areaCode) // 2
}
@get:Bindable
var number: String = ""
set(value) {
field = value
notifyPropertyChanged(BR.number)
}
}
Also import the following if the IDE doesn’t inform you:
import androidx.databinding.Bindable
import com.raywenderlich.android.databindingobservables.BR
Here’s what’s happening in the code above:
- You annotate
areaCode
with theBindable
annotation. This lets the Data Binding Library generate an entry for it in a class, BR.java. This entry is a static immutable integer field of the same name,areaCode
, and it identifies whenPhoneNumber
‘sareaCode
field changes. - When
areaCode
‘s value changes, you propagate the change to notify any observers. You do this by usingareaCode
‘s generated field in BR.java.
You’ll notice compile errors in PhoneNumber.kt, since the compiler can’t find BR
‘s fields yet. Rebuild the project, and the Data Binding Library will generate the BR
class with the appropriate fields.
It’s time to use this class. Open MainViewModel.kt, and replace // TODO: Add phone number
with the following:
val phoneNumber = PhoneNumber()
Make sure to import the following if the IDE hasn’t done so:
import com.raywenderlich.android.databindingobservables.model.PhoneNumber
Now, bind this new instance to the UI. Open activity_main_livedata.xml, locate the phone number’s EditText
fields, and update them as follows:
<EditText
android:id="@+id/phoneNumberAreaCodeEditText"
...
android:text="@={viewmodel.phoneNumber.areaCode}" />
<EditText
android:id="@+id/phoneNumberEditText"
...
android:text="@={viewmodel.phoneNumber.number}" />
Now, as you edit the phone number in the registration form, it also updates the corresponding instance in MainViewModel
.
Transforming a Single Data Source
As previously mentioned, using LiveData
over the old observable fields offers the option of using transformations. The data source your UI observes can itself observe another data source. That could be another data source the UI is observing or even data streams from other components, like a database. Your data source can then transform data it receives before preparing data for the UI and emitting it.
In the registration form, once the user inputs their email address, you’ll use it to both generate and display their username. You’ll use LiveData
‘s Transformations API to accomplish this.
Open MainViewModel.kt, and replace // TODO: Add username
with the following:
val showUsername: LiveData<Boolean> = Transformations.map(email, ::isValidEmail)
val username: LiveData<String> = Transformations.map(email, ::generateUsername)
Make sure to import the following:
import androidx.lifecycle.Transformations
import com.raywenderlich.android.databindingobservables.utils.isValidEmail
In the code above:
- You use the
email
property, which is aLiveData
instance, to control whether to display or hide the username on the UI. When the user’s email is valid,showUsername
emitstrue
to show the username. But when the email is invalid,showUsername
emitsfalse
to hide it. - Whenever
email
‘s value changes,generateUsername
uses this latest value to generate a new username, whichusername
then emits.
Now, you’ll use these two fields in your layout. Open activity_main_livedata.xml, locate the username’s TextView
, and update it as follows:
<TextView
android:id="@+id/usernameTextView"
...
android:text="@{@string/username_format(viewmodel.username)}" // 1
android:visibility="@{viewmodel.showUsername ? View.VISIBLE : View.GONE}" /> // 2
Adding the two lines above causes a compile error in your layout file, as the compiler doesn’t know what View
is. Import it at the top of the file:
<data>
<import type="android.view.View" />
...
</data>
In the code above, you:
- Set up a one-way binding between
username
andTextView
‘s text. Whenever a new username is emitted,TextView
‘s text is recomputed.username_format
is just a string resource that formats the username, which it takes as an argument. - Use a ternary operator to show or hide
TextView
depending on the value ofshowUsername
.
Build and run the app, and enter an invalid email address — you’ll see the username doesn’t show up. Now, enter a valid email address — the username is there. Magic!
Transforming Multiple Data Sources
The beauty of LiveData
transformations is that you don’t have to limit yourself to a single source — you can transform multiple sources. AndroidX provides a convenience LiveData
subclass to achieve this, MediatorLiveData
. It can observe multiple sources and perform an operation when any of them emits a new value.
After providing all required information, the user should be able to click REGISTER. Currently, the button is always enabled. Instead, it should be disabled until the user has input all necessary information. This includes the user’s first name, last name and email.
Open MainViewModel.kt, and replace // TODO: Add a way to enable the registration button
with the following:
val enableRegistration: LiveData<Boolean> = MediatorLiveData<Boolean>().apply { // 1
addSources(firstName, lastName, email) { // 2
value = isUserInformationValid() // 3
}
}
Here’s what’s happening in the code above:
- You create a new
MediatorLiveData
instance that emits Booleans:true
to enable the registration button andfalse
to disable it. - You observe the required user information fields:
firstName
,lastName
andemail
. - Whenever the value of any of the fields changes, you emit a new Boolean, indicating whether or not to enable the registration button.
As you may have noticed, isUserInformationValid
always returns false
. Now, update it as follows:
private fun isUserInformationValid(): Boolean {
return !firstName.value.isNullOrBlank()
&& !lastName.value.isNullOrBlank()
&& isValidEmail(email.value)
}
Finally, bind the button’s state to this new field. Open activity_main_livedata.xml, locate the registration button and update it as follows:
<Button
android:id="@+id/registerButton"
...
android:enabled="@{viewmodel.enableRegistration}" // 1
android:onClick="@{(view) -> viewmodel.onRegisterClicked()}" /> // 2
With the code above, you set up:
- A one-way binding between
enableRegistration
and the button’s state. - A click listener on the button that calls
onRegisterClicked
when the button is enabled and the user clicks it.
Check out onRegisterClicked
. It lets MainActivity
display a success dialog and should log the user’s information. getUserInformation
doesn’t do much at the moment, so update its body as follows:
private fun getUserInformation(): String {
return "User information:\n" +
"First name: ${firstName.value}\n" +
"Last name: ${lastName.value}\n" +
"Email: ${email.value}\n" +
"Username: ${username.value}\n" +
"Phone number: ${phoneNumber.areaCode}-${phoneNumber.number}\n" +
"Sessions: ${sessions.value}\n"
}
The code above lets you review the information the user entered. In a real app, you’d probably send this information to the app’s server.
Build and run. Notice the registration button remains disabled until you enter all the required data. When it’s enabled, click it — the registration flow is now complete!
Observing With StateFlow
Instead of using LiveData
, it may make more sense for your app to use data binding with StateFlow
if you’re already using Kotlin and coroutines. This helps keep your codebase more consistent and may provide additional benefits compared to using LiveData
, such as performing asynchronous logic in your data sources with the help of coroutines.
Using StateFlow
as the data binding source looks similar to using LiveData
.
Open AndroidManifest.xml. Comment out intent-filter
from .livedata.MainActivity
and uncomment intent-filter
from .stateflow.MainActivity
as follows:
<!-- LiveData Activity -->
<activity
android:name=".livedata.MainActivity"
...
<!-- <intent-filter>-->
<!-- <action android:name="android.intent.action.MAIN" />-->
<!-- <category android:name="android.intent.category.LAUNCHER" />-->
<!-- </intent-filter>-->
</activity>
<!-- StateFlow Activity -->
<activity
android:name=".stateflow.MainActivity"
...
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
.stateflow.MainActivity
is now the default launcher activity.
Set up data binding in MainActivity.kt and replace // TODO: Set up data binding
with the following:
val binding = DataBindingUtil.setContentView<ActivityMainStateflowBinding>(
this,
R.layout.activity_main_stateflow
)
binding.lifecycleOwner = this
binding.viewmodel = viewModel
Add the following imports:
import androidx.databinding.DataBindingUtil
import com.raywenderlich.android.databindingobservables.databinding.ActivityMainStateflowBinding
Lastly, open activity_main_stateflow.xml, and remove the TODO
at the top of the file. Then, wrap the root ScrollView
in a layout
tag and import MainViewModel
, which you’ll use for data binding.
<layout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools">
<data>
<variable
name="viewmodel"
type="com.raywenderlich.android.databindingobservables.stateflow.MainViewModel" />
</data>
<ScrollView...>
</layout>
Also, remove the following lines from ScrollView
:
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
Observing Simple Types
Like wrapping simple types with LiveData
, you can make your simple typed data observable by wrapping it in StateFlow
. Implement the data sources for the user’s first name, last name and email in MainViewModel.kt. It’ll look like this:
val firstName = MutableStateFlow(DEFAULT_FIRST_NAME)
val lastName = MutableStateFlow(DEFAULT_LAST_NAME)
val email = MutableStateFlow(DEFAULT_EMAIL)
Similar to how you bound these fields to the UI in the LiveData
section, use these fields in activity_main_stateflow.xml as you did in activity_main_livedata.xml:
<EditText
android:id="@+id/firstNameEditText"
...
android:text="@={viewmodel.firstName}" />
<EditText
android:id="@+id/lastNameEditText"
...
android:text="@={viewmodel.lastName}" />
<EditText
android:id="@+id/emailEditText"
...
android:text="@={viewmodel.email}" />
Observing Collections
Similar to wrapping collections with LiveData
, you can make a collection observable by wrapping it in StateFlow
. Like above, implement the sessions data source in MainViewModel.kt.
val sessions = MutableStateFlow<EnumMap<Session, Boolean>>(EnumMap(Session::class.java)).apply {
Session.values().forEach { value[it] = false }
}
Import the following:
import java.util.EnumMap
import com.raywenderlich.android.databindingobservables.model.Session
The code above should look familiar to you: It’s almost the exact code you used to set up sessions
in the LiveData
section. You’ll bind it to the layout the same way you did before. Open activity_main_stateflow.xml and update the chips to use the sessions StateFlow:
<com.google.android.material.chip.Chip
android:id="@+id/morningSessionChip"
...
android:checked="@={viewmodel.sessions[Session.MORNING]}" />
<com.google.android.material.chip.Chip
android:id="@+id/afternoonSessionChip"
...
android:checked="@={viewmodel.sessions[Session.NOON]}" />
<com.google.android.material.chip.Chip
android:id="@+id/eveningSessionChip"
...
android:checked="@={viewmodel.sessions[Session.EVENING]}" />
<com.google.android.material.chip.Chip
android:id="@+id/nightSessionChip"
...
android:checked="@={viewmodel.sessions[Session.NIGHT]}" />
You’ll also need to import the enum at the top of the layout:
<data>
<import type="com.raywenderlich.android.databindingobservables.model.Session" />
...
</data>
Observing Objects
Whether you’re using LiveData
or StateFlow
, the approach to making an object observable remains the same. You’ve already made PhoneNumber
extend BaseObservable
in the previous section. All that’s left is to add a phoneNumber
field in MainViewModel.kt and bind it to the phone number EditText
s in the layout file.
Just like before, open MainViewModel.kt, and replace // TODO: Add phone number
with the following:
val phoneNumber = PhoneNumber()
Open activity_main_stateflow.xml, locate the phone number’s EditText
fields, and update them as follows:
<EditText
android:id="@+id/phoneNumberAreaCodeEditText"
...
android:text="@={viewmodel.phoneNumber.areaCode}" />
<EditText
android:id="@+id/phoneNumberEditText"
...
android:text="@={viewmodel.phoneNumber.number}" />
Transforming a Single Data Source
StateFlow
provides many operators to transform a data source. They let you do much more than just map data — you can also filter, debounce and collect data, to name a few. Compared to LiveData
, you have more control over how you transform your data sources.
For your use case, you’ll only need the mapping operator. You’ll use a convenience method mapToStateFlow
in MainViewModel.kt to generate a username and decide when to show it. Replace // TODO: Add username
with the following:
val showUsername: StateFlow<Boolean> = email.mapToStateFlow(::isValidEmail, DEFAULT_SHOW_USERNAME)
val username: StateFlow<String> = email.mapToStateFlow(::generateUsername, DEFAULT_USERNAME)
You may also need to import the following:
import com.raywenderlich.android.databindingobservables.utils.isValidEmail
As you may have noticed, unlike LiveData
, StateFlow
requires an initial value.
Next, bind these fields in activity_main_stateflow.xml:
<TextView
android:id="@+id/usernameTextView"
...
android:text="@{@string/username_format(viewmodel.username)}" // 1
android:visibility="@{viewmodel.showUsername ? View.VISIBLE : View.GONE}" /> // 2
Finally, add this import to the data tag at the top:
<data>
<import type="android.view.View" />
...
</data>
Build and run. Enter a valid email address, and you’ll see the generated username displays.
Transforming Multiple Data Sources
You can combine multiple data sources and transform their emitted values using — you guessed it — the combine
method! It takes in multiple Flow
s and returns a Flow
whose values are generated with a transform function that combines the most recently emitted values by each flow. Since data binding doesn’t recognize Flow
s, you’ll convert the returned Flow
to a StateFlow
.
In this last step, you’ll set the state of the registration button depending on the required fields: first name, last name and email.
val enableRegistration: StateFlow<Boolean> = combine(firstName, lastName, email) { _ ->
isUserInformationValid()
}.toStateFlow(DEFAULT_ENABLE_REGISTRATION)
Then, import the following:
import kotlinx.coroutines.flow.combine
This should seem similar to what you implemented with LiveData
. You’re observing the first name, last name and email flows, and whenever any of them emit a value, you call isUserInformationValid()
to enable or disable the registration button.
Just like before, update isUserInformationValid()
with the following code:
private fun isUserInformationValid(): Boolean {
return !firstName.value.isNullOrBlank()
&& !lastName.value.isNullOrBlank()
&& isValidEmail(email.value)
}
The last step is binding this field to the state of the registration button and setting its click listener.
Open activity_main_stateflow.xml, and update the register button to look as follows:
<Button
android:id="@+id/registerButton"
...
android:enabled="@{viewmodel.enableRegistration}"
android:onClick="@{(view) -> viewmodel.onRegisterClicked()}" />
You also need to update getUserInformation
:
private fun getUserInformation(): String {
return "User information:\n" +
"First name: ${firstName.value}\n" +
"Last name: ${lastName.value}\n" +
"Email: ${email.value}\n" +
"Username: ${username.value}\n" +
"Phone number: ${phoneNumber.areaCode}-${phoneNumber.number}\n" +
"Sessions: ${sessions.value}\n"
}
Build and run, then play around with the registration form. Once you’ve entered the required data, click the registration button, and the success dialog appears. That’s it — you’ve done it again!
Where to Go From Here?
Download the final project using the Download Materials button at the top or bottom of the tutorial.
Congratulations! You learned how to use one of data binding’s most important features: observability. You saw how to set up your data sources to be observable using either LiveData
or StateFlow
, and you also learned how to make different types of data observable, from primitives to collections and complex objects. Finally, you saw how to set up observable data sources that expose transformed data from other sources.
If you need to brush up on data binding, check out Data Binding in Android: Getting Started. If, instead, you’d like to see how data binding fits in with other architectural patterns in Android, check out MVVM and DataBinding: Android Design Patterns.
We hope you enjoyed this tutorial! If you have any questions or comments, please join the forum discussion below.
Comments