Implement Data Binding with Kotlin

Photo by Dan Price on Makeuseof

Android launch Data Binding library for several years. The Data Binding Library offers both flexibility and broad compatibility. You can use it with devices running Android 4.0 (API level 14) or higher. It’s an option to apply since we still can use the local way to write our code. So what’s the benefit to apply it to our project? I would say. It will let our code clean. Let’s see how we implement it.

In build.gradle we can easily enable it by a toggle.

Then no matter what architecture pattern you using (MVC,MVP, or MVVM)

You will have a model like this User.kt

Then in your xml file. Please wrap your view with <Layout></Layout> tag.

And add <data></data> this means you will binding the views and data model together in this activity_user.xml

Then we need build project to generate some component.

Choose Make Project

In UserActivity we claim to bind as lateinit var because it must be inited in onCreate and never be null.

That’s it. The view and data binding together. If the data value changed. the view will automatically change then.

Also support primitive type and String for data in xml.

That’s the basic usage for data binding. Then you might interest that what about load image? This looks like doesn’t work at all. It’s true. Data binding provide some further usage method. I will introduce how to use BindingAdapter.

With ViewModel

If you want to bindLivaData in view model. Remember to add lifecycleOwner . Let’s see the comment from google:

Sets the {@link LifecycleOwner} that should be used for observing changes of
LiveData in this binding. If a {
@link LiveData} is in one of the binding expressions and no LifecycleOwner is set, the LiveData will not be observed and updates to it will not be propagated to the UI.


Here is our requirement. I want a circle avatar. First of all, we create a singleton class UiUtil and implement loadImageInCircle method. It’s implemented by Glide so maybe you need to add dependance in your build.gradle file.

The value means in the xml, we need to define both imageUrl and placeholder. The requireAll means we can just define one of them rather than all. After rebuild, we can use app:imageUrl in xml now. Finally will look like

We don’t need to call loadImageInCircle in our code. Just add one line then we can support circle crop image. :)

Logic in xml

We can also write some logic in xml. Like below isShow is a boolean type to determine the nameTextView show or hide. And we need to import android.view.View in xml data block.

Although we can use this way. But in my personal opinion. I would encourage you to put this kind of logic in Presenter or ViewModel. Because you can write Test to protect your business logic.


In some case, a custom conversion is required between specific types. For example, the android:background expects a Drawable, but the color value specified is an integer. So we can define BindingConversion here.

Then android:background support color now. we can define in our xml.


Let’s wrap up. Here are some pros and cons of data binding.


  • Reduces boilerplate code to make the code base clean.
  • Easy implement custom attrs and custom views.
  • The library extracts the views including the IDs from the view hierarchy in a single pass. This mechanism can be faster than calling the findViewById() method for every view in the layout. (reference)


  • If your data model is nested. you might need to check the null case. Hence, better to create a method in your parent cover the null check.
  • Auto generates class causes the app size to increase.
  • UI isn’t testable if you write business in xml. You should avoid doing that.

Github example: here

An Android developer