We commonly refer to the object encapsulating all of this as the host, and it’s typically configured through the Main method in a Program class. Alternatively, a Startup class can also provide an entry point to configuring the host. This is what the out-of-the-box generic host in ASP.NET Core looks like:
Because .NET MAUI will also use the .NET Generic Host model, we will be able to initialize our apps from a single location moving forward. It also provides us with the ability to configure fonts, services, and third-party libraries from a centralized location. We do this by creating a MauiProgram class with a CreateMauiApp method. Every platform invokes this method automatically when your app initializes.
The bare minimum this MauiProgram class needs to do is to build and return a MauiApp. The Application class, referenced as App in the UseMauiApp method, is the root object of your application. This defines the window in which it runs when startup has completed. The App is also where you define the starting page of your app.
We’ve covered the new concept of handlers earlier in this article. If you’re looking to hook into this new handler architecture, the MauiProgram class is where you register them. You do this by calling the ConfigureMauiHandlers method and calling the AddHandler method on the current collection of handlers.
In this sample, we are applying the MyEntryHandler to all instances of MyEntry. The code in this handler will therefore run against any object of type MyEntry in your mobile app. This is the preferred solution for when you want to target a completely new control with your handler. If all you want to do is change a property on an out-of-the-box control you can do this straight from the MauiProgram class as well, or really anywhere you know your code will run prior to the control being used.
This sample uses compiler directives to indicate that the handler code should only run on the Android platform because it uses APIs that are unavailable on other platforms. If you’re doing a lot of platform-specific code, you might want to consider using other multi-targeting conventions instead of littering your code with compiler directives. This essentially means separating your platform-specific code into platform-specific files suffixed with the platform name. By using conditional statements in your project file, you can then ensure that only the platform-specific files are included when compiling for those specific platforms.
Using existing Xamarin.Forms custom renderers
If you’re looking to migrate an existing Xamarin.Forms app to .NET MAUI you might already have written custom renderers to handle some of the functionality of your app. These are usable in .NET MAUI without too much adjustment, however, it is advised to port them over to the handler infrastructure. To use a Xamarin.Forms custom renderer register it in the MauiProgram class.
Using the AddCompatibilityRenderer method, we can hook up a custom renderer to a .NET MAUI control. You need to do this on a per-platform basis, so if you have multiple platforms you will need to add the renderer for each platform individually.
This post was originally part of an article written for CODE Magazine’s Focus issue on .NET 6.0. This article was written based on the available Preview builds at the time. Current previews might have changed things compared to the article.