[Core][Hosting] Resolve handler services through registered service types

[mdh1418]

Description of Change

Reflection techniques used in MAUI's dynamic resolution of a virtual view's handler are neither AOT friendly nor trimming friendly. It involves iterating through the view's base types (GetServiceBaseTypes) and checking if any registered handler service types match (GetServiceDescriptor).

GetServiceBaseTypes(Type serviceType)

{
	var types = new List<Type> { serviceType };

	Type? baseType = serviceType.BaseType;

	while (baseType != null)
	{
		types.Add(baseType);
		baseType = baseType.BaseType;
	}

	foreach (var interfac in serviceType.GetInterfaces()) // Not AOT friendly, requires trimming annotations
	{
		if (typeof(IView).IsAssignableFrom(interfac))
			types.Add(interfac);
	}

	return types;
}

GetServiceDescriptor(Type serviceType)

{
	if (serviceType == null)
		throw new ArgumentNullException(nameof(serviceType));

	var types = GetServiceBaseTypes(serviceType);

	foreach (var type in types)
	{
		if (_collection.TryGetService(type, out var descriptor) && descriptor != null)
			return descriptor;
	}

	return null;
}

Instead of using reflection to resolve a virtual view's corresponding registered handler, this PR takes inspiration from #20058 and leverages a set of registered handler service types to find a virtual view's corresponding handler.

With the addition of ImageSource service type mappings and Handler service type set, MauiFactory's AOT unfriendly and trimming unsafe logic is no longer needed. This PR opts to simplify MauiFactory, which may be substituted out for the default ServiceProvider in another PR.

This PR does the following:

• Modifies MauiHandlersFactory service registration to emulate ImageSourceServiceProvider service registration
• Introduces a RegisteredHandlerServiceTypeSet to keep track of handler service types registered through AddHandler and to resolve a virtual view's corresponding handler service type
• Cleans up existing tests and adds new tests
• Simplifies MauiFactory and removes AOT unfriendly + trimming unsafe logic
• Removes MauiFactory build warnings from BuildWarningsUtilities test

Issues Fixed

Contributes to #19397
Fixes #1298 tested via HostBuilderResolvesToHandlerRegisteredUnderMostDerivedBaseInterfaceType

[simonrozsival]

Looks pretty good!

[simonrozsival]

Is this override necessary?

[mdh1418]

Yes, there is an exception propagation test

maui/src/Core/tests/UnitTests/HandlerTests.cs

Lines 24 to 77 in 8ba0551

	[Fact]
	public void ExceptionPropagatesFromHandler()
	{
	var mauiApp = MauiApp.CreateBuilder()
	.ConfigureMauiHandlers(handlers => handlers.AddHandler<IViewStub, ViewHandlerWithChildException>())
	.ConfigureMauiHandlers(handlers => handlers.AddHandler<ExceptionThrowingStub, ExceptionThrowingViewHandler>())
	.Build();
	var mauiContext = new MauiContext(mauiApp.Services);
	Assert.Throws<PlatformViewStubCreatePlatformViewException>(() =>
	new ViewStub().ToPlatform(mauiContext)
	);
	}
	class ViewHandlerWithChildException : ViewHandlerStub
	{
	public ViewHandlerWithChildException()
	{
	}
	protected override PlatformViewStub CreatePlatformView()
	{
	return new PlatformViewStub();
	}
	public override void SetVirtualView(IView view)
	{
	base.SetVirtualView(view);
	new ExceptionThrowingStub().ToPlatform(MauiContext);
	}
	}
	class ExceptionThrowingStub : ViewStub
	{
	}
	class ExceptionThrowingViewHandler : ViewHandlerStub
	{
	public ExceptionThrowingViewHandler()
	{
	}
	protected override PlatformViewStub CreatePlatformView()
	{
	throw new PlatformViewStubCreatePlatformViewException();
	}
	}
	class PlatformViewStubCreatePlatformViewException : Exception
	{
	}

that tests whether a view/element can throw an exception for another view/element.

I originally moved all HandlerTests to HostBuilderHandlerTests because I didn't see why we really needed the separation, both were in the same testing namespace anyways and both used HostBuilding (MauiApp.CreateBuilder().Build)

Then I figured that the test didn't fit in either, as it wasn't testing the HostBuilder's ability to register and retrieve services, rather it would be an ElementTest, so now its there as ElementToHandlerPropagatesThrownException.

The reason ElementToHandlerPropagatesThrownException needs that declared override void SetVirtualView from what I'm guessing because I don't fully understand the intent of the original test, was to give it some easy access method to throw an exception in the nested view/element after grabbing the view/element's handler in the ToHandler extensions method

maui/src/Core/src/Platform/ElementExtensions.cs

Lines 81 to 99 in 8ba0551

	handler = context.Handlers.GetHandler(viewType);
	}
	catch (MissingMethodException)
	{
	handler = viewType.CreateTypeWithInjection(context);
	if (handler != null)
	handlersWithConstructors.Add(view.GetType());
	}
	}
	if (handler == null)
	throw new HandlerNotFoundException(view);
	handler.SetMauiContext(context);
	view.Handler = handler;
	if (handler.VirtualView != view)
	handler.SetVirtualView(view);

. So once the view/element (ViewWithExceptionThrowingChildStub) grabbed the nested child view/element which throws the exception (ExceptionThrowingViewStub) we just check that the exception propagates through. Originally it was using CreatePlatformView to throw the exception but I figured if we just wanted to propagate an exception being thrown, using SetVirtualView would achieve the same results. But moving from UnitTests to DeviceTests meant that different stubs were available ViewStubHandler vs ElementStubHandler, but I couldn't override SetVirtualView without adding this to the ElementHandlerStub. Maybe I was missing something simple?

So the propagation pattern now looks like
ViewWithExceptionThrowingChildStub().ToHandler -> GetHandler -> ViewWithExceptionThrowingChildHandler.SetVirtualView -> ExceptionThrowingViewStub().ToHandler -> GetHandler + ExceptionThrowingViewHandler.SetVirtualView -> throw HandlerPropagatesException.
Compared to the original test that had
ViewStub().ToHandler -> GetHandler -> ViewHandlerWithChildException.SetVirtualView -> ExceptionThrowingStub().ToHandler->GetHandler->ExceptionThrowingViewHandler.SetVirtualView->ExceptionThrowingViewHandler.CreatePlatformView-> throwPlatformViewStubCreatePlatformViewException`

@PureWeen do you happen to know if I'm on the right track for the original intent of the test?

[rmarinho]

/rebase