In this article, we are going to see the MauiAppBuilder class, because it was added, and some other code implemented there so that we can understand how the structure of our applications works in .NET MAUI.
This is the first article in the series: Exploring MAUI App Builder. In this series we’ll talk about some new features included in .NET MAUI.
What is the MauiAppBuilder?
If you’ve been wondering “What is MauiAppBuilder” well, then you’ve missed out on the latest news related to .NET MAUI. But don’t worry, we’re here for you.
MauiAppBuilder was added to support the new mobile app model with .NET MAUI to simplify the initial configuration code and some others plus. However, MauiAppBuilder is very much an implementation detail. It was introduced to optimize a specific scenario (which I’ll describe shortly), but for the most part, you don’t need to know you’re using it.
Before we enter the MauiAppBuilder itself, let’s see what it is replacing and why.
Configuration in Xamarin.Forms
In Xamarin.FOrms we have many ways or specific forms depending on the case, to configure the resources that we are going to use in our application.
For example:
- Fonts – You can add them to your shared project and register them in the assembly.
- Images – You can add them to your shared project and use an extension to use them.
- Crossplatform Native LifecycleEvents – Located in each individual project, the most general ones are supported by booksellers that you can use in your shared project.
- Renderers – Located in each individual project with assembly-level registration.
- Among others.
Depending on the resources we want to use, the configuration may be different or increase in terms of complexity. Thanks to the Xamarin.Forms ecosystem all this is well documented and I do not think we have problems with the configuration of these resources.
If the configuration system works fine in Xamarin.Forms then why do we need an AppBuilder in .NET MAUI?
The “partial configuration” issue in Xamarin.Forms
The main problem is when you need to configure/develop certain resources that need to be hosted in native projects you need to go to each project individually to add these configurations.
However, it must be said that it may seem a bit unnecessary or boring to have so many places to set up x or y.
For example, every time you have to set up a library that needs access to native projects you have to go to each individual project to set it up. This is still working like this.
For the more general resources the solution was:
Move settings to our shared project. Here we can see for example:
- Images
- Fonts
- And that’s it…
This is the only configuration that we can share between our projects and they are still a bit manual so to speak.
And that’s where MauiAppBuilder comes in.
MauiAppBuilder in .NET MAUI
Apart from simplifying the model of our application with .NET MAUI, the MAUI team added the MauiAppBuilder. A class that will allow us to build and configure our applications in a unified way.
Currently, the MauiAppBuilder has support for:
- Fonts – You can register your fonts and add an alias to them
- Images – No configuration needed
- Animations – No documentation at the moment
- Crossplatform LifecycleEvents – You can easily connect to native events.
- Handlers – Custom Control Registry
- LogginBuilder– It looks like we’ll have a logger. No documentation at the moment
- ServicesCollection – Collection of Registered Services
- ConfigurationManager – Collection of registered configurations
...
/// <summary>
/// A builder for .NET MAUI cross-platform applications and services.
/// </summary>
public sealed class MauiAppBuilder
{
private readonly HostBuilder _hostBuilder = new();
private readonly BootstrapHostBuilder _bootstrapHostBuilder;
private readonly MauiApplicationServiceCollection _services = new();
private readonly LoggingBuilder _logging;
private readonly ConfigureHostBuilder _host;
private MauiApp? _builtApplication;
internal MauiAppBuilder(bool useDefaults = true)
{
...
}
/// <summary>
/// A collection of services for the application to compose. This is useful for adding user provided or framework provided services.
/// </summary>
public IServiceCollection Services { get; }
/// <summary>
/// A collection of configuration providers for the application to compose. This is useful for adding new configuration sources and providers.
/// </summary>
public ConfigurationManager Configuration { get; }
/// <summary>
/// A collection of logging providers for the application to compose. This is useful for adding new logging providers.
/// </summary>
public ILoggingBuilder Logging => _logging;
/// <summary>
/// An <see cref="IHostBuilder"/> for configuring host specific properties, but not building.
/// To build after configuration, call <see cref="Build"/>.
/// </summary>
public IHostBuilder Host => _host;
/// <summary>
/// Builds the <see cref="MauiApp"/>.
/// </summary>
/// <returns>A configured <see cref="MauiApp"/>.</returns>
public MauiApp Build()
{
...
}
...
}
...
With MauiAppBuilder, when it is called ConfigureFonts() method, for example, the builder loads this configuration and then builds the app with this configuration later with the Build() method.
Implementing this is easier than as described because the interface exposes the configuration settings we need.
...
public static MauiApp CreateMauiApp()
{
var builder = MauiApp.CreateBuilder();
builder
.UseMauiApp<App>()
.ConfigureFonts(fonts =>
{
fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
});
return builder.Build();
}
...
As you can see, we can now manage the configuration of resources of our application in one place in a more attractive way and with many attractive functionalities that are added as a plus.
Will we be able to handle everything inside the MauiAppBuilder? Well, no.
Every time I see this pattern I can’t help but compare it to ASP.NET Core Web API. It’s like it’s a good start, but it lacks a little more.
In ASP.NET Core we can map our drivers for the topic of navigation, or know if we are in a development environment to register extra services if necessary; like we don’t have in the MauiAppBuilder.
It would be fantastic to be able to manage the navigation of our applications at the service level and not have to depend on an external library for this.
So, should I worry about MauiAppBuilder?
So, having read all of this way, should you care if you’re using MauiAppBuilder or not?
Probably not.
The new MauiAppBuilder introduced in .NET MAUI optimizes the use case I described earlier where you need to build your configuration for your application.
However, the configurations introduced in Xamarin.Forms are still very compatible with .NET MAUI, and continue to use types and behind the scenes.
The only situation I can think of you to be careful about is whether you are, or want to, modify or extend the MauiAppBuilderclass. That seems very unlikely to me, and if you do, I’d be interested to know why!
But other than that niche exception, no, there’s no need to worry. Just be happy knowing that if you need to do a “partial setup,” and you’re using the new MauiAppBuilder, your app will be a little more effective!
Summary
In this post, I described the new MauiAppBuilder introduced in .NET MAUI. MauiAppBuilder was introduced to optimize a common situation where you need a “partially built” configuration. Typically, this is because a configuration provider requires some configuration, for example, loading secrets for a configuration that indicates which API to use.
MauiAppBuilder optimizes this scenario by loading our initial configuration before building our application.
This is the first article in the series: Exploring MAUI App Builder. In this series we’ll talk about some new features included in .NET MAUI.
