Move Dialogs, Alerts, Action Sheets, etc. to a Service

[jfversluis]

I have been working on a .NET MAUI Blazor sample app and quickly ran into the issue where I needed to show a dialog of sorts. This posed a problem: I can't show a regular dialog through the web browser, but I also don't have access to the .NET MAUI Page to call DisplayAlert.

Luckily, the solution was pretty easy; write a little wrapper for the .NET MAUI layer to show a dialog through there. You can see the implementation underneath.

public class DialogService : IDialogService
{
    public async Task<string> DisplayActionSheet(string title, string cancel, string destruction, params string[] buttons)
    {
        return await Application.Current.MainPage.DisplayActionSheet(title, cancel, destruction, buttons);
    }

    public async Task<bool> DisplayConfirm(string title, string message, string accept, string cancel)
    {
        return await Application.Current.MainPage.DisplayAlert(title, message, accept, cancel);
    }
}

I foresee a lot of people that will start writing this exact same service over and over again, which seems like a waste of everyones time. Therefore, I think it would be great if we could refactor showing our dialogs, action sheets, etc. to a service that can be injected through dependency injection. That way we can easily use it in Blazor scenarios as well as regular .NET MAUI apps where we want to use MVVM or similar design patterns.

What are peoples thoughts, ideas, feelings?

[sander1095]

This is a great idea. This also touches upon the issue I had with unit testing in Xamarin and Maui. Everything is always used in a "Shell.Current" or "Application.Current" pattern, making it impossible to write tests that test that on a button press, some mocks have been called.

I have heard everyone always writes wrappers around these kind of classes so they can be injected, so I think this would be helpful.

But perhaps it is also a good idea to take a look if other things should then also become DI-able. How about the current shell instance?
What if I write a test that calls a repo and then navigates to a page? Writing UI tests is a solution here, but unit tests would be easier to write if the current shell instance was mockable so I could verify that navigation was called.

[filipoff2]

yup, In my app that was service.

Needed from unit tests perspective, screen resolution, on small screen co thing can be flyer, notifications, on Big popup or even page.

[rthanga1]

I faced the same problem. In many viewmodels, I use Shell.Current.GoToAsync which cannot be unit tested as Shell.Current will be null during unit tests

[AmrAlSayed0]

Yes, I also support this. I am using Prism in my XF app which provides interfaces and implementations of those services and when I got a request from my boss to change the appearance of all the dialogs in the app, I simply created another implementation that uses XCT's Popup and injected that service instead. Would be great if we could have those interfaces built into MAUI.

[marinasundstrom]

Great idea! There are a lot of stuff that really should be injectable services - Alert and ActionSheet are among these.

I know that some things have been left as is in MAUI due to compatibility and time constraints.

There was also probably some technical reasons for why DisplayAlert now is on the Page object, but can’t that be fixed?

As pointed out, this enhancement would be useful to Blazor Hybrid developers.

Update: DisplayAction sends a message via MessagingCenter. The action is performed by some handler.

I would suggest creating a DialogService and an ActionSheetService and deprecate the methods on Page.