Chapter 6 MAUI

Application Lifecycle

Applications go through different stages while running, stages like starting, stopping, sleeping, and resuming. These differ depending on the platform your app is running on. A mobile application will go to sleep once it’s moved to the background to preserve battery; a WPF application, for example, will keep running even when minimized, choosing efficiency over battery life.

Why is this important to know, and use, as a developer? Consider you’re building a mobile app. The app contains a registration form; one of your users is filling out the form and suddenly gets a call before being able to press the save button. A call pushes

your app to the background, giving priority to the phone app. If this is a high-end device, the app might keep its data in the background, but the mobile operating system might decide that the app is taking up too many resources in the background and to remove

it from memory while still keeping it in the open apps list. That’s why, as a developer, you need to hook into the pausing event. We can use this event to temporarily store data, like the data already entered in the form, and resume that data when the resuming event fires.

Lifecycle events in MAUI are abstracted away from the platform. That means that there is a common API that will work over all platforms, but they have a different implementation under the hood. It also means that the common API is built mostly on top of structures that are available across all platforms. It’s possible to break out of the shared layer and go into platform-specific code, should you need more fine-grained control of the lifecycle on a specific platform.

There are a number of lifecycle events available, on different parts of an application. The following tables Lifecycle events on application level (Table 6-1), Lifecycle events on window level (Table 6-2), Lifecycle events on page level (Table 6-3), and Lifecycle events on view level (Table 6-4) provide a complete list of the available lifecycle events at the time of writing.

161

Chapter 6 MAUI

Table 6-1.  Lifecycle events on application level

Table 6-2.  Lifecycle events on window level

162

Table 6-3.  Lifecycle events on page level

Table 6-4.  Lifecycle events on view level

163

Chapter 6 MAUI

MVVM

Xamarin.Forms brought XAML into the cross-platform mobile world as an abstraction layer on top of the supported platforms their own UI stack. It’s an XML-based layout and style engine that transform into platform-native elements at compile time by default. Just like the WPF XAML stack, it supports databinding, templating, resource dictionaries, and so on. This book is not a XAML guide, but MAUI has made some changes in the available design patterns for writing cross-platform apps, so I’ll provide a high-level overview.

Model-View-ViewModel (MVVM) was introduced in 2005 by Microsoft architects Ken Cooper and Ted Peters. They developed a pattern that leveraged databinding to decouple data and logic from the view so that the view could be developed separately from the logic and so that the logic could be unit-tested without creating the entire visual tree.

MVVM consists of three layers:

The most important part is the ViewModel; you can compare it to a controller in MVC, but stateful. A ViewModel for a specific view gathers all the data the view needs, shapes it into bindable properties, and makes sure to react to property changes where needed. A view in MAUI has a BindingContext property which needs to contain a reference to the correct ViewModel, as shown in Listing 6-6.

Listing 6-6.  Setting a BindingContext on a MAUI ContentPage

public MainPage()

{

InitializeComponent(); BindingContext = new MainViewModel();

}

From this moment on, all bindings that do not specify another BindingContext will turn to the MainViewModel class to resolve their bindings when requested.

164

Chapter 6 MAUI

Databinding in MAUI with XAML is the same as with Xamarin.Forms and quite similar to databinding in WPF (or Silverlight if you want to go way back). Let’s look at an example using a ViewModel.

I’ve created a new project using the default MAUI XAML template. I’ve added a ViewModels folder and created a MainViewModel inside that folder. Listing 6-7 shows the created MainViewModel.

Listing 6-7.  MainViewModel

public class MainViewModel

{

private ICommand _increaseCountCommand;

public int Count { get; private set; }

public ICommand IncreaseCountCommand => _increaseCountCommand ??= new Command(IncreaseCount);

private void IncreaseCount()

{

Count++;

}

}

Let’s start with Count; Count is a basic auto-property with a private set, nothing special there so far. It’s a public property which means it’s available to bind to. The datatype here is integer, but it can be anything, even complex objects.

IncreaseCountCommand is an ICommand which is an abstraction of reacting on user actions. ICommand is an interface from the System.Windows namespace. It’s used for exactly this use case in WPF, UWP, and every other XAML-based framework. The Command implementation however lives in the Microsoft.Maui assemblies. This way

Microsoft is giving us a way to use familiar concepts, while under the covers, it is a brand new implementation. In this case, we will attach the IncreaseCountCommand to a button tap in a minute. We’re using C# 8’s null-coalescing assignment feature to assign an ICommand implementation. This means that when the property’s getter is called, it will check for null and first assign the value if it is null; if not, it will return the value.

165

Chapter 6 MAUI

We could also initialize the command using the constructor as shown in Listing 6-8.

Listing 6-8.  The same MainViewModel but with command initialization done in the constructor

public class MainViewModel

{

public int Count { get; private set; }

public ICommand IncreaseCountCommand { get; private set; }

public MainViewModel()

{

IncreaseCountCommand = new Command(IncreaseCount);

}

private void IncreaseCount()

{

Count++;

}

}

This works just the same, so where’s the difference? When binding to an ICommand, the getter is only being called when the command is triggered. Meaning that a page will load, but the IncreaseCountCommand will not be initialized yet as long as the user does not tap the button. On a page with a lot of commands, this shaves of precious time of the viewmodel initialization; we’re basically deferring initializing each command until it’s needed for the first time.

In MainPage.xaml, we’ll transform the basic example from the MAUI template into an MVVM example. We’ll start by removing most of the code in MainPage.xaml.cs, as that logic now lives in the MainViewModel.

Listing 6-9.  Cleaned up MainPage

public partial class MainPage : ContentPage

{

public MainPage()

{

InitializeComponent();

166

Chapter 6 MAUI

BindingContext = new MainViewModel();

}

}

There are some parts we still need of course. Notice that this class is partial; the other part of the partial class is the XAML file itself. The XAML compiler transforms that XAML code into a partial C# class.

Do not remove InitializeComponent; this method call triggers the creation of all elements on page. This should typically be the first call in the constructor of a page. After that, we set the BindingContext; as mentioned before, this will bubble down to all elements on that page unless we specifically assign another BindingContext to an element.

In XAML, we need to change the label and the button to bind to the properties on our ViewModel. Listing 6-10 shows the label.

Listing 6-10.  Label with binding

<Label

Text="{Binding Count}" Grid.Row="2" FontSize="18" FontAttributes="Bold" x:Name="CounterLabel"

HorizontalOptions="Center" />

Let’s zoom into the binding; all other properties speak for themselves. A binding statement is always set between squiggly brackets. We use the Binding keyword to tell MAUI that we want to dynamically bind to a property on the BindingContext. Keep in mind that there is no IntelliSense here because we’ve set the BindingContext in C# land; the XAML editor does not know this. Since we’re compiling our XAML code, we do get compile-time errors on typos. So, by putting Text="{Binding Count}" we’re

telling MAUI that we want the value of BindingContext.BindingProperty or in this case MainViewModel.Count to be put into the Text property of this label. Listing 6-11 shows the bindings for the Button.

167

Chapter 6 MAUI

Listing 6-11.  Binding a command to a button

<Button Text="Click me"

Command="{Binding IncreaseCountCommand}" FontAttributes="Bold"

Grid.Row="3"

SemanticProperties.Hint="Counts the number of times you click" HorizontalOptions="Center" />

For the button, we bind to its Command property. When the element’s default action (Click or Tap in case of a button) is triggered, the system will try to cast the object bound to Command to an ICommand and trigger its Execute method. Note that it is possible to assign both a click event handler and a command to a button; both will fire if the button is tapped.

Let’s try it out! Launch the app and you should see something similar to Figure 6-6 (your version might look different depending on the platform you’re targeting).

Figure 6-6.  Running the MVVM-based app

Notice the “0” on top of the page? That’s our databinding at work; the Count property has a default value of 0, and thanks to databinding, we see that value reflected on page. Click the button and you’ll see that… nothing happens? Have we made a mistake? If you put a breakpoint in the IncreaseCount method in the MainViewModel, you’ll see that it hits whenever we click the button, and the integer’s value does increase, so why doesn’t the new value show on the page? The answer is simple: the databinding system does

not constantly monitor its BindingContext for changes; this would simply cost too many resources. Instead it trusts us as developers to tell it when a value changes so that it can refresh that property; this is done by using the InotifyPropertyChanged interface. We can implement this interface on our MainViewModel as shown in Listing 6-12.

168

Chapter 6 MAUI

Listing 6-12.  Implementing INotifyPropertyChanged

Public class MainViewModel : InotifyPropertyChanged

{

private int _count;

private Icommand _increaseCountCommand;

public int Count

{

get => _count; set

{

if (_count == value) return;

_count = value;

PropertyChanged?.Invoke(this, new PropertyChangedEventArgs (nameof(Count)));

}

}

public Icommand IncreaseCountCommand => _increaseCountCommand ??= new Command(IncreaseCount);

private void IncreaseCount()

{

Count++;

}

public event PropertyChangedEventHandler PropertyChanged;

}

INotifyPropertyChanged has one member, an event called PropertyChanged. That event takes the name of the property that just changed as a string parameter. We are using the nameof() method to prevent typing errors in magic strings. The nameof method gets replaced by the actual name of the member we pass in at compile time, so

using this has no impact on the runtime performance. The binding framework listens for this event, takes the name of the property that just changed, looks for it in its bindings, and refreshes that specific binding. Triggering that event can happen wherever you need

169