This document explains how to use the Data Binding Library to write declarative layouts and minimize the glue code necessary to bind your application logic and layouts.
The Data Binding Library offers both flexibility and broad comnpatibility — it's a support library, so you can use it with all Android platform versions back to Android 2.1 (API level 7+).
To use data binding, Android Plugin for Gradle 1.3.0-beta1 or higher is required.
Please note that the Data Binding library is a beta release. While Data Binding is in beta, developers should be aware of the following caveats:
To get started with Data Binding, download the library from the Support repository in the Android SDK manager.
The Data Binding plugin requires Android Plugin for Gradle 1.3.0-beta1
or higher, so update your build dependencies (in
build.gradle) as needed.
Also, make sure you are using a compatible version of Android Studio. Android Studio 1.3 adds the code-completion and layout-preview support for data binding.
Setting Up Work Environment:
To set up your application to use data binding, add data binding to the class
path of your build.gradle file, right below "android".
dependencies {
classpath "com.android.tools.build:gradle:1.3.0-beta1"
classpath "com.android.databinding:dataBinder:1.0-rc0"
}
}
Then make sure jcenter is in the repositories list for your sub projects.
allprojects {
repositories {
jcenter()
}
}
In each module you want to use data binding, apply the plugin right after android plugin
apply plugin: ‘com.android.application' apply plugin: 'com.android.databinding'
The data binding plugin is going to add necessary provided and compile configuration dependencies to your project.
Data-binding layout files are slightly different and start with a root tag of layout followed by a data element and a view root element. This view element is what your root would be in a non-binding layout file. A sample file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android">
<data>
<variable name="user" type="com.example.User"/>
</data>
<LinearLayout
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{user.firstName}"/>
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{user.lastName}"/>
</LinearLayout>
</layout>
The user variable within data describes a property that may be used within this layout.
<variable name="user" type="com.example.User"/>
Expressions within the layout are written in the attribute properties using
the “@{}” syntax. Here, the TextView’s text is set to the
firstName property of user:
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{user.firstName}"/>
Let’s assume for now that you have a plain-old Java object (POJO) for User:
public class User {
public final String firstName;
public final String lastName;
public User(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
}
This type of object has data that never changes. It is common in applications to have data that is read once and never changes thereafter. It is also possible to use a JavaBeans objects:
public class User {
private final String firstName;
private final String lastName;
public User(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
public String getFirstName() {
return this.firstName;
}
public String getLastName() {
return this.lastName;
}
}
From the perspective of data binding, these two classes are equivalent. The
expression @{user.firstName} used for
the TextView’s android:text attribute will
access the firstName field in the former class
and the getFirstName() method in the latter class.
By default, a Binding class will be generated based on the name of the layout
file, converting it to Pascal case and suffixing “Binding” to it. The above
layout file was activity_main.xml so the generate class was
ActivityMainBinding. This class holds all the bindings from the
layout properties (e.g. the user variable) to the layout’s Views
and knows how to assign values for the binding expressions.The easiest means
for creating the bindings is to do it while inflating:
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
ActivityMainBinding binding = DataBindingUtil.setContentView(this, R.layout.main_activity);
User user = new User("Test", "User");
binding.setUser(user);
}
You’re done! Run the application and you’ll see Test User in the UI. Alternatively, you can get the view via:
MainActivityBinding binding = MainActivityBinding.inflate(getLayoutInflater());
If you are using data binding items inside a ListView or RecyclerView adapter, you may prefer to use:
ListItemBinding binding = ListItemBinding.inflate(layoutInflater, viewGroup, false); //or ListItemBinding binding = DataBindingUtil.inflate(layoutInflater, R.layout.list_item, viewGroup, false);
Zero or more import elements may be used inside
the data element. These allow easy reference to
classes inside your layout file, just like in Java.
<data>
<import type="android.view.View"/>
</data>
Now, View may be used within your binding expression:
<TextView
android:text="@{user.lastName}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:visibility="@{user.isAdult ? View.VISIBLE : View.GONE}"/>
When there are class name conflicts, one of the classes may be renamed to an “alias:”
<import type="android.view.View"/>
<import type="com.example.real.estate.View"
alias="Vista"/>
Now, Vista may be used to reference the
com.example.real.estate.View and
View may be used to reference
android.view.View within the layout file. Imported types may be
used as type references in variables and expressions:
<data>
<import type="com.example.User"/>
<import type="java.util.List"/>
<variable name="user" type="User"/>
<variable name="userList" type="List<User>"/>
</data>
Note: Android Studio does not yet handle imports so the autocomplete for imported variables may not work in your IDE. Your application will still compile fine and you can work around the IDE issue by using fully qualified names in your variable definitions.
<TextView
android:text="@{((User)(user.connection)).lastName}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
Imported types may also be used when referencing static fields and methods in expressions:
<data>
<import type="com.example.MyStringUtils"/>
<variable name="user" type="com.example.User"/>
</data>
…
<TextView
android:text="@{MyStringUtils.capitalize(user.lastName)}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
Just as in Java, java.lang.* is imported automatically.
Any number of variable elements may be used
inside the data element. Each
variable element describes a property that may
be set on the layout to be used in binding expressions within the layout
file.
<data>
<import type="android.graphics.drawable.Drawable"/>
<variable name="user" type="com.example.User"/>
<variable name="image" type="Drawable"/>
<variable name="note" type="String"/>
</data>
The variable types are inspected at compile time, so if a variable implements Observable or is an observable collection, that should be reflected in the type. If the variable is a base class or interface that does not implement the Observable* interface, the variables will not be observed!
When there are different layout files for various configurations (e.g. landscape or portrait), the variables will be combined. There must not be conflicting variable definitions between these layout files.
The generated binding class will have a setter and getter for each of the
described variables. The variables will take the default Java values until
the setter is called — null for reference types,
0 for int, false for
boolean, etc.
By default, a Binding class is generated based on the name of the layout
file, starting it with upper-case, removing underscores ( _ ) and
capitalizing the following letter and then suffixing “Binding”. This class
will be placed in a databinding package under the module package. For
example, the layout file contact_item.xml will generate
ContactItemBinding. If the module package is
com.example.my.app, then it will be placed in
com.example.my.app.databinding.
Binding classes may be renamed or placed in different packages by adjusting
the class attribute of the
data element. For example:
<data class="ContactItem">
...
</data>
This generates the binding class as ContactItem in the
databinding package in the module package. If the class should be generated
in a different package within the module package, it may be prefixed with
“.”:
<data class=".ContactItem">
...
</data>
In this case, ContactItem is generated in the module package
directly. Any package may be used if the full package is provided:
<data class="com.example.ContactItem">
...
</data>
Variables may be passed into an included layout's binding from the containing layout by using the application namespace and the variable name in an attribute:
<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:bind="http://schemas.android.com/apk/res-auto">
<data>
<variable name="user" type="com.example.User"/>
</data>
<LinearLayout
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="match_parent">
<include layout="@layout/name"
bind:user="@{user}"/>
<include layout="@layout/contact"
bind:user="@{user}"/>
</LinearLayout>
</layout>
Here, there must be a user variable in both the
name.xml and contact.xml layout files.
The expression language looks a lot like a Java expression. These are the same:
+ - / * %
+
Logical && ||
& | ^
+ - ! ~
>> >>> <<
== > < >= <=
instanceof
()
null
[]
?:
Examples:
android:text="@{String.valueOf(index + 1)}"
android:visibility="@{age < 13 ? View.GONE : View.VISIBLE}"
android:transitionName='@{"image_" + id}'
A few operations are missing from the expression syntax that you can use in Java.
this
super
new
The null coalescing operator (??) chooses the
left operand if it is not null or the right if it is null.
android:text="@{user.displayName ?? user.lastName}"
This is functionally equivalent to:
android:text="@{user.displayName != null ? user.displayName : user.lastName}"
The first was already discussed in the Writing your first data binding expressions above: short form JavaBean references. When an expression references a property on a class, it uses the same format for fields, getters, and ObservableFields.
android:text="@{user.lastName}"
Generated data binding code automatically checks for nulls and avoid null
pointer exceptions. For example, in the expression
@{user.name}, if user is null,
user.name will be assigned its default value (null). If you were
referencing user.age, where age is an int, then it
would default to 0.
Common collections: arrays, lists, sparse lists, and maps, may be accessed
using the [] operator for convenience.
<data>
<import type="android.util.SparseArray"/>
<import type="java.util.Map"/>
<import type="java.util.List"/>
<variable name="list" type="List<String>"/>
<variable name="sparse" type="SparseArray<String>"/>
<variable name="map" type="Map<String, String>"/>
<variable name="index" type="int"/>
<variable name="key" type="String"/>
</data>
…
android:text="@{list[index]}"
…
android:text="@{sparse[index]}"
…
android:text="@{map[key]}"
When using single quotes around the attribute value, it is easy to use double quotes in the expression:
android:text='@{map["firstName"]}'
It is also possible to use double quotes to surround the attribute value. When doing so, String literals should either use the " or back quote (`).
android:text="@{map[`firstName`}"
android:text="@{map["firstName"]}"
It is possible to access resources as part of expressions using the normal syntax:
android:padding="@{large? @dimen/largePadding : @dimen/smallPadding}"
Format strings and plurals may be evaluated by providing parameters:
android:text="@{@string/nameFormat(firstName, lastName)}"
android:text="@{@plurals/banana(bananaCount)}"
When a plural takes multiple parameters, all parameters should be passed:
Have an orange
Have %d oranges
android:text="@{@plurals/orange(orangeCount, orangeCount)}"
Some resources require explicit type evaluation.
| Type | Normal Reference | Expression Reference |
|---|---|---|
String[] |
@array | @stringArray |
| int[] | @array | @intArray |
| TypedArray | @array | @typedArray |
| Animator | @animator | @animator |
| StateListAnimator | @animator | @stateListAnimator |
color int
|
@color |
@color |
| ColorStateList | @color | @colorStateList |
Any plain old Java object (POJO) may be used for data binding, but modifying
a POJO will not cause the UI to update. The real power of data binding can be
used by giving your data objects the ability to notify when data changes.
There are three different data change notification mechanisms,
Observable objects, ObservableFields, and
observable collections.
When one of these observable data object is bound to the UI and a property of the data object changes, the UI will be updated automatically.
A class implementing android.databinding.Observable interface
will allow the binding to attach a single listener to a bound object to
listen for changes of all properties on that object.
The Observable interface has a mechanism to add and remove
listeners, but notifying is up to the developer. To make development easier,
a base class, BaseObservable, was created to implement the
listener registration mechanism. The data class implementer is still
responsible for notifying when the properties change. This is done by
assigning a Bindable annotation to the getter and notifying in
the setter.
private static class User extends BaseObservable {
private String firstName;
private String lastName;
@Bindable
public String getFirstName() {
return this.firstName;
}
@Bindable
public String getFirstName() {
return this.lastName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
notifyPropertyChanged(BR.firstName);
}
public void setLastName(String lastName) {
this.lastName = lastName;
notifyPropertyChanged(BR.lastName);
}
}
The Bindable annotation generates an entry in the BR class file
during compilation. The BR class file will be generated in the module
package.If the base class for data classes cannot be changed, the
Observable interface may be implemented using the convenient
PropertyChangeRegistry to store and notify listeners
efficiently.
A little work is involved in creating Observable classes, so developers who want to save time or have few properties may use ObservableFields. ObservableFields are self-contained observable objects that have a single field. There are versions for all primitive types and one for reference types. To use, create a public final field in the data class:
private static class User extends BaseObservable {
public final ObservableField<String> firstName =
new ObservableField<>();
public final ObservableField<String> lastName =
new ObservableField<>();
public final ObservableInt age = new ObservableInt();
}
That's it! To access the value, use the set and get accessor methods:
user.firstName.set("Google");
int age = user.age.get();
Some applications use more dynamic structures to hold data. Observable collections allow keyed access to these data objects.ObservableArrayMap is useful when the key is a reference type, such as String.
ObservableArrayMap<String, Object> user = new ObservableArrayMap<>();
user.put("firstName", "Google");
user.put("lastName", "Inc.");
user.put("age", 17);
In the layout, the map may be accessed through the String keys:
<data>
<import type="android.databinding.ObservableMap"/>
<variable name="user" type="ObservableMap<String, Object>"/>
</data>
…
<TextView
android:text='@{user["lastName"]}'
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView
android:text='@{String.valueOf(1 + (Integer)user["age"])}'
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
ObservableArrayList is useful when the key is an integer:
ObservableArrayList<Object> user = new ObservableArrayList<>();
user.add("Google");
user.add("Inc.");
user.add(17);
In the layout, the list may be accessed through the indices:
<data>
<import type="android.databinding.ObservableList"/>
<import type="com.example.my.app.Fields"/>
<variable name="user" type="ObservableList<Object>"/>
</data>
…
<TextView
android:text='@{user[Fields.LAST_NAME]}'
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
<TextView
android:text='@{String.valueOf(1 + (Integer)user[Fields.AGE])}'
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
The generated binding class links the layout variables with the Views within
the layout. As discussed earlier, the name and package of the Binding may be
customized. The Generated binding
classes all extend android.databinding.ViewDataBinding.
The binding should be created soon after inflation to ensure that the View
hierarchy is not disturbed prior to binding to the Views with expressions
within the layout. There are a few ways to bind to a layout. The most common
is to use the static methods on the Binding class.The inflate method inflates
the View hierarchy and binds to it all it one step. There is a simpler
version that only takes a LayoutInflater and one that takes a
ViewGroup as well:
MyLayoutBinding binding = MyLayoutBinding.inflate(layoutInflater); MyLayoutBinding binding = MyLayoutBinding.inflate(LayoutInflater, viewGroup, false);
If the layout was inflated using a different mechanism, it may be bound separately:
MyLayoutBinding binding = MyLayoutBinding.bind(viewRoot);
Sometimes the binding cannot be known in advance. In such cases, the binding can be created using the DataBindingUtil class:
ViewDataBinding binding = DataBindingUtil.inflate(LayoutInflater, layoutId,
parent, attachToParent);
ViewDataBinding binding = DataBindingUtil.bindTo(viewRoot, layoutId);
A public final field will be generated for each View with an ID in the layout. The binding does a single pass on the View hierarchy, extracting the Views with IDs. This mechanism can be faster than calling findViewById for several Views. For example:
<layout xmlns:android="http://schemas.android.com/apk/res/android">
<data>
<variable name="user" type="com.example.User"/>
</data>
<LinearLayout
android:orientation="vertical"
android:layout_width="match_parent"
android:layout_height="match_parent">
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{user.firstName}"
android:id="@+id/firstName"/>
<TextView android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="@{user.lastName}"
android:id="@+id/lastName"/>
</LinearLayout>
</layout>
Will generate a binding class with:
public final TextView firstName; public final TextView lastName;
IDs are not nearly as necessary as without data binding, but there are still some instances where access to Views are still necessary from code.
Each variable will be given accessor methods.
<data>
<import type="android.graphics.drawable.Drawable"/>
<variable name="user" type="com.example.User"/>
<variable name="image" type="Drawable"/>
<variable name="note" type="String"/>
</data>
will generate setters and getters in the binding:
public abstract com.example.User getUser(); public abstract void setUser(com.example.User user); public abstract Drawable getImage(); public abstract void setImage(Drawable image); public abstract String getNote(); public abstract void setNote(String note);
ViewStubs are a little different from normal Views. They start off invisible and when they either are made visible or are explicitly told to inflate, they replace themselves in the layout by inflating another layout.
Because the ViewStub essentially disappears from the View hierarchy, the View in the binding object must also disappear to allow collection. Because the Views are final, a ViewStubProxy object takes the place of the ViewStub, giving the developer access to the ViewStub when it exists and also access to the inflated View hierarchy when the ViewStub has been inflated.
When inflating another layout, a binding must be established for the new layout. Therefore, the ViewStubProxy must listen to the ViewStub's OnInflateListener and establish the binding at that time. Since only one can exist, the ViewStubProxy allows the developer to set an OnInflateListener on it that it will call after establishing the binding.
At times, the specific binding class won't be known. For example, a RecyclerView Adapter operating against arbitrary layouts won't know the specific binding class. It still must assign the binding value during the onBindViewHolder.
In this example, all layouts that the RecyclerView binds to have an "item"
variable. The BindingHolder has a getBinding method returning the
ViewDataBinding base.
public void onBindViewHolder(BindingHolder holder, int position) {
final T item = mItems.get(position);
holder.getBinding().setVariable(BR.item, item);
holder.getBinding().executePendingBindings();
}
When a variable or observable changes, the binding will be scheduled to
change before the next frame. There are times, however, when binding must be
executed immediately. To force execution, use the
executePendingBindings() method.
You can change your data model in a background thread as long as it is not a collection. Data binding will localize each variable / field while evaluating to avoid any concurrency issues.
Whenever a bound value changes, the generated binding class must call a setter method on the View with the binding expression. The data binding framework has ways to customize which method to call to set the value.
For example, an expression associated with TextView's attribute
android:text will look for a setText(String).
If the expression returns an int, data binding will search for a setText(int)
method. Be careful to have the expression return the correct type, casting if
necessary. Note that data binding will work even if no attribute exists with
the given name. You can then easily "create" attributes for any setter by
using data binding. For example, support DrawerLayout doesn't have any
attributes, but plenty of setters. You can use the automatic setters to use
one of these.
<android.support.v4.widget.DrawerLayout
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:scrimColor="@{@color/scrim}"
app:drawerListener="@{fragment.drawerListener}"/>
Some attributes have setters that don't match by name. For these
methods, an attribute may be associated with the setter through
BindingMethods annotation. This must be associated with a class and contains
BindingMethod annotations, one for each renamed method. For example, the
android:tint attribute is really associated
with setImageTintList, not setTint.
@BindingMethods({
@BindingMethod(type = "android.widget.ImageView",
attribute = "android:tint",
method = "setImageTintList"),
})
It is unlikely that developers will need to rename setters; the android framework attributes have already been implemented.
Some attributes need custom binding logic. For example, there is no
associated setter for the android:paddingLeft
attribute. Instead, setPadding(left, top, right, bottom) exists.
A static binding adapter method with the BindingAdapter
annotation allows the developer to customize how a setter for an attribute is
called.
The android attributes have already had BindingAdapters created.
For example, here is the one for paddingLeft:
@BindingAdapter("android:paddingLeft")
public static void setPaddingLeft(View view, int padding) {
view.setPadding(padding,
view.getPaddingTop(),
view.getPaddingRight(),
view.getPaddingBottom());
}
Binding adapters are useful for other types of customization. For example, a custom loader can be called off-thread to load an image.
Developer-created binding adapters will override the data binding default adapters when there is a conflict.
You can also have adapters that receive multiple parameters.
@BindingAdapter({"bind:imageUrl", "bind:error"})
public static void loadImage(ImageView view, String url, Drawable error) {
Picasso.with(view.getContext()).load(url).error(error).into(view);
}
<ImageView app:imageUrl=“@{venue.imageUrl}”
app:error=“@{@drawable/venueError}”/>
This adapter will be called if both imageUrl and error are used for an ImageView and imageUrl is a string and error is a drawable.
When an Object is returned from a binding expression, a setter will be chosen from the automatic, renamed, and custom setters. The Object will be cast to a parameter type of the chosen setter.
This is a convenience for those using ObservableMaps to hold data. for example:
<TextView
android:text='@{userMap["lastName"]}'
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
The userMap returns an Object and that Object will be automatically cast to
parameter type found in the setter setText(CharSequence). When there
may be confusion about the parameter type, the developer will need
to cast in the expression.
Sometimes conversions should be automatic between specific types. For example, when setting the background:
<View
android:background="@{isError ? @color/red : @color/white}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>
Here, the background takes a Drawable, but the color is an
integer. Whenever a Drawable is expected and an integer is
returned, the int should be converted to a
ColorDrawable. This conversion is done using a static method
with a BindingConversion annotation:
@BindingConversion
public static ColorDrawable convertColorToDrawable(int color) {
return new ColorDrawable(color);
}
Note that conversions only happen at the setter level, so it is not allowed to mix types like this:
<View
android:background="@{isError ? @drawable/error : @color/white}"
android:layout_width="wrap_content"
android:layout_height="wrap_content"/>