Android Data Binding

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 set up correctly. Since some of our work here at Wunderman Thompson Apps is with sports apps, I’m going to use a Team object as the view model like so:

public class Team {

	private String teamCity;
	private String teamName;
	private String teamColor;
	@DrawableRes private int teamPrimaryLogo;
	@DrawableRes private int teamSecondaryLogo;
	private boolean isHomeTeam;
	private boolean isNationallyBroadcasted;
	
	...
}

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

TextView myTextView = findViewById(R.id.my_textview);
if (isHomeTeam && !isNationallyBroadcasted) {
	myTextView.setVisibility(View.GONE);
} else {
	myTextView.setVisibility(View.VISIBLE);
}

and say hello to view models and data binding!

In Team.java:

public int getMyTextViewVisibility() {
	return isHomeTeam && !isNationallyBroadcasted ? View.GONE : View.VISIBLE;
}

In view_sample_view.xml:

<...>
<data>
  <variable
       name=”viewModel”
       type=”Team />
</data>
<TextView      
      android:id=”@+id/my_textview”
      …
      android:visibility=”@{viewModel.myTextViewVisibility} />
</…>

It’s no contest that ternary operators are a great tool for one line of 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.

<TextView			
   android:id=”@+id/my_textview”
   …
   android:visibility=”@{isHomeTeam && !isNationallyBroadcasted ? View.GONE : View.VISIBLE}” ></TextView>

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 codebase.

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:

@BindingAdapter("src")
public static void setImageDrawable(ImageView view, @DrawableRes int drawableId) {
	if (drawableId != 0) {
		view.setImageResource(drawableId);
	}
}

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.

<ImageView
                android:layout_width=”wrap_content”
                android:layout_height=”wrap_content”
                ...
                app:src=”@{viewModel.imageResourceHere}”></ImageView>

Using the Same Model Instance

Another favorite use case of mine is passing the view model to another layout. 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):

<layout>
	<data>
		<variable
		name=”viewModel”
		type=”SharedViewModel” ></variable>
	</data>
	<LinearLayout
		… >
		<TextView
			… ></TextView>
		<includes
			layout=”@id/layout_complicated_1”
			bind:viewModel=”@{viewModel}”
			… ></includes>
		<includes
			layout=”@id/another_complicated_layout”
			bind:viewModel=”@{viewModel}”
			… ></includes>
		<... />
	</LinearLayout>
</layout>

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 included 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 Data Binding.