Introduction
Android Binding is a new Open Source Framework for Android-Java providing XML layout view binding mechanism. It helps development of Android Application by decoupling the View widgets and backend Activities. It works best with MVP or MVVM patterns.
Please also download from Market (Search "Markup Demo") the demo on most features of Android Binding.
A more fundamental, getting started to Android MVVM with android-binding tutorial series is up in my own blog.
UPDATE: v0.2 is released. Please visit the project homepage for details as it may not be compatible with previous versions.
Critical Changes (as of 30/1/2010)
If this is the first time you read this article, you may skip this section.
Version 0.11 of Android binding is released with this sample application. As the project evolves, a number of critical (yet would results breaking original codes) changes were made. Upon the release of 0.11, I suppose those changes should be final.
The first time I wrote this article, Android Binding doesn't support binding to object collections, but now, it can bind to Cursor or Array, each 'row' of the records are treated as a View Model, which means Command and DependentObservables are all functional, which would be covered later in this article.
The sample application is rewritten, as the Contacts list no longer binds to the raw Adapter but via a more declarative way. Action related binding renamed to have a 'on-' prefix, for example, click -> onClick to make it more distinctive.
Observable<T> now requires passing the class of T as parameter: e.g.
Observable<Boolean>(Boolean.class, true);
Since this makes writing such code too verbose, some shorthand primitive observables are provided.
Sample Application
The following will briefly introduce how it is used. Where the sample application codes used here are obtainable at:
and the compiled application is available at Android Market (Search "Android Binding" in Market).
This sample is a modification based on Google's original Contact Manager Sample, the purpose of it is to show the differences in view binding and the benefits of using Android Binding.
Basic Configuration
To use Android Binding, all you need to do is to reference the library (in Eclipse, right click project -> Properties -> Android, reference the Android Binding Project as library). And then, in Application class:
public class ContactManagerApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
Binder.init(this);
}
}
The Binder.init(Application) is required to run once and only once, across the application life cycle. During the init() process, it is time for Android Binding to register and initialize the markup and binding providers, which can support custom view classes.
Activity
Activity is no longer required to be View-awared, even the view model doesn't. Android Binding is best supported for View Model First development in MVVM. So, no more presentation / user interaction logic in Activity and results in a clean Activity class:
public final class ContactManager extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
ContactManagerModel model = new ContactManagerModel(this);
Binder.setAndBindContentView(this, R.layout.contact_manager, model);
}
}
You provide the Model (or ViewModel to be precise) to binder, and it automatically wires up the view with the ViewModel. This is how we markup the contact_manager.xml:
Layout
="1.0"="utf-8"
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:binding="http://www.gueei.com/android-binding/"
android:orientation="vertical"
android:layout_width="fill_parent"
android:layout_height="fill_parent">
<ListView android:layout_width="fill_parent"
android:layout_height="wrap_content"
binding:itemSource="ContactList"
binding:itemTemplate="@layout/contact_entry"
android:layout_weight="1"/>
<CheckBox android:layout_width="wrap_content"
android:layout_height="wrap_content"
binding:checked="ShowInvisible"
binding:onCheckedChange="PopulateList"
android:text="@string/showInvisible"/>
<Button android:layout_width="fill_parent"
android:layout_height="wrap_content"
binding:onClick="AddContact"
android:text="@string/addContactButtonLabel"/>
</LinearLayout>
Layout looks pretty much the same as standard Android Layout, except that an extra binding namespace is imported. There's an issue with AAPT, that the binding namespace needed to reference to the "demo" project instead of the library. (Hope it can be solved in the coming future). The binding namespace should point to http://www.gueei.com/android-binding/.
As shown in the above layout file, the markup is done through the custom namespace (prefixed binding), and the attribute is pretty much reflecting to most original View attributes.
There are currently two kinds of bindable objects in a view. First is the Property (like checked in CheckBox) and the second is Command (checkedChange in Checkbox), where both of them will be explained in the later part of this article.
Also note that for the ListView, it is binding to itemSource which will be either some Cursor or Array of View Models (and we will cover that later) and the itemTemplate is a standard Android Resource reference format, that tells what the layout of each item should look like.
Following is the contact_entry.xml:
="1.0"="utf-8"
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:binding="http://www.gueei.com/android-binding/"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
binding:onClick="ShowContact"
>
<TextView android:layout_width="fill_parent"
android:layout_height="wrap_content"
android:textSize="20dip"
binding:text="Name"
/>
</LinearLayout>
It is still fairly standard layout XML file with customized binding namespace. Notice that the layout root (i.e. the LinearLayout) defined an action onClick.
ViewModel
The ViewModel is something that bridges the View and Model (it will be the contact provider in this example). The ViewModel in Android Binding is a class defining all the 'bindable' data/command Fields for the View to access. Following shows a portion of the ViewModel:
public class ContactManagerModel {
private Activity mContext;
public CursorSource<ContactRowModel> ContactList =
new CursorSource<ContactRowModel>
(ContactRowModel.class, new Factory());
public BooleanObservable ShowInvisible = new BooleanObservable(false);
public Command PopulateList = new Command(){
public void Invoke(View view, Object... args) {
populateContactList();
}
};
public Command AddContact = new Command(){
public void Invoke(View view, Object... args) {
launchContactAdder();
}
};
private void populateContactList() {
Cursor cursor = getContacts();
ContactList.setCursor(cursor);
}
BooleanObservable is representing an object that is 'observable' by other objects, so, whatever changes are made on this object will keep its observers notified. There are quite some Observables defined in Android Binding, like StringObservable, IntegerObservable, ... all of them are subclasses of IObservable<T> which implement the following methods:
set() get() notifyChanged()
The get() and set() are a replacement for getter and setter methods in Java, which will, by default, notify the subscribers about the change on the object automatically (where this is a borrowed concept from .NET).
Command is the interface that defines something that is "Executable". Normally they will be wired with Event fired from User Interface.
Finally, since our contact source is a cursor, we need to supply the CursorSource<?> to indicate how our Cursor is used.
Binding to Cursor
In Android Binding, each row of record in the Cursor, is supposed to be a View Model. That means, you are applying the same layout each with a separate set of data. One of the most powerful features in Android Binding, is that it allows you to define Commands and more complicated logic even in the sub-view models. As mentioned before, you cannot just supply a Cursor as itemSource for AdapterViews (including ListView, Spinners...), but it must be either an ArraySource or CursorSource.
CursorSource takes two constructor parameters:
public CursorSource<ContactRowModel> ContactList =
new CursorSource<ContactRowModel>
(ContactRowModel.class, new Factory());
First one is the class of the sub-viewmodel that representing each 'row' of cursor data (so it is named rowModel), the other one is a factory that actually knows how to 'construct' the row. Let's look at them one by one.
public class ContactRowModel extends CursorRowModel {
public IdField Id = new IdField(0);
public StringField Name = new StringField(1);
public Command ShowContact = new Command(){
The RowModel is pretty much standard View Model, except it requires to extend from CursorRowModel. The IdField, StringField are simply Observables but their value will be filled up automatically using the Cursor; the number within the bracket tells which column you are mapping that field to.
Model Validation
Model validation (to be precise, validating the View Model) is also supported, this is also demonstrated in this sample application but you may read my other article for details.
Furthermore
Observable is quite restricted at the moment, as it requires the View Attribute and the Property of Model to be the same in type. That means, if you bind the checked (which is boolean) attribute with an Observable<Integer>, it won't work, since implicit type casting is not allowed. Therefore, another two subclasses of Observable are provided:
DependentObservable<?>
This denotes that an observables' value is dependent on other Observables. For example, we can rewrite the above ViewModel to add an SelectedContact:
DependentObservable<Contact> SelectedContact = new
DependentObservable<Contact>(Contact.class, SelectedId){
@Override
public Contact calculateValue(Object... args){
getContactFromDb((Integer)args[0]);
}
};
DependentObservable requires only one override method, the calculateValue. Since DependentObservable can depends on multiple dependents, the parameters length in calculateValue is open, and explicit typecast is required. The above example is similar to a one-way converter, that converts the Id to a real contact.
There's actually a Converter class in Android Binding, and the only difference with DependentObservable is that Converter can allow two-way binding:
Converter<?>
public abstract void ConvertBack(T value, Object[] outResult);
Indeed, Converter is a subclass of DependentObservable. It depends on a list of other observables, it can convert a boolean true to number 1, and when the convert back when other changes the convert's value.
Progress and Plans
An Alpha version of the project is released. You can go to the project homepage to download it.
Future plan is to add support to more POJO (Plain Old Java Object) way of View Model declaration.
You are free to download the code from the Google Code project repository, reports and issues. Please drop in the discussion group: http://groups.google.com/group/androidbinding.
Conclusion
This article briefly introduces the functionality of the Android Binding. If you compare it to the original Contact Manager Sample, you will find that using Android Binding w/MVVM results in much cleaner code and thus, more friendly to Unit testing and better code quality. Active development is in progress and this is my first OSS. I really look forward to comments and suggestions on this framework.
Author Blog and Project Details
