Simplify App Bootstrapping

[nickrandolph]

Currently app startup is quite complex:

• Three files: app.xaml, app.xaml.host.cs, app.xaml.cs
• Multiple phases: App constructor, XAML resource loading, Launched method, Window constructor, HostBuilder, Navigation Initialization

Goal is to simplify app bootstrapping to something like

App
    .Resources()
    .Logging()
    .Configuration()
    .Services()
    .Navigation()

[dansiegel]

To update from this morning's discussion, the focus would be around an IAppBuilder that gives you access to the Application and startup Arguments with a focus on providing delegates for the IHostBuilder and a method to create the IHost.

public interface IAppBuilder
{
    Application App { get; }
    string? Arguments { get; }
    Window Window { get; }
    IAppBuilder Configure(Action<IHostBuilder> configureHost);
    IHost Build();
}

This would be non-prescriptive in terms of requiring that the developer uses the Uno Navigation, etc, while still allowing more prescriptive extensions to be provided like:

public static async Task<IHost> ShowAsync<TShell>(this IAppBuilder builder, Func<IAppBuilder, TShell, ContentControl> getRootElement)
    where TShell : UIElement, new()
{
    var appRoot = new TShell();
    var navigationRoot = getRootElement(builder, appRoot);
    builder.Window.Content = appRoot;
    builder.Window.Activate();

    return await builder.Window.InitializeNavigationAsync(
        async () =>
        {
            return builder.Build();
        },
        navigationRoot: navigationRoot
    );
}

The advantage of this is that it can help clean up the Application's OnLaunched method like:

protected async override void OnLaunched(LaunchActivatedEventArgs args)
{
    await this.Build(args)
        .YourCustomExtension()
        .Configure(builder => {
            // call any existing IHostBuilder extensions
        })
        .ShowAsync<Shell>((builder, shell) => {
            shell.SplashScreen.Initialize(builder.Window, args);
            return shell.SplashScreen;
        });
}

Sample.zip

[francoistanguay]

App because some extensions might want to listen to Appplication events like UnhandledException?

Window, because Dan thought it was better to create the Window in the Build at the beginning somehow?

[dansiegel]

Window was there because it was easier to maintain between an extension like ShowAsync and then still be available for the SplashScreen init

[francoistanguay]

If splash happening within ShowAsync, dont see as much of a need, unless some extensions need it, like Navigation need it. We pass it explicitly in InitiNavAsync for now....

I think we could remove it and add it later once we find a need for it maybe...

[dansiegel]

Well it's being passed around in ShowAsync... like you need it to initialize the ExtendedSplashScreen and you need it to set the Shell and for the Initialize Navigation... so it's a nice clean way to be able to access it either in a callback for user code or for the ShowAsync in the version that I had posted.

[francoistanguay]

If ShowAsync creates it, it can pass it around internally, doesnt mean it should be exposed on IAB. Maybe am missing something. To be discussed then.

[francoistanguay]

Could we rename IAppBuilder to IApplicationBuilder?

If we keep the ShowAsync helper method in the framework, then in the template code I'd introduce a simple ShowAsync() extention method that contains the splashscreen callback init code to keep minimal api code as clean as possible.

Other idea would've been to introduce some more of IContentControlHost interface that nav init would be aware of and that Shell vould implement to expose its innter SplashScreen..... Not sure if any clearner but we wouldn't neet the ballback.

[nickrandolph]

I like the idea of having an IContentControlHost but perhaps make it more specific to navigation eg INavigationHost

[francoistanguay]

If we dont believe this interface could serve any other purpose, sure. Otherwise, even something more generic like IContentControlProvider could make sense.

[francoistanguay]

Also, we'll need to make sure we have this bootstrapping working if Navigation is NOT enabled in the template. So to default back to the "vanilla" bootstrapping.

[nickrandolph]

Two things from this:

• We need to make sure that the IHost is captured somehow - if you're not using Navigation, you'll want to be able to access IHost so that you can use the DI container
• We need to make sure the window is captured somehow, so that you can manually navigate on it. Although I suppose if they're not using navigation then this becomes their responsibility to new up

[francoistanguay]

Dan said the AppBuilder will create the Window in this new contract.

Agree for the host, should be part of the "Vanilla" ShowAsync implementation that doesnt use Nav I'd imagine.

[nickrandolph]

Latest iteration:

public interface IApplicationBuilder
{
    Application App { get; }
    object? Arguments { get; }
    Window Window { get; }
    IApplicationBuilder Configure(Func<IHostBuilder, IHostBuilder> configureHost);
    IHost? Host { get; }
    IHost Build();
}

Note that Configure takes a Func<IHostBuilder,IHostBuilder> which is more consistent with the hostbuilder pattern - the extensions methods typically accept a IHostBuilder and return a HostBuilder so they can be chained. The IApplicationBuilder also captures the IHost after the Build method has been called.

ShowAsync method has no callback but has implicit knowledge of splashscreen -> would mean that it's part of Navigation.Toolkit. An improvement for this would be to offer an internal extension point so that when UseNavigationToolkit is called, we register interest in ShowAsync and do the appropriate initialization on the navigation root.

public static class IApplicationBuilderExtensions
{
    // Note: This extension belongs in Uno.Extensions.Navigation.UI/WinUI
    public static async Task<IHost> ShowAsync<TShell>(this IApplicationBuilder builder)
    where TShell : UIElement, new()
    {
        var appRoot = new TShell();
        var navRoot = appRoot as ContentControl;
        if (appRoot is IContentControlProvider contentProvider)
        {
            navRoot = contentProvider.ContentControl;
        }

        if (navRoot is ExtendedSplashScreen splashScreen &&
            builder.Arguments is LaunchActivatedEventArgs launchArgs)
        {
            splashScreen.Initialize(builder.Window, launchArgs);
        }

        builder.Window.Content = appRoot;
        builder.Window.Activate();

        // TODO: This needs tidying up inside Navigation library so that there's a single
        // InitializeNavigationAsync method that can make the determination on whether
        // to use the logic from Navigation.Toolkit or not
        if (navRoot is LoadingView loading)
        {
            // InitializeNavigationAsync from Navigation.Toolkit to deal with LoadingView
            return await builder.Window.InitializeNavigationAsync(
                async () =>
                {
                    return builder.Build();
                },
                navigationRoot: loading
            );
        }
        else
        {
            // InitializeNavigationAsync from Navigation that simply attaches navigation
            return await builder.Window.InitializeNavigationAsync(
                async () =>
                {
                    return builder.Build();
                },
                navigationRoot: navRoot
            );
        }
    }
}

The resulting app startup is now simpler:

protected async override void OnLaunched(LaunchActivatedEventArgs args)
{
    await this.CreateBuilder(args)
        .YourCustomExtension()  // These are extensions on IApplicationBuilder
        .Configure(builder => 
            builder
                .UseXYZ()   // These are extensions on IHostBuilder
                .UseABX()
        )
        .ShowAsync<Shell>();
}

This simplification uses the IContentControlProvider interface

public interface IContentControlProvider
{
    ContentControl ContentControl { get; }
}

which is implemented by Shell

public sealed partial class Shell : UserControl, IContentControlProvider
{
    public ContentControl ContentControl => Splash;

    public Shell()
	{
		this.InitializeComponent();
	}
}

[nickrandolph]

UnoExtApp3.zip
Updated sample

[francoistanguay]

Why is AppBuilder.Argyments object? Cant it just be the string inside the LaunchEventArgs?

Why is IHost needed to be captured? I think it's error prone as it can be null until you call BUild() so it's a bad idea.

Otherwise am ok with moving ShowAsync to Nav.Toolkit, We still need a vanilla version without Navigation to create the Window and a simple shell maybe. So names cant conflict.

[dansiegel]

I agree I think the move to object? is kind of weird... actually I would say it probably makes more sense to just make the arguments LaunchActivatedEventArgs since the Navigation needs that anyway, it's easy enough to unbox and get the string.

I get the argument about functions returning the IHostBuilder for typical extensions but I don't believe we have that requirement here. For a normal lambda function it probably wouldn't make a difference but if someone boxes themselves in with curly braces they'd find they need to do a return and it really doesn't matter for us with the ApplicationBuilder. I think that should be left as an Action<IHostBuilder> since we're just invoking whatever delegates someone registers and they aren't chaining themselves together. Besides in the delegate you can chain however many IHostBuilder extensions you want/need in a single Configure call...

[francoistanguay]

So ideally we wouldnt have a strong dependency ou LaunchActivatedEventArgs if all it contains is a string.

Nick's point about FUnc<IHB, IHB> is that in theory some ext3ensions could replace/decorate the IHB instance for whatever reason, but I cant think of one.

And going to my previous point, if we need to "capture" IHost, ideally we'd have a way to reinject it in DI once the host is created,vor wrap it into an IApplication or something.

[dansiegel]

Yeah I don't see a reason to capture the IHost in the IApplicationBuilder. This seems like a bad idea. You should either capture it when you call Build or from a Navigation extension that calls Build

[francoistanguay]

Would it scale better if we introduced IApplication right away, containing IHost, maybe the Window as well coming from IAppBuilder and whatever else we might need in the future?

Am not a fan of creating abstractions for nothing but maybe it would scale better if we returned something generic already instead of Task...

IApplication
IHost Host { get; }
Window MainWindow { get; }

[dansiegel]

IApplicationBuilder should contain the Application & Window because you may need them for initialization while you're building things. The host should only be returned by the Build or an extension method for Navigation which internally calls build. This better matches the pattern established by the dotnet team.