Some example is needed for using the new version with dependency injection

[RedChops]

The updated docs mention that this library (and associated) have been updated to support dependency injection. That's pretty great, but the problem is that once the native dotnet DI container is built it becomes immutable and can't be initialized asynchronously, at least in something like Maui.

This creates a problem for applications that have many viewmodels using repositories that request data from Postgrest with, say, explicit clauses for the current user's UID, on pages that would require access to the current user object, or on pages that would like to subscribe to Realtime.

I am probably missing something, but I can really only see two ways to solve this:

1. Use dependency injection only with Supabase.Client and have every consumer call InitializeAsync() on it before accessing the various components contained within through an async initialization pattern. This seems incredibly wasteful.
2. Completely forgo the built-in dotnet dependency injection service, either for a 3rd party service (I don't know the capabilities of them, maybe they're the same in which case this isn't an option) or initializing Supabase elsewhere early in the app and storing the instances in a static class.

Option 2 doesn't seem intended, considering there was just a multi-project push to support dependency injection and is basically how I used the Supabase libraries prior to this update, just using the libraries Instance property instead of creating my own. It carried a big benefit though: I initialized Supabase early enough in the applications lifecycle that I could ensure it would be ready to determine where the application should take the user on open (logged in or out views).

I'm sure I'm just missing something though, so some example of how this library is expected to be used and initialized now in a multiple-page, many-consumer application would be great.

[RedChops]

The async initialization pattern, to me, makes sense for services that are really only used in one or two places. The cost of possibly initializing them twice is not so great (usually). On the other hand, Supabase tends to be an application backbone, so it doesn't really make any sense to initialize it a ton of times.

[acupofjose]

@RedChops I have been using the Dependency injection model with Maui by specifying Supabase.Client as a Singleton within the builder, and leverage it using an AppStateService class like so:

MauiProgram.cs

static IServiceProvider? serviceProvider;
public static TService? GetService<TService>() => serviceProvider!.GetService<TService>();

public static MauiApp CreateMauiApp() {
// ...
builder.Services.AddSingleton(provider =>
    new Supabase.Client(
	 supabaseUrl,
	 supabaseKey,
	new SupabaseOptions
	{
	    AutoRefreshToken = true,
	    AutoConnectRealtime = true,
	    SessionHandler = new SupabaseSessionHandler()
	}
));

builder.Services.AddSingleton(provider => new AppStateService(provider.GetRequiredService<Supabase.Client>()));

// ...
}

Shared/AppStateService.cs

public class AppStateService : INotifyPropertyChanged
{
// ...
		public Supabase.Client Supabase;

		private AuthState authState = AuthState.SignedOut;
		public AuthState AuthState { get => authState; set => SetField(ref authState, value); }

		private Session? session;
		public Session? Session { get => session; set => SetField(ref session, value); }

		private User? user;
		public User? User { get => user; set => SetField(ref user, value); }
                
                private async void Auth_StateChanged(object? sender, ClientStateChanged e)
                {
			AuthState = e.State;
			Session = Supabase.Auth.CurrentSession;
			User = Supabase.Auth.CurrentUser;

			switch (e.State)
			{
				case AuthState.SignedIn:
					await Shell.Current.GoToAsync("//accounts");
					await Refresh();
					break;
				case AuthState.SignedOut:
					Reset();
					await Shell.Current.GoToAsync("//profile");
					break;
			}
             }
// ...
}

Using this setup, you can either reference AppStateService using DependencyInjection like this (after registering the model in the builder:

builder.Services.AddTransient<AuthViewModel>();

 public AppStateService AppState { get; private set; }

protected AuthViewModel(AppStateService appState)
{
    AppState = appState;
}

Or using the static lookup on MauiProgram

public AppStateService AppState { get; private set; }

protected BaseViewModel()
{
    AppState = MauiProgram.GetService<AppStateService>()!;
}

Supabase can be initialized once in App.cs in the OnStart method:

	public App(AppStateService appState, Supabase.Client supabase)
	{
		InitializeComponent();

		MainPage = new AppShell();
	}

	protected override async void OnStart()
	{
		base.OnStart();
		await Supabase.InitializeAsync();
	}

Does that help?

[RedChops]

I had tried something like this initially but found that the objects retrieved from the container weren't updating as expected. I went back through a little more carefully with your examples and sure enough this time it worked!

I found a bit of a gotcha though that I'll leave here because even the Maui docs don't really detail this all that well. If you need to hook native app lifecycle events, in this case to support the magic link callbacks from Supabase, you now definitely have to use ConfigureLifecycleEvents instead of overriding the callbacks within platforms AppDelegate, App.xaml.cs, etc. Previously when using Client.Instance I'd run InitializeAsync within the platform code when receiving a magic link callback then checking that initialization later in Maui's App.cs to make sure I didn't initialize twice. When using dependency injection I had to move some things around due to execution order, something like (mentioning the call order):

// App.xaml.cs (Maui)
    public App(AuthStateService authState, Supabase.Client client, IServiceProvider serviceProvider)
    {
        InitializeComponent();

        _client = client;
        ServiceProvider = serviceProvider;
        MainPage = new AppShell(authState);
    }

    // Executes third
    protected override async void OnStart()
    {
        base.OnStart();
        await _client.InitializeAsync();
    }

// App.xaml.cs (Windows)

public partial class App : MauiWinUIApplication
{
    /// <summary>
    /// Initializes the singleton application object.  This is the first line of authored code
    /// executed, and as such is the logical equivalent of main() or WinMain().
    /// </summary>
    public App()
    {
        this.InitializeComponent();
    }

    // Executes second
    protected override MauiApp CreateMauiApp() => MauiProgram.CreateMauiApp();

    // Executes first
    protected override async void OnLaunched(Microsoft.UI.Xaml.LaunchActivatedEventArgs launchActivatedEventArgs) {}
}

// MauiProgram.cs
#if WINDOWS
             // Executes fourth, or at the very least after Mauis App.xaml.cs is fully loaded
            events.AddWindows(windows => windows
                .OnLaunched(async (window, lArgs) =>
                {
                    var client = App.ServiceProvider.GetService<Supabase.Client>()!;
                    AppActivationArguments args = AppInstance.GetCurrent().GetActivatedEventArgs();
                    ExtendedActivationKind kind = args.Kind;

                    if (kind == ExtendedActivationKind.Protocol)
                    {
                        if (args.Data is IProtocolActivatedEventArgs protocolArgs)
                        {
                            Uri uri = protocolArgs.Uri;
                            await client.Auth.GetSessionFromUrl(uri);
                        }
                    }
                }));
#endif

So simply, the call order is loosely

1. Platform native callbacks
2. MauiProgram builder code
3. Maui App.xaml.cs initialization
4. Lifecycle events configured within the MauiProgram builder code

The important thing to note is that OnStart is run before any configured lifecycle events, so we can be sure that if the library is initialized there, it'll be available for anything else.

Thanks for the help!

[acupofjose]

Glad you got an answer! Thanks for the lifecycle deepdive - I haven't seen that anywhere else either. Very helpful!