[android] fix DI registration for Frame, ListView, TableView

[jonathanpeppers]

This partially reverts b0bba51.

When running:

.\bin\dotnet\dotnet.exe build src\Controls\samples\Controls.Sample\Maui.Controls.Sample.csproj -f net7.0-android -t:Run

The app crashes on the "Compatibility" screen with:

System.InvalidOperationException: No service for type 'Android.Content.Context' has been registered.

These are caused by the change:

--handlersCollection.AddHandler(typeof(Frame), typeof(Handlers.Compatibility.FrameRenderer));
++handlersCollection.AddHandler<Frame>(svc => new Handlers.Compatibility.FrameRenderer(svc.GetRequiredService<Android.Content.Context>()));

It turns out this code path only works because:

1. Microsoft.Extensions.DI throws a MissingMethodException

2. MAUI has fallback logic to catch this and call:

return (IElementHandler)Extensions.DependencyInjection.
    ActivatorUtilities.CreateInstance(mauiContext.Services, handlerType, mauiContext.Context);

ActivatorUtilities is part of Microsoft.Extensions.DI.

For now, let's just revert this change for Android for these three types: Frame, ListView, and TableView.

I spend some time trying to "unwind" this and avoid the MissingMethodException on startup. I couldn't solve it yet, but plan to come back to it later.

[PureWeen]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[mattleibow]

I wonder if you are able to get the maui context, and then get the android contextfrom that. The maui context should be registered in the services?

[mattleibow]

But I am not sure which maui context it will be - it may be the root app one, or the latest/nearest...

[jonathanpeppers]

svc.GetService<IMauContext>() returns null at this point for some reason?

[PureWeen]

yea, the service passed in here is just the MauiHandlerFactory that implements IServiceProvider. It doesn't really have any exciting information or access to the relevant WrappedServiceProvider

Currently all these controls are completely broken so just doing this for now to get unbroken.

This is partially why I was hoping we'd shift to a dependency resolution route. If the ToHandler code used ActivatorUtilities then we could look at dependency resolution to make this work.

I think it's still worth seeing if we can modify this factory approach to provide the WrappedServiceProvider inside this code block before we print NET8.