Deep Dive on MAUI Application

Introduction

Regardless of the platform, developers of enterprise apps encounter several challenges:

– Evolving app requirements over time.

– Emerging business opportunities and challenges.

– Continuous feedback during development that can significantly impact the app’s scope and requirements.

Building adaptable apps requires an architecture that allows for easy modification or extension over time. This involves designing the app so that individual parts can be developed and tested independently without affecting the rest of the app.

Many enterprise apps are complex and require multiple developers, making it challenging to design the app in a way that allows for independent development while ensuring seamless integration.

The traditional monolithic approach, where components are tightly coupled, often results in apps that are hard to maintain. Bugs are difficult to fix without impacting other components, and adding or replacing features is inefficient.

This article will help you understand and focus on the core patterns and architecture for building a cross-platform enterprise app using .NET MAUI. My article is designed to help you produce adaptable, maintainable, and testable code by addressing common .NET MAUI enterprise app development scenarios.

Model-View-ViewModel pattern (MVVM)

The MVVM (Model-View-ViewModel) pattern consists of three essential components: the model, the view, and the view model. Each element plays a distinct role in the architecture. The accompanying diagram visually depicts the intricate connections between these components.

The view defines the structural layout and visual presentation that users see on the screen. It’s recommended that each view be outlined in XAML, keeping the code minimal and free from business logic.

The view model defines properties and commands for data binding with the view. It notifies the view of any state changes through change notification events. These properties and commands outline the UI’s functionalities, while the view determines how they are displayed.

Model classes act as non-visual entities that encapsulate an application’s data. Essentially, the model represents the domain model of the application, often incorporating a data model alongside business and validation logic.

How to connect view models to views:

Create a view model declaratively:

– The simplest approach is for the view to declaratively create its associated view model in XAML. When the view is instantiated, so is the corresponding view model object. This method is demonstrated in the following code snippet.

Unset

<ContentPage xmlns:local=”clr-namespace:example”>
<ContentPage.BindingContext>
<local:LoginViewModel />
</ContentPage.BindingContext>
<!– Omitted for brevity… –>
</ContentPage>

Creating a view model programmatically

– In the code-behind file of a view, you can assign the view model to its BindingContext property. Typically, this assignment takes place in the view’s constructor, as shown in the following code example.

Updating views in response to changes in the associated view model or model.

– Every view model and model class accessible to a view should implement the INotifyPropertyChanged interface. This interface allows the class to inform data-bound controls given any changes in the underlying property values.

– For example, the following code shows a simple ViewModel with properties that raise changes.

Using the MVVM toolkit in modular mobile applications enhances the architecture, making the app more maintainable, testable, and scalable.

– The MVVM pattern is well-established in .NET, supported by a variety of frameworks developed by the community to simplify its implementation. Each framework offers a unique set of features, but they generally include a standard view model with an implementation of the INotifyPropertyChanged interface. Additional functionalities often provided by MVVM frameworks include custom commands, navigation aids, dependency injection/service location modules, and seamless integration with UI platforms.

– The example below shows the same ViewModel using components that come with the MVVM Toolkit:

ObservableObject manages all the logic required for raising change notifications by utilizing the SetProperty method within your property setter.

UI interaction through commands:

– In multi-platform applications, user interactions such as button clicks typically trigger actions, often implemented through event handlers in the code-behind file. However, within the MVVM pattern, executing these actions is the responsibility of the view model, and it is recommended to avoid placing code directly in the code behind.

– View models typically expose public properties that implement the ICommand interface for binding from the view.

– The Command or Command constructor requires an Action callback, which is called when the ICommand.Execute method is invoked. An optional constructor parameter, CanExecute, is a Func that returns a bool.

The MVVM Toolkit includes two commands: RelayCommand and AsyncRelayCommand. RelayCommand is suitable for executing synchronous code and shares a similar implementation with the .NET MAUI Command object.

AsyncRelayCommand offers numerous additional capabilities for handling asynchronous workflows. This is frequently encountered in our ViewModel, as it often involves communication with repositories, APIs, databases, and other systems that rely on async/await operations.

Dependency injection

Dependency injection, a specialized form of the Inversion of Control (IoC) pattern, focuses on acquiring necessary dependencies by delegating the responsibility of injecting these dependencies into an object at runtime to another class.

The code example below demonstrates the structure of the ProfileViewModel class when utilizing dependency injection:

Using a dependency injection container offers several advantages:

– It eliminates the need for a class to locate its dependencies and manage its lifetimes.

– It allows dependencies to be mapped without affecting the class.

– It facilitates testability by enabling the mocking of dependencies.

– It enhances maintainability by making it easy to add new classes to the application.

In a .NET MAUI app utilizing MVVM, a dependency injection container is generally employed to register and resolve views and view models, as well as to register services and inject them into view models.

The following code example demonstrates how the MAUI app declares the CreateMauiApp method in the MauiProgram class:

RegisterViewModels, and RegisterViews were created to help provide an organized and maintainable registration workflow. The following code shows the RegisterViewModels method:

The following table guides when to choose different registration lifetimes.

– .NET MAUI supports both automatic and explicit dependency resolution. Automatic dependency resolution uses constructor injection without explicitly requesting dependencies from the container. Explicit dependency resolution happens on demand by directly requesting a dependency from the container.

– In this example, the MainPage constructor receives an injected MainPageViewModel instance. The MainPageViewModel instance, in turn, has ILoggingService and ISettingsService instances injected.

The dependency injection container can be explicitly accessed from an Element through its Handler.MauiContext.Service property, which is of type IServiceProvider:

In summary, dependency injection decouples concrete types from the code that depends on them. It typically involves a container that maintains a list of registrations and mappings between interfaces or abstract types and the concrete types that implement or extend them.

Messenger between components

The publish-subscribe pattern is a messaging model where publishers send messages without being aware of the receivers, known as subscribers. Likewise, subscribers listen for specific messages without knowing the publishers.

In .NET, events embody the publish-subscribe pattern and serve as the straightforward method for inter-component communication when loose coupling isn’t necessary, like between a control and its containing page. Nonetheless, memory management issues may arise from the lifetimes of publishers and subscribers, particularly when short-lived objects subscribe to events of static or long-lived objects.

Prior to .NET 7, we used the Messaging Center publish-subscribe pattern. With the release of .NET 7, Messaging Center has been deprecated and replaced by IMessenger in the CommunityToolkit.Mvvm.

The IMessenger interface outlines the publish-subscribe pattern, facilitating message-driven communication between components that are challenging to connect through object and type references.

The IMessenger interface enables multicast functionality for publish-subscribe operations. This implies that multiple publishers can send a single message, while multiple subscribers can listen to that same message.

There are two implementations of the IMessenger interface that come with the CommunityToolkit.Mvvm package.

– The WeakReferenceMessenger employs weak references, making it easier to clean up message subscribers. This is an ideal choice if your subscribers lack a clearly defined lifecycle.
– The StrongReferenceMessenger utilizes strong references, leading to improved performance and a more precisely managed subscription lifetime.

Define Message:

– IMessenger messages consist of custom objects carrying personalized payloads.

Publishing a message

– To broadcast a message, we utilize the IMessenger.Send method, typically accessible via WeakReferenceMessenger.Default.Send or StrongReferenceMessenger.Default.Send. Messages can encompass any object type.

– The Send method publishes the message and its payload using a fire-and-forget approach. As a result, the message is sent even if no subscribers are registered to receive it, and in such cases, the message is simply ignored.

Subscribing to a message

– Subscribers can register to receive messages by using one of the IMessenger.Register overloads.

– If payload data is provided, avoid modifying it within a callback delegate since multiple threads may simultaneously access the data. To prevent concurrency errors, the payload data should be immutable.

Unsubscribing from a message payload:

– Subscribers can opt out of receiving messages they no longer wish to receive using one of the IMessenger.Unregister overloads, as shown in the following code example:

Summary: Messenger facilitates message-based communication between components that are difficult to connect through object and type references. This mechanism enables publishers and subscribers to interact without direct references to each other, reducing dependencies between components and allowing for independent development and testing.

Assessing remote data

Many modern web-based solutions utilize web services hosted on web servers to deliver functionality to remote client applications. The operations are exposed by a web service from a web API.

Client apps should be able to use the web API without needing to understand the implementation details of the data or operations it exposes.

Making the HTTP Requests:

– The MAUI application employs the HttpClient class to send HTTP requests, utilizing JSON as the media type.

– This class enables asynchronous sending of HTTP requests and receiving of HTTP responses from a resource identified by a URI.

To improve application performance, it is crucial to cache and reuse instances of HttpClient. Creating a new HttpClient for each operation can cause socket exhaustion issues.

Making a GET request:

– Making a POST request:

Making a DELETE Request

If an app detects a failure when attempting to send a request to a remote service, it can handle the failure in any of the following ways:

– Retrying the operation: The app can immediately retry the failed request.

– Retrying the operation after a delay: The app should wait for an appropriate amount of time before attempting the request again.
– Cancelling the operation: The application should cancel the request and report an exception.

The retry pattern should be tailored to the app’s business requirements. For instance, it’s crucial to fine-tune the retry count and interval for the specific operation being performed.

Implementing the Retry pattern using Polly in a .NET Core Web application enhances the application’s resilience by handling transient faults gracefully.

Validation

Any app that accepts user input must ensure its validity. For example, the app could verify that the input contains only characters within a specific range, meets a certain length or adheres to a particular format.

Lack of validation opens the door for users to input data that can lead to app failures. Effective validation enforces business rules and serves as a defense against potential injection of malicious data by attackers.

In the Model-View-ViewModel (MVVM) pattern, it’s common for a view model or model to handle data validation and communicate any validation errors to the view, enabling users to rectify them.

First Approach: Using Observable Validator in MVVM toolkit.

– The ObservableValidator is a base class implementing the INotifyDataErrorInfo interface, providing support for validating properties exposed to other application modules.

– It also inherits from ObservableObject, so it implements INotifyPropertyChanged and INotifyPropertyChanging as well.

ObservableValidator showcases the following primary functionalities:

– It furnishes a foundational implementation for INotifyDataErrorInfo, offering access to the ErrorsChanged event and other essential APIs.

– It offers the ValidateProperty method, allowing for manual triggering of property validation. This is particularly handy when a property’s validation relies on another property’s value, which may have been updated while the former remains unchanged.

– It provides the ValidateAllProperties method, which automatically validates all public instance properties within the current instance. This occurs only if they are adorned with at least one [ValidationAttribute].

– It features a ClearAllErrors method, handy for resetting a model linked to a form that users may need to refill.

Customizing Validation Techniques.

– An alternative approach to custom validation involves crafting a custom [ValidationAttribute] and embedding the validation logic within the overridden IsValid method.

Next, we can incorporate this attribute into our view model.

Second Approach: Customizing ValidableObject

– Properties in the view model that necessitate validation are of type ValidatableObject. Each instance of ValidatableObject has its validation rules appended to its Validations property.

– Validation in the view model is triggered by invoking the Validate method of the ValidatableObject instance. This method retrieves the validation rules and applies them to the ValidatableObject.Value property.

– Validation errors are stored in the Errors property of the ValidatableObject instance, while the IsValid property of the ValidatableObject instance is updated to reflect the success or failure of the validation.

The following code shows the implementation of the ValidatableObject:

Validation rules are specified by creating a class that derives from the IValidationRule interface

– This interface mandates that a validation rule class must include a boolean Check method for performing the necessary validation, and a ValidationMessage property to hold the error message displayed if validation fails.

– The following code example shows the IsNotNullOrEmptyRule validation rule.

So how  to add validation rules to a property in the view model:

Step 1: Declare the validated property in the view model. It needs to be type ValidatebleObject.

Step 2: Add validation rules to the Validations collection of ValidateObject instance.

Step 3: Trigger validation when property changes:

Unset

<Entry Text=”{Binding Email.Value}”>
<Entry.Behaviors>
<behaviors:EventToCommandBehavior
EventName=”TextChanged”
Command=”{Binding ValidateEmailCommand}” />
</Entry.Behaviors>
</Entry>

Step 4: Display validation errors

Unset

<material:TextField Title=”Email”
Text=”{Binding Email.Value}”
Keyboard=”Email”
Style=”{x:StaticResource EntryStyle}”>
<material:TextField.Attachments>
<Image Source=”error_container.png” Margin=”0,0,10,0″
IsVisible=”{Binding Email.IsValid, Converter={StaticResource Key=InvertedBoolConverter}}”/>
</material:TextField.Attachments>
<material:TextField.Behaviors>
<mct:EventToCommandBehavior
EventName=”TextChanged”
Command=”{Binding ValidateEmailCommand}” />
</material:TextField.Behaviors>
<material:TextField.Triggers>
<DataTrigger
TargetType=”material:TextField”
Binding=”{Binding Email.IsValid}”
Value=”False”>
<Setter Property=”BorderColor”
Value=”#F55718″ />
<Setter Property=”TitleColor”
Value=”#F55718″ />
</DataTrigger>
</material:TextField.Triggers>
</material:TextField>
Unset

<Label Text=”{Binding Email.Errors, Converter={StaticResource ListToStringConverter}}”
IsVisible=”{Binding Email.Errors, Converter={StaticResource IsListNotNullOrEmptyConverter}}”
FontSize=”14″
TextColor=”#F55718″/>

In summary, we will have a completed flow like this screenshot:

Summary

This article highlights several challenges encountered when developing an enterprise application and offers solutions to address them. To ensure your app can be modified or extended over time, it’s crucial to design it with adaptability in mind. This involves partitioning the app into discrete, loosely coupled components that can be easily integrated. While challenging, this approach guarantees the app remains flexible and maintainable.

Thank you for reading this article. In the next one, I’ll cover topics such as authentication, platform invocation, how to apply async/await in mobile apps, and unit testing ….  to help you tackle the challenges of developing an enterprise application. Stay tuned!

Reference: 

MAUI Documentation: Link

MAUI blog: Link

MAUI tutorial channel: Link