Taoffi's blog

prisonniers du temps

Back to earth – Xamarin.Forms Cuvée 2017

After some months spent on other project types, so glad to find back Xamarin.Forms and to see how it evolved (matured) with the integration in Visual Studio 2017.

The new Xamarin.Forms project template is awesome and pedagogic. You can start building an entire professional solution around the basic objects delivered within that template!

This 2017 spring (well: it is autumn elsewhere!) other interesting projects also blossomed. Don't miss Grial 2.0 of UXDivers. A great ergonomic framework for Xamarin.Forms.

Those guys @UXDivers are unique! (Will talk about this later)

The new Xamarin.Forms template base objects

Inside the main portable project, you will find the 'Helpers' folder containing some interesting foundation objects, of which, the ObservableObject class.

ObservableObject is the base class of another delivered sample object 'BaseDataObject' of which derives the 'Item' object… another delivered sample object.

 

The relationship between those objects are shown in the following class diagram:

 

That looks to be a great and mature foundation. Deriving your objects from this simple architecture would allow you, among other benefits, to have a reliable property change notification mechanism (See my last year's post about this question)

 

Great… But!

As often among our developer community, we may agree on an architectural pattern and disagree on parts of its implementation.

In the new Xamarin implementation, a class calls its parent to set a property value. The parent then sets the new value and notifies the property change.

 

Here is the base class's (ObservableObject) code to set a property value:

 

protected bool SetProperty<T>(ref T backingStore, T value,
             [CallerMemberName]string propertyName = "",
             Action onChanged = null)
{
     if (EqualityComparer<T>.Default.Equals(backingStore, value))
         return false;

      backingStore = value;
     onChanged?.Invoke();
     OnPropertyChanged(propertyName);
     return true;
 }

 

 

A derived class can then use this:

 

string description = string.Empty;

public string Description
{
     get { return description; }
     set { SetProperty(ref description, value); }
}

 

 

In the above example, the property change notification is executed using the caller name (thanks to CompilerService.CallerMemberName attribute) unless the name is explicitly specified.

 

Note: msdn documentation

An Empty value or null for the propertyName parameter indicates that all of the properties have changed.

 

In so many case, a property change may require notifying the change of one or more of other object properties. A simple example would be: when you change the 'Birth date' of a person object, which requires notifying the change of his or her Age property as well.

In fact, an object's property value is, in most cases, linked to business rules and is better handled at the object's level. The property change notification, as its name suggests, is related to notifying external objects who may be interested by the value change of that property.

Summarizing this need by a SET mechanism can be good but does not seem to be an all-purpose solution.

We still need to complement this with the 'old' notification mechanism (based on Expressions) exposed in the pattern of the abovementioned post (which, itself, derives from other community knowledge as I mentioned!)

 

[This post corrects and clarifies points mentioned in a previous post]

Comments are closed