Android Studio Data Binding Pro Tips

Using Android Studio Code Templates and Live Templates to improve Data Binding support

Data Binding is proving to be a really useful tool. Android Studio support is already pretty robust and steadily improving but there are still a few little annoyances. This post is for developers that have already decided to use Data Binding and are looking for some ways to iron out some of the remaining wrinkles within Android Studio.

If you would like to learn more about Data Binding, GDE Lisa Wray has posted a great video and also been featured in an episode of the Fragmented podcast. Google’s official documentation is also quite thorough.

Root Layout Tag

When you create a new layout resource file in Android Studio, a Code Template will auto create your root ViewGroup xml node along with the xml namespace that Android requires. But Data Binding requires that you place a layout node as your root node. It can get frustrating repeatedly wrapping your ViewGroup in a new layout tag and then pulling the xml namespaces up into this new layout tag. Fortunately Android Studio allows us to modify this default Code Template so we can auto wrap each new resource file with a layout tag. The Code Templates we care about are located at: Preferences →Editor →File and Code Templates →Click the far right tab “Other”. You’ll want to edit the contents of layoutResourceFile and layoutResourceFile_vertical.

Location of Code Template in Preferences

Select the existing template and modify its contents to include the layout node. I also like to include the data node. This is what I use for layoutResourceFile:

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
  <data>
  </data> 
  <${ROOT_TAG} android:layout_width="${LAYOUT_WIDTH}"
               android:layout_height="${LAYOUT_HEIGHT}">
  
  </${ROOT_TAG}>
</layout>

You might find it useful to go ahead and add the tools and app namespaces as well. But keep in mind that adding these namespaces on-demand is already pretty painless using the built-in Live Templates (appNs and toolsNs). Speaking of Live Templates, we can create our own Live Templates to smooth out another DataBinding wrinkle…

Data Binding Variables

Variables require you to provide a name and a type. type requires the full class name of your model like this:

<variable name="mainViewModel"
          type="com.mjordan.example.MainViewModel"/>

But in the above example, if you just type “MainViewModel” for the type then Android Studio won’t know what you’re talking about — you receive no auto-complete assistant. If you begin typing with “com” then you’ll get some help for the next segment in the path but this whole process can be a little tedious. However, using Live Templates we can leverage some built-in scripts to provide the smart type chooser dialog shown below:

Selecting this entry in the dialog will populate the full class name in our type attribute. Adding this new Live Template is pretty easy. Navigate to Live Templates in Preferences (located just under the above mentioned Code Templates). Add a new template and give it a name like “dbvar” with the template text:

<variable name="$name$"
          type="$type$"/>

Beneath the template text, click “Applicable In” and select XML. Next click “Edit variables” button on the right of the template text to assign some logic to your variables (the $ enclosed names, here we’re using “name” and “type”). In the “Expression” column, select camelCase(String) for name and classNameComplete() for type.

Edit Live Template Dialog in Preferences

Now when you type “dbvar” from within a layout file, the variable node will be written and the cursor placed on name. After entering a name and pressing enter the cursor will move to the type attribute and bring up the smart class name chooser including filtering and auto-complete. You can add another Live Template for imports following the same idea.

Custom Binding Adapters

Custom Binding Adapters or Custom Setters are a powerful mechanism to add some new functionality. But when you see app:someAttributeName in a layout file you can’t immediately discern whether it’s calling a public setter on one of the View’s properties or if it’s calling a binding adapter defined somewhere in the project. Unfortunately there’s no “go to definition” support from Android Studio to help, and this situation can become a little troublesome for other developers to debug. I don’t know of a silver bullet for this use-case, but I have found that using a naming convention for the binding adapters in your project can help a lot. Specifically, I prefix mine with “ba_”. That way when developers see app:ba_imageUrl or app:ba_goneUnless it’s immediately apparent to them that this line of code is calling into a custom binding adapter.

When you’re writing a layout file and you want to use one of your custom binding adapters, there’s also no auto-complete support. Fortunately you’ll get compile-time errors if you misspell the binding adapter name. You can consider adding more Live Templates to ease the usage of binding adapters that you find are likely to be used from any layout file.

I expect the Data Binding support in Android Studio to continue to mature, but in the meantime its nice to be using an IDE that enables us to build some of our own helpers.