Skip to end of metadata
Go to start of metadata

As its name implies, binding providers acts as the mediator that provides binding definitions to the interested parties such as view models and views. In most cases, you should put the binding providers in the core project where all shareable application code reside.

To create a binding provider, you create a class that derives from BindingProvider Class such as shown in the following example.

On this page:

As shown in the above sample, the binding provider simply contains a set of binding definitions which are added through the AddBinding method – typically called in the constructor of the class.

Adding Binding Definition

The AddBinding method has a number of overloads, but in essence they are designed for a purpose. The AddBinding method establishes a binding contract between the ViewModel source and the view target on a particular property. Take a deeper look at the following code for example.

One of the most important points to note in the above example is the view target contract which represents the identifier agreement that Crosslight will use to establish the binding across various mobile platforms. This means that the corresponding view in the target platform – whether it is iOS or Android – that consumes the particular binding should conform to the same identifier as specified in the view target contract. This architectural design allows binding registration between source and target across different platforms in loosely coupled fashion.

To further understand how the binding provider actually works and the relationship with the source and the target view, please see the following illustration.

As seen in the above illustration, once you have properly define the binding definitions in a binding provider, Crosslight automatically binds the source to the target according to the view target contract. The binding features and properties that support data binding will be discussed more details in the next section.

The binding provider is specifically designed for platforms that do not support built-in data binding such as iOS and Android. Since Windows Phone and Windows RT support data binding in nature, it makes more sense and more elegant to bind directly to the ViewModel in the XAML markup.

As a rule of thumb, it’s recommended that you create binding provider based on the logical view or screen that share common binding definitions. For instance, if you have two or three views that show item details such as the product name and quantity, then you can group the common binding definitions to a binding provider called ItemDetailBindingProvider. Once you have a binding provider that represents a group of binding definitions based on logical view, you can easily import them to the view context which will be discussed in more details later.


Understanding Bindable Properties

In addition to the source and view target contract, another important aspect of Crosslight data binding concept is the bindable property. Bindable property represents the property of which the target view will be bind to. Unlike standard control properties, bindable properties are agnostic to the view-specific technology which allows the same binding description to be reused in any supported platforms – thanks to the solid binding architecture built into the entire Crosslight technology stacks.

In essence, the bindable properties act as extended properties to the native UI components. As the results of this architectural design, the UI controls in each native platform can leverage the Crosslight binding technology without requiring subclassing. This means that the UI controls in iOS and Android remain the same as it is – yet can be bound to the Crosslight binding description.

To enable rapid business-oriented mobile apps development, Crosslight includes a vast array of common bindable properties that you can directly consume without additional code.

The following list shows a few examples of common bindable properties exposed in Crosslight.

For the complete list of supported bindable properties, please see BindableProperties Class.

The interpretation of the bindable properties are vary depending on the UI components and the target mobile platform. However, Crosslight presents a design guideline that enforces identical implementation of bindable properties in the similar kind of UI components regardless of the target platforms.

For example, the text input component in iOS is represented by a type called UITextField, while in Android is called TextView. Since both of them fall into the same component kind – which is a text input type – both should support the TextProperty bindable properties. This allows you to simply create binding definitions that target a particular bindable properties without have to concern the actual type of the native UI component – as long as they conform to the same view target contract.

Built for extensibility, Crosslight also allows you to create your own bindable properties and implement the binding value dispatch through your own custom binding adapter. To learn more, see Implementing Custom Bindable Properties.