How to define a class with different implementations for desktop and browser?

[TheRealQuantam]

I have an Avalonia 11 app that builds for both desktop and WebAssembly browser, meaning a core assembly with the MVVM, a desktop assembly, and a web assembly. How can I write a class with different implementations for desktop and web that can be used by the core assembly? I might hypothesize that I'd write an interface in the core assembly then different implementations of it in the desktop and web assemblies, but how then do I instantiate the appropriate class from the core assembly, especially given how aggressive trimming is in WebAssembly builds?

I can't use #if to select for the target because the core assembly only has one target, yes? And I can't really switch between the two implementations at runtime (OperatingSystem.IsBrowser()) because they involve different dependencies.

[IanRawley]

You're halfway there. Put an interface in the core assembly, with concrete implementations in the platform assemblies. On app start the platform assemblies register the concrete implementation with a services register, which the core can then request as needed.

[IanRawley]

Depends on the platform. For instance on Android it's the CustomizeAppBuilder override in MainActivity, for Windows it would be within BuildAvaloniaApp() in the Program class. Browser looks like it would be the same as Windows here, but I haven't tried and so can't confirm.

[thevortexcloud]

None of that is the "recommended" way. I wrote how to do this a long time ago also an incorrect way (#13455 (reply in thread))

But the easiest way is to:

1. Make a static class to hold your service collection (like in the link above)
2. When Avalonia is set up, use AfterSetup like its done here How can I access `NSWorkspace` without `MonoMac.NetStandard` in AvaloniaUI? #13455 (reply in thread)

[TheRealQuantam]

Here's the autogenerated code for Program.cs for the desktop build:

class Program
{
    // Initialization code. Don't use any Avalonia, third-party APIs or any
    // SynchronizationContext-reliant code before AppMain is called: things aren't initialized
    // yet and stuff might break.
    [STAThread]
    public static void Main(string[] args) => BuildAvaloniaApp()
        .StartWithClassicDesktopLifetime(args);

    // Avalonia configuration, don't remove; also used by visual designer.
    public static AppBuilder BuildAvaloniaApp()
        => AppBuilder.Configure<App>()
            .UsePlatformDetect()
            .WithInterFont()
            .LogToTrace()
            .UseReactiveUI();
}

This is why I wasn't sure where to do it as the comment says to not use third-party APIs yet, which would presumably include the DI framework.

[thevortexcloud]

@ Vortex: Could you please elaborate on why DI may not work ? And what do you mean with "unbounded" for reflection.

Thanks!

Unbounded means it can't be known at compile time. Which means the trimmer has no way to know if the code is used or not. Which means it might delete the code you need and fail at runtime.

[thevortexcloud]

This is why I wasn't sure where to do it as the comment says to not use third-party APIs yet, which would presumably include the DI framework.

That comment is about doing things before Avalonia starts that rely on Avalonia or doing async things. Setting up a service container has really nothing to do with Avalonia (at least if you have followed MVVM/SRP properly). AfterSetup though is a good place to do it since it means Avalonia is at least sort of ready. For example this method in the official samples instantiates some things:

Avalonia/samples/ControlCatalog.Desktop/Program.cs

Lines 18 to 29 in 418e15d

	public static AppBuilder BuildAvaloniaApp()
	=> AppBuilder.Configure<App>()
	.LogToTrace()
	.AfterSetup(builder =>
	{
	builder.Instance!.AttachDevTools(new Avalonia.Diagnostics.DevToolsOptions()
	{
	StartupScreenIndex = 1,
	});
	EmbedSample.Implementation = new EmbedSampleWin();
	})

[maxkatz6]

On top of other suggestions, you can use OperatingSystem.IsBrowser()