Simplifying MVVM INotifyPropertyChanged On Xamarin.Forms

The goal is simplifying MVVM INotifyPropertyChanged in Xamarin Forms therefore making it unnecessary to keep inheriting base classes and handling the setter of each ViewModel Property.

Remember that the code shown here is just an example to demonstrate an alternative to the normal methods with MVVM. Nowadays frameworks exist to work with MVVM in Xamarin Forms, the Prism is one of them.

What do we need?

Visual Studio 2015 or 2017, it can be the community version, no problems there;
CROSS Platform Xamarin Forms project with XAML for pages;
Fody PropertyChanged to be installed via nuget;

Observation

This article expects that you have already done some implementation with MVVM design Pattern in Xamarin Forms.

Traditional MVVM INotifyPropertyChanged in Xamarin Forms

public class TradicionalPageViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void NotifyPropertyChanged([CallerMemberName] string propertyName = "")
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
private string _title;
public string Title
{
get
{
return _title;
}
set
{
if (_title!= value)
{
_title= value;
NotifyPropertyChanged();
}
}
}
private string _name;
public string Name
{
get
{
return _name;
}
set
{
if (_name!= value)
{
_name= value;
NotifyPropertyChanged();
}
}
}
private int _age;
public int Age
{
get
{
return _age;
}
set
{
if (_age!= value)
{
_age= value;
NotifyPropertyChanged();
}
}
}
}

The code above is the traditional pattern, that is, the “spartan way” where you’ll need, for each property, to implement all the setter rules of each property of your ViewModel, in addition to implementing the interface INotifyPropertyChanged with the event that will notify the ViewModel changes.

It’s certain that the template above doesn't follow the principles of DRY (Don’t Repeat Yoursefl), so to facilitate it there are some alternatives, one of them is shown below by the folks of the Xamarin Marathon, specifically the MVVM video of Alexandre Chofi and James Montemagno.

Alternative MVVM INotifyPropertyChanged in Xamarin Forms

public class MarathonPageViewModel : BaseViewModel
{
private string _title;
public string Title
{
get
{
return _title;
}
set
{
SetProperty(ref _title, value);
}
}
private string _name;
public string Name
{
get
{
return _name;
}
set
{
SetProperty(ref _name, value);
}
}
private int _age;
public int Age
{
get
{
return _age;
}
set
{
SetProperty(ref _age, value);
}
}
}

Alexandre Chofi created a base class and some methods to be used on each ViewModel Property facilitating its use and repeating less code. Of course, the code became very clean and easy to use.

BaseViewModel Class from Xamarin Brazil Marathon

public class BaseViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
protected virtual void OnPropertyChanged([CallerMemberName]string propertyName = null)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs((propertyName)));
}
protected bool SetProperty<T>(ref T storage, T value, [CallerMemberName]string propertyName = null)
{
if (EqualityComparer<T>.Default.Equals(storage, value))
{
return false;
}
storage = value;
OnPropertyChanged(propertyName);
return true;
}
}

This morning I had an idea to simplify this INotifyPropertyChanged thing, so I woke up early and started looking and unsurprisingly something appears ready to use.

So, for those developers who are more eclectic, there exists an alternative that's even simpler, I’m speaking of Fody PropertyChanged library.

MVVM INotifyPropertyChanged with Fody PropertyChanged in Xamarin Forms,

[ImplementPropertyChanged]
public class HomePageViewModel
{
public string Title { get; set; }
public string Name { get; set; }
public int Age { get; set; }
}

As you can see above, I really don’t know if something simpler than this exists. We just add the attribute [ImplementPropertyChanged] to the ViewModel at the compile time, the Fody PropertyChanged will inject the necessary code in the setter of each public property of the ViewModel.

Make sure to remember that the thing is not dynamic, that is, it will not affect the performance of your application because it’s on the compile-time not on execution. Do you believe it? Take a look at the code below caught from .NET Reflector:

namespace FSL.XF5.ViewModels
{
using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Runtime.CompilerServices;
using System.Threading;
public class HomePageViewModel : INotifyPropertyChanged
{
[DebuggerBrowsable((DebuggerBrowsableState) DebuggerBrowsableState.Never), CompilerGenerated]
private string <Title>k__BackingField;
[field: NonSerialized]
public event PropertyChangedEventHandler PropertyChanged;
public virtual void OnPropertyChanged(string propertyName)
{
PropertyChangedEventHandler propertyChanged = this.PropertyChanged;
if (propertyChanged != null)
{
propertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
public string Title
{
[CompilerGenerated]
get
{
return this.<Title>k__BackingField;
}
[CompilerGenerated]
set
{
if (!string.Equals(this.<Title>k__BackingField, value, (StringComparison) StringComparison.Ordinal))
{
this.<Title>k__BackingField = value;
this.OnPropertyChanged("Titulo");
}
}
}
}
}

This implementation code is on my GitHub and you can download it now. Simplifying INotifyPropertyChanged: Suggestions or Criticism are always welcome. To know more about Fody PropertyChanged click here.

An important feedback from a college and member of the community

"In addition to the content well shown, I point out the existence of a certain procedure that requires to be executed when using IDE like Xamarin Studio. In this, after the installation of the Nuget Packge and the creation of the FodyWeavers.xml file in the root of the project, it’s necessary the addition of a simple XML TAG for the processing of PropertyChanged be done correctly, it’s necessary to add the TAG below.

<PropertyChanged />

Also important, is to pay attention for updates on Fody and PropertyChanged package, for those focused on PropertyChanged package, update the Fody only when the update is requested by the PropertyChaned itself, otherwise keep a library Fody as it is. Users of mono version 5 or superior, it’s mandatory to be using the latest version of the PorpertyChanged package(together with the latest of Fody for its dependency), to solve conflicts with Cecil(Mono) dependency’s." Rodrigo Amaro.

Good studies and farewell!