2

Cleaning up MVVMCross ViewModels with Fody

 3 years ago
source link: https://prin53.medium.com/cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Cleaning up MVVMCross ViewModels with Fody

Have you noticed that the more complex the UI is, the more repetitive code appears in the ViewModel? And especially, the code related to “live” properties is duplicated.

Despite the fact that refactoring is always challenging, you can start a ViewModel’s code clean-up by involving the PropertyChanged weaving library based on the tool called Fody.

Even if you are familiar with this library, the advanced usage section could still be helpful.

Our demo ViewModel contains FirstName, LastName and Email properties that are “live” properties, e.g., the PropertyChanged event should be invoked when any of these properties are changed.

As you can see, there is a lot of repeatable code, and several ways to raise the property changed even. If you run the app, the output will be like this:

1*PibKyw6QVy0yTQsHIqpSLA.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
Live property updates are printed to the console using the default MvvmCross property notifications.

Let’s see how this code can be cleaned up using the PropertyChanged library.

Setup

All we need is to add the PropertyChanged.Fody package to the project that contains the ViewModel layer:

1*EcbbtLsRV6RZKvfjSF2Big.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
PropertyChanged.Fody package can be found and added using the default NuGet manager in Rider IDE.

The FodyWeavers.xml file will be added automatically:

1*OpzzhDcuIcDaMFkKVqnzCQ.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
PropertyChanged weaver should be set in the Fody config to work correctly.

Basic Usage

As the MvxViewModel already implements INotifyPropertyChanged, no changes are required except for removing manual RaisePropertyChanged method calls.

Much cleaner, isn’t it?

Advanced Usage

Here are the most useful advanced features, but the full features list is available in the official documentation.

Ignoring Unneeded Properties

There is no end to optimization, and ignoring unnecessary PropertyChanged events can speed up your application a bit. To do that, you need to add the [DoNotNotify] attribute to the property you want to ignore:

[DoNotNotify]
public string Email { get; set; }

Now our debug output does not contain the Email line because the property is not “live” anymore:

1*Pc_PH-rfCZfgjqi7yiMPLQ.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
No PropertyChanged events raised for ignored Email property.

Property Interception

If you need some additional logic (like validation) when the property is set, you can add an interception method using the particular signature On<Property>Changed:

public string Email { get; set; }

// ReSharper disable once UnusedMember.Local
private void OnEmailChanged()
{
Debug.WriteLine($"New email is: {Email}");
}

Ignoring Unneeded Methods

Sometimes our method names are similar to those used by the Fody.PropertyChanged library:

1*bNGk4jwC_HAbyHWacHMjhg.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
Connectivity event subscription conflicts with Fody.PropertyChanged methods signature.

And warnings appear during the build process:

1*YHfd7rygtFSWmfdoPHA2jQ.png?q=20
cleaning-up-mvvmcross-viewmodels-fody-b644efa86f82
Method conflicts end up with build-time warnings.

To resolve them, you need to add an attribute [SuppressPropertyChangedWarnings] specified in the unsupported method’s warning message:

[SuppressPropertyChangedWarnings]
private void OnConnectivityChanged(
object sender,
ConnectivityChangedEventArgs e
)
{
Debug.WriteLine($"Is Connected: {e.IsConnected}");
}

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK