In the above example, {Binding Username} points to a public property on the LogingPages binding context, the LoginViewModel. When the user enters text, changes are automatically applied into the Username property.

But what if we introduced a new Entry bound to Password, a property that doesn't exist on the LoginViewModel:

LoginPage.xaml.cs

<Entry Text="{Binding Username}"/>
<Entry Text="{Binding Password}"/>

Provided we have configured the views binding context correctly, the XAML analyser recognises this is a runtime bug and marks it:

MFractor encourages a XAML first workflow; you write out bindings in XAML and then generate the implementation on the view model.

This is a big change to existing workflows. Previously, we coded these properties by hand and wire them up manually in the XAML; an approach both time-consuming and error prone. You have to remember property names, property types, control types and then you need to write this all out by hand!

Using binding generation we can literally eliminate minutes of work and hundreds of keystrokes in a few clicks.

MFractor provides the following shortcuts to implement our bound properties:

We are using Fody's ImplementPropertyChanged attribute on our ViewModel to automatically add INotifyPropertyChanged behaviour.

The backing field fix is most useful when:

We want backing logic that occurs when our property changes.

We occasionally want to manipulate the properties backing field without changes propagating to the UI.

The Implement ViewModel Refactoring

Another way to generate properties for a view model is to use the Implement View Model refactoring. This shortcut collects all missing binding expressions (excluding bindings inside DataTemplates) and generates them in bulk onto the binding context.

We can access this short cut by right clicking anywhere in a XAML file, navigating to Generate and then selecting the Implement View Model action:

You'll notice that there are 2 actions:

Implement View Model gathers all missing bindings in the XAML document and implements them all as public properties with a public get and set accessor.

Implement View Model (Use Backing Fields) gathers all missing bindings in the XAML document and implements them all as public properties with a public get and set accessor that sets or gets a backing field.

There are often cases when a binding context isn't specified explicitly and can't be inferred implicitly. A common example of this is that you have just started to build a XAML view and haven't yet got around to building the corresponding view model.

The Implement View Model action can also generate a view model class for the XAML view if one is not already defined. Using Mvvm naming conventions, MFractor generates a view model class for your XAML view under the MyDefaultNamespace.ViewModels namespace.

For example:

LoginPage.xaml.cs

<Entry Text="{Binding Username}"/>
<Entry Text="{Binding Password}"/>

When creating the view model class, MFractor removes the Page or View suffix from the view name and then attaches ViewModel to the end of the resulting name.

Remove the Page or View suffix: LoginPage -> Login

Attach the ViewModel suffix: Login -> LoginViewModel

Generate a new class named LoginViewModel under the namespace MyDefaultNamespace.ViewModels.

If you project references Fody's ImplementPropertyChanged extension, the default getter / setter implementation will also annotate the result with the [ImplementPropertyChanged.PropertyChanged] attribute:

Binding Generation And Value Converters

When a binding expression uses a Converter, MFractor will attempt to resolve the input type of the referenced value converter and use that as the property type. We must have a value conversion attribute on the IValueConverter for MFractor to resolve the input type. Please read the Value Conversion Type-Safety tutorial to learn more.

For example, we add a login button that is only enabled when the user has their password entered: