Android Data Binding: Tips & Tricks

Written by: on March 20, 2018

Why Use Data Binding?

First introduced at Google I/O in 2015, Data Binding brought much excitement to Android developers. Because accessor methods can be placed directly into the xml, it allows for less boilerplate code, more testing, and direct object usage. Data binding has been around for other platforms for some time now, and it only made sense to bring it to Android.

Before we get into some tips and tricks, take the time to make sure that you have your objects and project setup correctly. Since some of our work here at POSSIBLE Mobile is with sports apps, I’m going to use a Team object as the view model like so:

Making Your Code Testable and Readable

Developers are human and they do make mistakes, however, tests can catch them before it’s too late. With data binding and view models, your code becomes testable at the view level, allowing for issues to be found sooner, especially when you start to refactor.

Say goodbye to

and say hello to view models and data binding!

In Team.java:

In view_sample_view.xml:

It’s no contest that ternary operators are a great tool for one line if statements, and as an added bonus, they can be used directly in xml with Data Binding. Here’s an example of showing the primary logo when the team is home, but notice how it is more difficult to read the more boolean checks you add. The only thing testable from the Team class would be correctly setting your data and boolean.

Even though the previous example with the ternary operator will work, it is never a bad idea to have tests for your code. Also, since The Android framework has been extensively tested, there should be no Android code in your view model. The tests should only focus on the code specific to your code base.

Data Binding with Binding Adapters

When moving your logic to your view model, know that some caveats exist. One such caveat is using a drawable id from your model for an image source. This is because the xml tag "android:src” expects a fully qualified and resolved drawable source, which is where a custom binding can come into play. BindingAdapter annotations can be quite helpful and can even provide a solution to returning drawable ids. An example of the custom binding for drawables follows:

In the example above, notice that the first parameter is ImageView, which means that the adapter will only work with that type. The great thing about binding adapters is that you can pretty much do anything you can imagine. For example, let’s say you want to change the dimension of a generic view dynamically based on data returned. In that case, you would want to make sure that the first parameter would be View view so that any view that extends the View class could be used.

When you want to use one of your binding adapters, make sure that the xml code knows where to find your attribute. Using the above adapter in the following example, I would need app:src or bind:src instead of the normal android:src. The above example only has one attribute (“src”), but you can have more than one, just be aware that the view will not use your binding adapter unless all attributes have been used.

Using the Same Model Instance

Another favorite use case of mine is passing the view model to another layout through <includes>. We’ve all been at the point where a complicated layout can get up to a ridiculous number of lines, or sections of it will be reused, and that’s where this useful pattern can help. An example of this is below (all layouts have the same variable declaration):

The above code allows for the same instance and state of the SharedViewModel object to be used between the different layouts included. However, when passing a view model through an includes tag, the included layout’s root view cannot be because the object won’t exist after inflation (a view model object cannot be bound to a non-existent merge object).

Take these tips, go forth, and make your data binding more useful, readable, and testable. Remember, just because you can put ternary operators in xml, doesn’t mean that you should if you want the code to be less confusing and more readable. This article only goes into some very basic concepts of Data Binding, but so much more is possible, even two-way databinding.

Krista Horn

Krista Horn

Krista Horn is an Android Developer at POSSIBLE Mobile. When she’s not writing code, you can find her enjoying music and playing in the mountains.
Article


Add your voice to the discussion: