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