Building reactive graphical user interfaces on Ubuntu with XAML

With the initial release of .NET Core, we can now build cross-platform .NET applications using not only Windows, but also macOS, Ubuntu, and other Linux distros. As a full-stack developer who is pretty excited about the evolution of the .NET ecosystem, I use a laptop with Ubuntu and Windows in dual boot, and with .NET Core SDK installed on both operating systems. However, most of the development time I prefer using Ubuntu KDE. On the one hand, the command-line interface in Linux makes a wide variety of problems way easier to solve, including package management, network configuration, and orchestration of Docker containers. On the other hand, using the same environment on your production and development servers also offers some benefits.

However, no cross-platform desktop GUI exists in .NET Core out of the box. Such awesome desktop frameworks as WPF and UWP currently support Windows only, even after WPF was ported to .NET Core. To overcome this issue, Microsoft has recently announced the new Multiplatform App UI, planning to target general availability in November of 2021. However, according to the MAUI page on GitHub, Linux devices won’t receive official support from Microsoft. Surely, one could use a framework based on web technologies in order to develop a desktop app, but this can lead to users complaining about high RAM and CPU usage. In this situation, AvaloniaUI comes to the rescue!

What is AvaloniaUI? 🔥

AvaloniaUI is an open-source, free, and feature-rich .NET Core framework, allowing us to build cross-platform apps of any complexity, on any operating system, including Ubuntu, macOS, and Windows.

The framework uses a XAML dialect, which should feel familiar to folks coming from WPF, UWP, or Xamarin Forms worlds. XAML is a markup language that allows describing app UI declaratively, using a concise XML-like syntax. Similarly to WPF and UWP, Avalonia XAML supports the MVVM pattern and data bindings.

The main difference is, however, in the XAML compilation engine. The XAML markup in AvaloniaUI is type-checked at compile-time, making typos and other markup bugs much easier to discover and fix. Worth noting, that AvaloniaUI supports debugging XAML right in the debugger of your favorite IDE. AvaloniaUI uses the XamlX compiler internally in order to enable these awesome features.

Additionally, AvaloniaUI allows using regular C# code for building user interfaces, and this may seem similar to the technique used in Flutter. Binding from code is supported as well, and a specific syntax exists, which allows attaching the bindings to the specified properties in the initializers of C# objects. Worth noting, that IObservables from reactive extensions are first-class citizens in AvaloniaUI.

The styling system in AvaloniaUI is heavily inspired by CSS and can be thought of as a mix of XAML templates and CSS selectors. From my personal experience, combining these two powerful techniques for building user interfaces is a really cool idea, which greatly simplifies the process of styling a complex application. With a CSS-like selector, you can easily select the required control, and the setters declared in XAML allow using brushes from resource dictionaries. Such resource dictionaries can be changed dynamically at runtime, making theming AvaloniaUI applications incredibly easy.

Another cool feature that distinguishes AvaloniaUI from good old technologies like WPF is intelligent data templates. Data templates in AvaloniaUI have a DataType property, and the template for the data can be chosen at runtime based on the type of the bound object. The bound object, on its turn, is usually a view model built with ReactiveUI. In Avalonia applications, ReactiveUI is used as the MVVM framework by default.

Clean Code is Crucial in Software Development - Here's Why | Data Driven Investor

What is ReactiveUI? 💫

ReactiveUI should feel familiar to folks coming from WPF, UWP, and Xamarin Forms worlds. It is an advanced, composable, reactive MVVM framework for all .NET platforms, with almost 1.5 million downloads on NuGet. ReactiveUI copes gracefully as your application scales, allowing you to avoid overcomplicating things by using the full power of reactive extensions.

A typical view model made with ReactiveUI may look like the one below. Such code can be placed into a .NET Standard library, and become easily portable and testable.

ReactiveUI allows observing property changes via the WhenAnyValue extension method. Computed properties are implemented via the ObservableAsPropertyHelper class, or with the [ObservableAsProperty] attribute, the ReactiveCommand class is the default implementation for the ICommand interface. Such commands are usually bound to buttons, so the buttons stay disabled until the WhenAnyValue condition is satisfied. The sample XAML markup for the SearchViewModel is shown below.

Additionally, ReactiveUI supports view model activation and routing. ReactiveUI routing consists of an IScreen, a bunch of IRoutableViewModels, and a platform-specific RoutedViewHost control. AvaloniaUI provides its own implementation of aRoutedViewHost control in Avalonia.ReactiveUI support package.

The ReactiveUI ecosystem includes such helper projects, as Pharmacist, DynamicData, Sextant, and others. These tools can give you superpower in building rich and reactive user interfaces. The ReactiveUI.Validation package contains validation helpers and the implementation for the INotifyDataErrorInfo interface.

Developing AvaloniaUI Apps on Linux

Using the technology stack described above, we can easily build a .NET Core GUI application on Linux, using JetBrains Rider as our IDE. There are helper packages such as Live.Avalonia that can simplify and speed up the GUI development process by adding the hot reload feature to our Avalonia graphical interfaces.

Visual Studio Code IDE from Microsoft can also be used for development.

In order to get started with building cross-platform .NET Core GUI apps using AvaloniaUI and ReactiveUI on Linux, install the templates from GitHub, and follow the tutorial on AvaloniaUI website. Another option is to follow yet another tutorial, which provides detailed instructions about how to set up ReactiveUI routing in an Avalonia app.

If you experience any issues, head over to AvaloniaUI Gitter, where you can ask any questions and get help from AvaloniaUI maintainers. If you are willing to dive deeply into the described technology stack, check out the following articles:

• Avalonia UI on Ubuntu: Getting Started
• A Cross-Platform GUI Theme for Desktop .NET Core Applications
• Reactive MVVM Pattern on the .NET Platform
• On Reactive Programming
• In Praise of Elevated Values
• Avalonia, a big candidate to create cross-platform apps with XAML
• What would a cross-platform .NET UI Framework look like? Exploring Avalonia
• Saving Routing State to the Disk in a Cross-Platform .NET Core GUI App with ReactiveUI and Avalonia
• A curated list of Awesome Avalonia libraries and resources
• ReactiveUI Handbook
• Introduction to Reactive Extensions: Getting Started

Thanks for reading!

Gain Access to Expert View — Subscribe to DDI Intel

Develop Cross-Platform Desktop GUI Apps on Linux with .NET Core was originally published in DataDrivenInvestor on Medium, where people are continuing the conversation by highlighting and responding to this story.

Build beautiful user interfaces with AvaloniaUI

Avalonia is a novel XAML UI framework, allowing .NET developers to deliver cross-platform .NET Core desktop applications for end-users. Inspired by Microsoft stack technologies, such as Xamarin Forms, Windows Presentation Framework, and Universal Windows Platform, Avalonia provides fully-featured means of building high-performant user interfaces of any complexity and any scale. Compared to Windows Presentation Framework, Universal Windows Platform, or Xamarin Forms, Avalonia provides a faster type-safe XAML compiler known as XamlIl, which makes the process of developing and debugging complex XAML interfaces far less painful. Moreover, XamlIl allows debugging XAML — watch this video on YouTube if you are still in doubt about giving Avalonia a try. Avalonia comes with ReactiveUI support out of the box, and this makes it possible to use the full power of reactive programming in an Avalonia .NET Core app.

Known Avalonia applications include its use in a cross-platform IDE and shell, in code editors, and in privacy-focused Bitcoin wallets. Avalonia is shipped as .NET Standard MIT-licensed NuGet packages and is available for free for anyone willing to build cross-platform desktop experiences in C# or F#, even for commercial use.

However, the ecosystem around the framework is still developing — there aren’t many GUI themes developed for the framework yet. Hence, designing a brand new modern style set seemed reasonable to me. User interface themes in Avalonia were designed as standalone components that can be easily replaced with any other sets of styles, and this made the development process of different color schemes even more simple and convenient.

The styling system in Avalonia can be thought of as a mix of CSS styling and WPF styling, a style consists of a selector and a collection of setters. Styles can be defined on any control, importing styles from files or packages is supported as well.

Avalonia styling system also supports pseudo-classes, which allows us to control the look of controls in different visual states. With the help of this feature, we can easily change the background of a button when a user presses it, or when a user moves the mouse over the control. Using the /template/ syntax, we can style the primitives based on which a more complex control is built. Dynamic and static resources are also supported, which may seem familiar for those coming from WPF, UWP, or Xamarin Forms.

Based on the mentioned implementation details, a novel graphical user interface theme was introduced and packed as a NuGet package. The theme received the name Citrus because of the orange accent color used in most of the color schemes available in the Citrus.Avalonia NuGet package. Following the licensing policy of the Avalonia framework, the Citrus theme is MIT-licensed and free for everyone, even for commercial use. The source code of the project is available on GitHub.

Getting Started

If you are completely new to Avalonia, see Avalonia Getting Started tutorial on their documentation website. After you have created the Avalonia .NET Core project, the Citrus.Avalonia package can be installed by either using the NuGet package manager GUI of any IDE, including JetBrains Rider and Microsoft Visual Studio. Another way is to execute the following .NET Core SDK command from your project root:

dotnet add package Citrus.Avalonia

Then, place the following XAML code into the App.xaml file:

<Application xmlns="https://github.com/avaloniaui"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             x:Class="YourNamespace.App">
  <Application.Styles>
    <StyleInclude Source="avares://Citrus.Avalonia/Citrus.xaml"/>
  </Application.Styles>
</Application>

The StyleInclude line is responsible for importing a set of styles into the application. The imported styles will be applied to all default XAML controls, descendant to the element which contains the StyleInclude line. As a result of the code snippet above, all default controls in your application will start using Citrus styles. If you are willing to apply the styles to a small part of your application, move the StyleInclude line to the Styles section of control other than Application . Notably, the Citrus NuGet package includes a dark color scheme as well.

To browse the control gallery, clone the Citrus.Avalonia.Sandbox sample project. There are five color schemes total available inside the Citrus.Avalonia NuGet package, named Citrus, Sea, Rust, Candy, and Magma. In order to use color schemes other than the default one, you need to adjust the StyleInclude XAML tag by changing the Source attribute to point to another color scheme. To avoid collisions, remember to remove other StyleInclude lines present in the App.xaml file before.

Changing Color Schemes Dynamically

In order to provide end-users the ability to change graphical user interface themes dynamically, move the StyleInclude line to a control other than Application . The StyleManager class shown below takes in a Window via the constructor, and provides the ability to change UI themes at runtime via the UseTheme method invocation.

See Avalonia Documentation for further details about building custom themes and adjusting styles. The source code of the Citrus theme described in this post may help as well, in case if you are going to build your own GUI theme. The sandbox project contains the control gallery shown in the pictures contained in this post. If you encounter any issues regarding the Avalonia GUI framework or the Citrus theme, head over to Avalonia Gitter. See the article Building Cross-Platform Reactive .NET Apps for more insight into the architecture used in XAML-based cross-platform C# applications.

Further work could cover more UI design guidelines. Folks from the Avalonia community have started working on the Material Design theme. Additionally, worth implementing the new Microsoft Fluent Design System and Apple Human Interface Guidelines.

A Cross-Platform GUI Theme for Desktop .NET Core Applications was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you are a C# programmer designing API of a tiny search engine. The engine is really simple — it searches for goods in a database using a query string provided by a user. You sit down, decide not to focus on implementation details yet, and write a simple C# interface:

Fine. You still don’t want to focus on implementation details, you’d like to ask someone to implement that interface for you. But before doing that, you ask yourself — what will happen, if your mate writes buggy code and such code passes code review? You decide to analyze potential issues and try to eliminate them. So, what’s wrong with the contract defined above?

1. The Search method accepts a string. C# doesn’t prevent you from passing null instead of a string to that method, but will the search engine implementation handle the null value correctly? Will it fail fast or return some search results? No answer.
2. The Search method returns a Task<T> , which can also be null. Yeah, it is a really bad practice to return null from methods returning tasks, but bad things happen.
3. The Search method can return a Task containing a null value. Is this meant to be correct behavior or not, what that null value means — again, no answer.
4. The search method executes correctly, consumes a query string, and returns a sequence of search results. Assuming SearchResult is a reference type, is there any guarantee, that our program will never fail with NullReferenceException when we try to access a SearchResult instance property in our code? No, we have to trust the implementation details.
5. Exceptions. Who knows, what exceptions a custom search engine might throw. The exceptions apparently are not documented anywhere yet.

If you use JavaScript without type annotations, the issues amount is actually a lot bigger than those 5 mentioned applicable to C#. Assuming all the above, the safe way of calling the ISearchEngine.Search method is something like this:

No one writes such code! Most time we don’t handle all these cases separately and simply let the program fail at run time if anything goes wrong. This means if we use a bad interface implementation, our software will likely crash.

Make Contracts More Reliable

Willing to make the contract more reliable, you, as a C# developer, download JetBrains.Annotations NuGet package, and annotate the code snippet above.

This is definitely better. You mark your input and output parameters with the NotNull and ItemNotNull attributes — so the project won’t compile if someone tries to use null s anywhere. Additionally, you document all possible exceptions that a search engine implementation might throw — so one can omit the global try catch block when working with that interface. Now, one can call the ISearchEngine.Search method safely!

This is the best way of resolving such issues with C#, but it isn’t a silver bullet. The person who implements the ISearchEngine interface can easily ignore recommendations defined in the signature, or turn ReSharper off. So, what do we have to do to absolutely trust our code base?

Write Unit Tests For Interface Implementations

This is quite obvious, and prevents our software from unexpected errors in most cases, but sometimes requires doing a ton of work each time the API changes. That’s why we move forward and try to learn new tools.

Use F#, Functional Programming and Types

F# is a strongly typed, multi-paradigm programming language that encompasses functional, imperative, and object-oriented programming methods. F# runs everywhere C# does.

Considering our search engine implementation, the first benefit we get when using F# is null safety. This means a reference type can never implicitly be null in F#. For example, a string variable can never be null, if we need to store a null value inside it, we use Nullable<string> type.

Yeah, no more null reference exceptions. Hopefully, null safety is going to be introduced in C#8. But now, if we rewrite our C# interface declared above in F#, we’ll eliminate four of five issues from our list! The only issue left is related to exceptions that are not documented.

Functional programmers don’t like exceptions. Although one can write a pure function that uses raise statements under the hood, exceptions violate referential transparency. Instead of exceptions, it’s better to use explicitly typed output and discriminated unions.

Assuming that, let’s refactor the C# interface declared above into F# types.

Here we describe all possible values that a function may produce, including errors, using a SearchResponse discriminated union. Instead of using implicit exceptions and XML documentation, we use types, and our code becomes self-documenting. Instead of using an interface here, we use a functional type. The search engine becomes a function that takes a query string and returns a response asynchronously. “Implementing” and using such function is simple.

We can finally trust the search engine implementation. Our app will never fail with null reference exceptions, and compiler forces us to handle all errors that a function may return, using pattern matching over a discriminated union. If we don’t handle all cases, we’ll receive a warning each time we are attempting to build the project. Far better!

Yeah, sounds tricky at first glance. If you find yourself interested and would like to learn more, visit F# For Fun and Profit website. Additionally, it’s worth reading “Domain Modelling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#” book by Scott Wlaschin for more real-world code examples and best practices. Code snippets in this article are highlighted using carbon.now.sh online service.

Telegram is a secure instant messaging service providing a platform that allows creating bots — the Telegram Bot API. A Bot is a Telegram account operated by software. There are Bot API implementations for almost every popular programming language, including Python, JavaScript, and C#. Funogram is a strictly typed Telegram Bot API wrapper built completely in F#, a cross-platform functional-first programming language. If you are new to F#, check this guide to get started. In this article, we are going to build our first Telegram Bot using F#, Funogram, and .NET Core.

Getting Started

First, we need to download .NET Core SDK and an IDE we’d like to use — Visual Studio, Rider, or Visual Studio Code with Ionide plugin. To initialize a simple F# console application, we use .NET CLI:

dotnet new console --lang F#

Then we need to install Funogram and download the missing packages:

dotnet add package Funogram && dotnet restore

From that point, we can start writing F# code!

Creating a Listener

The easiest way to communicate with Telegram servers is through long-polling. Long-polling is an emulation of pushing data, implemented by repeated polling with a delayed response. The good news is, that Funogram takes care of this for us and the only thing we have to do is to invoke the startBot function, so every update received from Telegram will trigger our handler.

Note that we don’t have to specify the type of function parameter context explicitly (it is Funogram.Bot.UpdateContext indeed), the compiler analyzes our code and infers types for us. bot-token is a Telegram Bot token received from Bot Father. Let’s run our code to see if everything goes well:

dotnet run

Handling Commands

Now it’s time to extend the functionality of our bot. Let’s teach him to greet users. The Funogram library uses Option Monads for handling optional Telegram API response values instead of nullability. To simplify our codebase and to avoid huge pattern matching nestings we can install the ExtCore library and use a MaybeBuilder from theExtCore.Control module.

dotnet add package ExtCore && dotnet restore

If you are new to monads and computation expressions, this article may help you get started. Funogram provides Funogram.Api.processCommands function allowing us to link commands to handlers. sendMessage constructs a request to Telegram Bot API, and api builds an asynchronous operation we need to start using Async.Start function.

Now our Telegram bot can greet users!

Further Learning

Funogram sources are available on GitHub. The complete Telegram Bot API reference can be found here, F# types and functions — here and here. If you get the Unable to read data from the transport connection exception, then it seems that Telegram is blocked in your country and you may need to set up a proxy. If you have any additional questions, feel free to ask the community on Slack or Telegram!

Validating forms with ReactiveUI and Fody

In the previous article, we took a look at several ways of implementing the MVVM pattern on the .NET platform. We found out, that the simplest approach is to use assembly weaving with reactive bindings and extensions. Now we are going to build a sample application using these techniques. Let’s start with the most common task — form validation.

Getting Started

The MVVM (Model-View-ViewModel) architectural pattern enforces the separation between three software layers, so we can think of extracting the layers into different assemblies. In order to achieve this, worth taking a look at .NET Standard — a formal specification of .NET APIs that are available across all .NET implementations.

Using the MVVM architectural approach and .NET Standard code sharing strategy, we can share our ViewModel and Model layers across multiple XAML UI frameworks. If we’ve built an app for the Universal Windows Platform, it would be rather easy to port it to other UI frameworks, such as Xamarin Forms, Avalonia, or Windows Presentation Foundation — UI will be the only thing we’ll need to build from scratch.

ReactiveUI and ReactiveUI.Fody libraries are fully compatible with .NET Standard, so we’ll use them in our sample application.

Form Validation Logic

Now we are ready to create our first reactive view model and populate it with some logic. Imagine we are developing a complex system and would like to gather feedback from users.

When a user sends us a message, we need to know whether the message is a bug report or a feature suggestion, we also need to group messages by categories. Users shouldn’t be able to submit feedback until they provide all the necessary information. A view model satisfying these conditions might look like the one below.

We mark the properties of our view model class with Reactive attributes— so all the marked properties will notify our UI when their values change. Using the WhenAnyValue extension method, we can subscribe to such notifications. A call to WhenAnyValue returns anIObservable<T>, where T represents the type of the observed property value. Then, we apply the Where operator from reactive extensions that allows us to filter irrelevant events. Inside a lambda passed to the Subscribe method, we perform another view model property mutation.

WhenAnyValue allows us to observe as many properties as we would like to, so we validate the whole form each time any of the form fields change. The Log extension method is a magic utility that logs all values emitted by an observable to the debug output. There are logging adapters for NLog, Serilog, and Log4Net. The Publish and RefCount operators are used to ensure the observable event stream will be subscribed only once. We pass the IObservable<bool> to the ReactiveCommand that is responsible for form submitting, so the command will stay disabled until a user fills the form up.

We mark the view model class with IEnableLogger and IActivatableViewModel interfaces. The former is used to enable logging extensions, and the latter is used to enable the WhenActivated feature. The DisposeWith extension method attaches the disposable produced by the Subscribe method call to the CompositeDisposable that will be disposed of once the view model deactivates.

Unit Testing

Testing is an important part of the software development process. We can use XUnit to run unit tests either on .NET Core or on .NET Framework. The NSubstitute library allows us to easily generate stubs and mocks, and FluentAssertions can improve the readability of our tests’ stack traces. Let’s write a test to ensure our presentation logic performs as expected!

UI For Universal Windows Platform

Creating a presentation part of the application is simple: we need to declare controls in XAML, and bind their values to view model’s properties and commands. Here is the code:

We need to implement the IViewFor<TViewModel> interface in our platform-specific view class. This makes activation and deactivation feature available for both our view and the associated view model. The view model should implement the IActivatableViewModel interface. A call to WhenActivated added to the view constructor will activate the corresponding view model.

Finally, we get a good-looking feedback form component!

UI For Xamarin Forms

In order to port the app to Android devices, we create a new Xamarin.Forms project from Visual Studio templates and add a reference to our .NET Standard class library containing view models. XAML markup will look like the one created for the Universal Windows Platform, but we’ll use cross-platform mobile-friendly controls provided by Xamarin.Forms. We also install ReactiveUI.AndroidSupport package into the Xamarin.Android project.

UI For Avalonia & Windows Presentation Foundation

It’s really easy now to port our application to Avalonia and Windows Presentation Foundation frameworks. For each framework, we create a platform-specific project and reference our .NET Standard class library. Also, we install ReactiveUI platform-specific packages according to the ReactiveUI installation guide. From that point, we can start building the UI.

UI For Windows Forms

Another useful feature ReactiveUI provides is type-safe binding that can be used on any platform, even if it isn’t XAML-based. For example, with ReactiveUI.WinForms package we can use the MVVM pattern with Windows Forms. In order to have the bindings working, we create a new form, implement the IViewFor interface, and place the binding extension methods into the WhenActivated block.

As we see, .NET stack allows us to build truly cross-platform software — using UWP, Xamarin.Forms, WPF, and Avalonia UI XAML frameworks we can bring our applications to devices running Android, iOS, Windows, Linux, and macOS operating systems. The MVVM pattern and such libraries, as ReactiveUI and Fody, can simplify the process of creating portable software, allowing developers to write clear and maintainable code.

The source code of the application described in this article can be found on GitHub: https://github.com/worldbeater/ReactiveMvvm ✨ Additionally, worth taking a look at a cross-platform application that demonstrates the usage of all the features described above. That application can be considered as a more comprehensive example, which is compatible with Windows, Linux, macOS, and Android.

Worth noting that additional validation helpers are available in the new ReactiveUI.Validation NuGet package. ReactiveUI.Validation includes INotifyDataErrorInfo implementation, helpers that allow to attach and detach validation rules dynamically, and the BindValidation extension method. The ReactiveUI.Validation library is cross-platform and could be used in both mobile and desktop apps that require complex validations.

Implementing the MVVM pattern with ReactiveUI and Fody

A portable and maintainable codebase is important, especially in large-scale and cross-platform .NET implementations. On XAML-based platforms, such as Windows Presentation Foundation (WPF), Universal Windows Platform (UWP), Xamarin Forms, and AvaloniaUI you can achieve maintainability goals by implementing the MVVM pattern.

MVVM stands for Model-View-ViewModel, where Model represents services, data transfer objects, and database entities related to the application domain, View is the UI and ViewModel’s responsibility is to tie these two layers together in a convenient way. ViewModel encapsulates interaction with Model, exposing properties and commands for XAML UI to bind to.

Traditional MVVM Implementation

To make bindings work a typical ViewModel should implement the INotifyPropertyChanged interface and call the PropertyChanged event when any of ViewModel’s properties change. A straightforward implementation may look like this:

With the following XAML describing our UI:

Works like a charm. When a user types their name into the text box, the text block placed below displays: “Hello, %username%!”. Values of these two controls stay synchronized — when the text box’s content changes, the text block updates itself immediately. Button clears the text box.

But wait! Our UI only needs two synchronized observable properties and one command, why do we have to write more than 20 lines of code to achieve that? What will happen, if we decide to add more properties representing ViewModel state? The code will bloat, becoming increasingly harder to understand and maintain!

Recipe #1. Observables. Shorter Getters And Setters. ReactiveUI

Well, the property change notifications boilerplate code issue is not new, and there are several solutions. Let’s take a look at ReactiveUI. It is a cross-platform, composable, functional reactive MVVM framework that brings the power of Reactive Extensions for the .NET platform. It also provides an INotifyPropertyChanged base class named ReactiveObject and a bunch of extension methods. Let’s modify our code snippet and see, how its reactive version looks like.

This snippet does exactly the same as the previous one but is shorter, more predictable, easier to understand and maintain. Property relations are described in one place using declarative ReactiveUI syntax. But this code is still quite verbose — we have to implement getters, setters, and backing fields explicitly.

Recipe #2. Boilerplate Code Encapsulation. Reactive Property

Another solution is to use reactive bindings from the ReactiveProperty library. This package provides wrapper classes responsible for sending notifications to the UI. Here ViewModel does not need to implement any interfaces, instead, each property implements INotifyPropertyChanged itself. Such properties also are observables — they can be mapped, filtered, combined, and so on. Let’s rewrite our sample using ReactiveProperty.

We only need to declare and initialize reactive properties and describe relations among them. No boilerplate code needed, except for property initializers. But this approach has a drawback — we should modify our XAML markup to make these bindings work as expected. Reactive properties themselves are wrappers, so UI needs to bind to each wrapper’s own property.

Recipe #3. Assembly Weaving. Fody + ReactiveUI

In a typical ViewModel, each property should send notifications to the UI when its value changes. With PropertyChanged.Fody package, a developer doesn’t have to take care of this. The only requirement is a ViewModel being marked with AddINotifyPropertyChangedInterface attribute — and code raising the property change event will be injected into setters automatically during the project build. If we need to turn our properties into observables, we can always use the WhenAnyValue extension method from ReactiveUI. Let’s rewrite our snippet again and see, how concise our code will become!

Fody manipulates the IL of an assembly at build time. PropertyChanged.Fody add-in searches for all classes implementing the INotifyPropertyChanged interface or marked with AddINotifyPropertyChangedInterface attribute, and modifies those classes’ property setters.

While this approach is great and allows us to write clean and simple code, outdated .NET Framework versions, including 4.5.1 and older ones, are no longer supported. This means you can actually use Fody with outdated versions but at your own risk while keeping in mind that any bugs found won’t ever get fixed. .NET Core versions are supported according to the .NET Core support policy.

Recipe #4. Assembly Weaving. ReactiveUI.Fody

Yet another option is to use the ReactiveUI.Fody package, which is now fully compatible with .NET Core. It works similarly to PropertyChanged.Fody, but uses the opt-in approach — you need to mark all properties with ReactiveUI.Fody attributes explicitly to have INotifyPropertyChanged boilerplate code injected into them at compile time. Additionally, this approach allows you to create get-only properties based on ObservableAsPropertyHelper that will always contain the latest value from an observable stream. Using readonly OAPHs in your codebase for describing computed properties allows you to benefit from compile-time checks that help you to ensure that your computed properties always contain the latest value from a certain IObservable<T> stream.

Hope this article helps you get started with implementing the MVVM pattern via Reactive Programming and keeping your code clean and concise. See the next chapter for more examples. If you are willing to learn ReactiveUI, check out the Getting Started tutorial and the ReactiveUI Handbook.