INavigation and Dependency Injection

[Bowman74]

Currently the INavigation interface is as it was in Xamarin Forms, that is to say the navigation methods like PushAsync take an instance of the page they are trying to navigate to. While this is fine as far as it goes, pretty much every Mvvm framework that works with Xamarin Forms had to deal with trying to make this dependency injection friendly.

The current design of the method methods begs the question of how do those pages being navigated to get created. Does whatever calls to navigate also need to have all pages that it may navigate to proactively injected in? Do they need to use the IServiceProvider in their code as a service locator to create the pages for them before navigating?

What I believe would be ideal if methods like PushAsync took a page type as a parameter. The Navigation provider would then be responsible for creating the page from dependency injection. It would be a bonus feature if it was configurable, either globally or on a per page basis, if new pages created will be within a new scope.

[Jared-Aus]

This sounds like a good improvement to me and a step in the right direction, however I'm not sure how useful it would be without also taking other parameters. Full disclaimer: I'm still generally just as confused by the complexity of combining MVVM with navigation now as I was 10+ years ago. Seemingly simple things like navigating from one part of an app another (and passing a Model object) from within a Command delegate requires a tonne of plumbing if you don't wish to pollute the VM with references to Pages. Out-of-the-box navigation has always felt like something that only survives for trivial or demo apps, whereas custom navigation services that handle VM to VM navigation for example feel too heavy for moderately sized apps.

[Bowman74]

I've seen a lot of MVVM frameworks take the approach of view model to view model navigation. Then there is some sort of navigation service that is injected into the view model. The current view model says what view model needs to be navigated to and the navigation service figures out from the view model type what view should be associated. As you said, having view models know about pages rather breaks the MVVM pattern. Also as you say, that seems a bit heavy for smaller apps.

Generally the INavigation service used directly isn't useful for much other than form to form navigation and doesn't work well in the MVVM pattern. The fact that the INavigation service isn't aware of dependency injection makes it not even useful for that if we want to use DI in the app.

[Jared-Aus]

I agree. The direction with MAUI seems to be a further push towards Shell navigation, which as with everything to do with Shell, is heavily and deliberately opinionated in it's approach. In principle that wouldn't bother me if the compromises weren't too great, but I struggle to reconcile Shell navigation with my understanding of good practices regarding MVVM, DI, and unit testing. And I certainly don't consider myself a purist in any sense.

To mention just one concern with Shell based navigation, in the context of a details page, not once in nearly 15 years of working with XAML and view models did I ever think "hmm... wouldn't it be great if I could use query strings and attributes like I would in an ASP.Net server-side response for the most critical dependency of my view model." Particularly when running in the same process and I already have a reference to the model object that's a natural constructor based dependency for the next/detail view model. Maybe I'm fighting the last war, or simply fail to recognise the brilliance of the the common web-based approach...

P.S, that web based approach (as used in the Visual Studio new Xamarin Forms shell based project templates) results in most XAML bindings firing twice - as change notifications are triggered for every property that's updated as part of the late loading of what's effectively the primary dependency. To me that's just unnecessary work and more places for things to go wrong.

[Bowman74]

My take on the shell is that it also appears to be the direction MAUI is going. Unlike INavigation, it is dependency injection friendly. The thing that worries me is that the MAUI Shell, at least in its' current state, doesn't support a lot of complex navigation scenarios.

Though for the course I'm creating for MAUI stuff Forms developers need to know I'll be pushing them to the shell concept based on the direction things seen to be going.