The classes that implement view inflation and binding are in org.robobinding and org.robobinding.binder packages. In the following section, a package start with . is a relative path to org.robobinding.

As shown above, application developers can use the framework in two potential ways(shown in two different colours), either through the utility class .binder.Binders or .binder.BinderFactoryBuilder(with customization capability). In either way, the final actual entry class is the same, BinderFactory. From BinderFactory, an instance of ViewBinder is created, which fulfils layout inflation and binding. Let us have a look at layout inflation process in the next.

The figure shows the layout inflation process and the core classes involved. Carrying on with the ViewBinder mentioned above, it further passes the layout inflation task to .binder.BindingViewInflater and the latter propagate to org.robobinding.NonBindingViewInflater. The only responsibility of NonBindingViewInflater is to inflate layout, constructing the view hierarchy from the given layout. When a view is created during inflation, a callback with view attributes to the BindingViewInflater is fired, and out of these view attributes, the BindingViewInflater builds a set of pending view binding attributes, org.robobinding.PendingAttributesForView, with the help of .binder.BindingAttributeParser. Repeating the process, until all PendingAttributesForViews are parsed from the layout.

Then the PendingAttributesForViews are passed to .binder.BindingAttributeResolver, which further tries to resolve them. BindingAttributeResolver uses .binder.ByBindingAttributeMappingResolverFinder to find a set of matched view binding attribute mapping resolver, .binder.ByBindingAttributeMappingResolver, according to the view hierarchy from top to bottom (e.g., android.widget.EditText inherits from android.widget.TextView, and TextView inherits from android.view.View. So a EditText instance matches three ByBindingAttributeMappingResolvers: A EditText ByBindingAttributeMappingResolver, a TextView ByBindingAttributeMappingResolver and a view ByBindingAttributeMappingResolver in order). BindingAttributeResolver calls all the matched ByBindingAttributeMappingResolvers in order to get a final set of .binder.ResolvedBindingAttributesForViews and then returns to the BindingViewInflater.

Afterwards, the BindingViewInflater add all the predefined pending attribute mappings, org.robobinding.PredefinedPendingAttributesForView, if there is. And then call BindingAttributeResolver to resolve them also, which follows the same process as resolving PendingAttributesForView above. Finally it gets a set of ResolvedBindingAttributesForViews as well.

The BindingViewInflater eventually hands a .binder.InflatedView containing all the ResolvedBindingAttributesForViews over to ViewBinder. The whole layout inflation work ends and the next binding stage starts.

The figure shows the entire binding process and the core classes involved. The ViewBinder hands the binding task to its ViewBindingLifecycle. The ViewBindingLifecycle runs the binding life-cycle on the InflatedView. Firstly try to bind all the ResolvedBindingAttributesForViews in the InflatedView. Internally the ResolvedBindingAttributesForViews invoke each of its binding attributes to complete the binding. After completion of the binding, the ViewBindingLifecycle validates the result. When an error is found, the whole process is terminated and the errors are reported. If successful with no errors, pre-initializing the views is kicked off when specified. Pre-initializing views is to synchronize values from a PresentationModel to its views.

View attribute bindings are implemented by org.robobinding.viewattribute and its sub package. In the following section, a package start with . is a relative path to org.robobinding.viewattribute.

There are three types of view attributes defined in the framework, namely a simple view attribute .property.PropertyViewAttribute, an event view attribute .event.EventViewAttribute and a composite view attribute .grouped.GroupedViewAttribute.

A PropertyViewAttribute implements binding for a simple view attribute. There are two kinds, which are single value-typed, property.PropertyViewAttribute, and multiple value-typed, property.MultiTypePropertyViewAttribute. A PropertyViewAttribute(in the figure with [1.1]marked, {enabledSwitch} and {selectedSwitch}) has only one possible value type such as EnabledAttribute(org.robobinding.widget.view.EnabledAttribute), having only one value type of Boolean. Whereas MultiTypePropertyViewAttribute(in the figure with [1.2] marked, {visibilitySwitch}) has multiple value types such as VisibilityAttribute(org.robobinding.widget.view.VisibilityAttribute), which can be a Integer or a Boolean.

A EventViewAttribute(in the figure with [2] marked, onClick and onLongClick) implements binding for a event view attribute, e.g., org.robobinding.widget.view.OnClickAttribute/OnLongClickAttribute and so on.

GroupedViewAttribute(in the figure with [3.1, 3.2] marked, {source}, @layout/item_row and {[text1.text:{name}]}; @layout/footer_layout, {footer} and {footerVisibility}) implements binding for a composite view attribute such as a org.robobinding.widget.adapterview.AdaptedDataSetAttributes which contains sub-attributes a source, an itemLayout and an optional itemMapping; a org.robobinding.widget.listview.FooterAttributes, which contains sub-attributes a footerLayout and two optional attributes, a footerPresentationModel and a footerVisibility.

org.robobinding.viewattribute package contains abstract classes of core concepts for view attributes, and org.robobinding.widget package contains various counterpart view attribute binding implementations for android.widget package. For example, org.robobinding.widget.textview package is for android.widget.TextView and org.robobinding.widget.seekbar package is for android.widget.SeekBar.

All kinds of view attributes have corresponding Binder classes. They work together to accomplish the binding task. For example, the counterpart of EventViewAttribute is EventViewAttributeBinder.

In the following section, a package start with . is a relative path to org.robobinding.viewattribute.

The figure shows the relationship between a composite view attribute .grouped.GroupedViewAttribute and its child view attributes. A GroupedViewAttribute contains various types of child view attributes. Currently the kinds of child view attributes in use are .grouped.ChildViewAttribute, .grouped.DependentChildViewAttribute, .property.PropertyViewAttribute and .property.MultiTypePropertyViewAttribute.

A ChildViewAttribute is an ordinary child view attribute and it has a subclass of .grouped.ChildViewAttributeWithAttribute. A ChildViewAttributeWithAttribute is a ChildViewAttribute but with a required attribute value, which will be set when the ChildViewAttributeWithAttribute is created, such as org.robobinding.widget.adapterview.SourceAttribute/SubViewLayoutAttribute.

DependentChildViewAttribute is a dependent child view attribute. It cannot be created in an ordinary way, as it depends on some runtime information from previous child attributes. It is, therefore, created via a .grouped.ChildViewAttributeFactory. Take org.robobinding.widget.adapterview.SubViewAttributes.SubViewAttributeFactory for example. It needs subViewLayoutAttribute.getLayoutId() to create a SubViewAttribute.

PropertyViewAttribute and MultiTypePropertyViewAttribute are single value-typed and multi value-typed view attributes. They are already discussed earlier, and can be reused here as a child view attribute.

In the following section, a package start with . is a relative path to org.robobinding.

The four packages, org.robobinding.presentationmodel, org.robobinding.property, org.robobinding.itempresentationmodel and org.robobinding.function, are for wrapping a PresentationModel as a .presentationmodel.PresentationModelAdapter, which is used in binding process. The PresentationModelAdapter is the entry class of the packages. The framework creates a PresentationModelAdapter instance for each PresentationModel. Currently, there are two ways for the framework to identify a class as a PresentationModel through .presentation.PresentationModel annotation.

A PresentationModelAdapter is created to wrap a PresentationModel and acts as a provider of three pieces of information, namely wrapping SimpleProperty, DataSetProperty and Method, and then acting as a provider of .property.PropertyValueModel, .property.DataSetValueModel and .function.Function. On the right hand side of the figure above, the property of windowTitle is a SimpleProperty, the property of albums is a DataSetProperty and createAlbum() is a Method. DataSetProperty is a data set property. The framework will create a .itempresentationmodel.ItemPresentationModel instance for each data item in the collection. In the given figure above, an AlbumItemPresentationModel will be created for each album item in albums collection and will be rendered to the screen according to the given row layout of @layout/album_row.

The concept of view event listener aggregates(org.robobinding.viewattribute.ViewListeners or its subclasses), is introduced to provide a workaround of registering multiple event listeners due to the fact that the Android framework can only allow register a single event listener in many cases(e.g., android.view.View.setOnFocusChangeListener). As an application may need to register multiple event listeners on a same event, to overcome the old listener not being erased by a new one accidentally, the concept of view event listener aggregate is implemented.