[Enhancement] Support IInitialize with Dialog ViewModel

[Kevin-5831]

Summary

In addition of the IDialogAware, provide a Dialog ViewModel initialization, similar of IInitialize and IInitializeAsync of page navigation.

API Changes

Add the equivalent of IInitialize & IInitializeAsync interfaces for the Dialogs.

public interface IDialogInitialize
{
void[+] Initialize(IDialogParameters parameters);[/+][-] Initialize(IDialogParametersparameters);[/-]
}
public interface IDialogInitializeAsync
{
Task InitializeAsync(IDialogParameters parameters);
}

Intended Use Case

Support the synchronous and asynchronous initialization of a Dialog ViewModel.

[nightfairy5831]

Please explain what the benefit / scenario is that you hope to solve here? I'm assuming you are used to Forms/MAUI Page Navigation hence the request. Dialogs and Page Navigation work differently. There is in fact no actual need for an "Initialize" interface.

Dialogs are Navigated to once and then closed, while Pages can be Navigated to and then Navigated Back to...
The existing API already initializes the Dialog before it is presented.

[nightfairy5831]

Thanks for the feedback, @dansiegel. I understand the distinction between Dialogs and Page Navigation, but my suggestion is focused on supporting asynchronous initialization. The current IDialogAware only supports synchronous operations, which can be limiting for scenarios that require async tasks before displaying the Dialog.

Introducing IDialogInitializeAsync would address this need and create consistency with the IInitializeAsync interface used in Page Navigation.

Alternatively, reusing the IInitializeAsync interface for Dialogs could be considered, but it would introduce a breaking change, as the parameter type would need to change from INavigationParameters to IParameters.

[Kevin-5831]

There is a major drawback to an async interface when showing a dialog. If you make a call to a service or perform some other async operation, the Dialog will not show until that operation is completed, which can cause some very bad user experiences. Imagine clicking a button to show a dialog, but first a network call is made before the dialog is shown, there will be a noticeable delay from when the button was pushed to when the dialog was shown. Of course, the first instinct will be to blame Prism, when in actuality it's the async nature of the code.

We had this exact same problem when we provided support for the IInitializeAsync for navigation. Suddenly everyone's navigation started to lag and feeling "slow". Of course, Prism got the blame but turns out it was their code in the Async interface that was causing the issues because the navigation couldn't complete until their async code finished.

Why do you want to have the dialog wait on a task before opening? Why not show the dialog immediately and show a loading indicator when making any async calls you need. This way your UI stays very responsive.

[nightfairy5831]

Trying to have consistency with patterns that are not recommended, and can actually be a trap, isn't a good reason to add a new API.

What is your main concern with async void? Is there technical concern or does it just make you feel weird because you always hear the "don't use async void" mantra?