[Enhancement] Move MessagingCenter, DependencyService, etc to separate packages

[alanag13]

Summary

In my opinion, all features not related directly to creating the UI or responding to its events should be moved to separate packages. MessagingCenter and DependencyService come to mind but I'm sure there are other good candidates.

This would allow Xamarin.iOS and Xamarin. Android projects to use these without pulling in all of Forms/Maui.

[hartez]

Some parts of the UI do use the MessagingCenter (e.g., Alerts, Prompts, Action Sheets), so it's unlikely that we'd remove that.

DependencyService may be changing (there's a spec with a proposal here somewhere, but I don't feel like looking it up just now), but it also provides some UI functionality - at the moment, it handles the native binding services and the dispatcher providers (possibly more). So some version of it will likely remain.

[alanag13]

@hartez I think I may have been misunderstood, I'm suggesting that these be moved to separate packages so that non-forms (erm, non-Maui) apps can use these features without pulling in the entire Forms/Maui dependency, not for them to be eliminated from the codebase.

[SkyeHoefling]

If we are going to make an opinionated enhancement with the DependencyService to use the Microsoft.Extensions.DependencyInjection which will really make Dependency Injection a first-class feature, maybe it would be a good idea to create an IMessageService. We could keep the same API that is available in the current MessageService including a static API which will meet the needs of people that don't want to use Dependency Injection, but also have a registered service for IMessageService.

This provides a few benefits:

• Same consistent API that everyone is familiar with
• Ability to use it if your class isn't being resolved by the Dependency Injection Container
• All code would be dependent on the IMessageService, which provides a powerful extension point for 3rd party frameworks
• Not completely a breaking change - If we keep the static API the same but use a new IMessageService it won't technically be a breaking change for projects that are migrating from Xamarin.Forms

[pictos]

@ahoefling the MessagingCenter already has an Interface, as you can see here, maybe the case is just clean up and improve the implementation code with new patterns.

@alanag13, if we move those items to other packages and the Maui needs to use these packages at the end of the day our projects will have a dependency on those packages... So I think that it would be better to keep them in the MAUI project.

[SkyeHoefling]

@pictos I had no idea it had an interface, thanks for sharing the code location

[alanag13]

@pictos I know this doesn't remove a dependency from Maui/Forms.-- the idea is to allow other projects (namely xamarin.android and xamarin.ios projects) to use these features without depending on Maui/Forms.

[TheCodeTraveler]

@alanag13 -I recommend using CommunityToolkit.MVVM's messenger. It is optimized to have 0 allocations and is 100x more efficient than .NET MAUI's MessangingCenter

I go into more details in this Discussion:
#3797

Source

[hartez]

@alanag13 Here's the spec I mentioned: #24

If we go that direction (and use Microsoft.Extensions.DependencyInjection) then we'll end up where you're suggesting with regard to DependencyService - it'll be an external dependency that others can use. And it'll be a more full-featured and robust one than the current DependencyService, which to be honest is a little gnarly internally.

If we go the route of modifying DependencyService to implement IServiceCollection/IServiceProvider, then it might make sense to move it to a separate package, but I'd still be skeptical - see the aforementioned gnarliness.

[alanag13]

@hartez I'm all for improvements besides just moving them to separate packages and would definitely be in favor of the proposed spec.MessagingCenter also has gnarliness that could similarly be improved upon.

[hartez]

MessagingCenter is a similar case - the SDK needs it anyway, so we make it available for folks who might need a messaging solution. But it really only includes the features and API that the SDK needs to function. It's a nice "hey, I'm using this SDK and I need simple messaging, I can just use the one that's already here and save myself a dependency" bonus option. It's perfectly functional, but super basic.

If we moved it into a separate package, I'm not sure anyone would want to use it - there are so many other options with more features and nicer APIs. It's possible that we could look at other messaging solutions to add as a dependency for this SDK (instead of using MessagingCenter), but what we need internally is very, very basic; anything else might be overkill.