I’m a big fan of the separation that the Mvvm pattern gives developers in that the user interface is encapsulated in the view (Page, UserControl etc) and that the business logic resides in the ViewModel/Model. When structuring the solution for an application I will go so far as to separate out my ViewModels into a separate project from the views, even with Xamarin.Forms where the views can be defined in a .NET Standard library.
One of the abstractions that this lends itself to is what is referred to as ViewModel to ViewModel navigation – rather than the ViewModel explicitly navigation to a page, or bubbling an event up to the corresponding view to get the view to navigate to the next page, ViewModel to ViewModel navigation allows the ViewModel to call a method such as Navigation(newViewModel) where the newViewModel parameter is either the type of the ViewModel to navigate to, or in some frameworks it may be an actual instance of the new ViewModel.
MvvmCross
Let’s see this in action with MvvmCross first – I’m going to start here because ViewModel to ViewModel navigation is the default navigation pattern in MvvmCross. I’ll start with a new project, created using the MvxScaffolding I covered in my previous post, using MvvmCross in a Xamarin.Forms application. The single view template already comes with a page, HomePage, with corresponding ViewModel, HomeViewModel. To demonstrate navigation I’m going to add a second page and a second ViewModel. Firstly, I’ll add a new class, SecondViewModel, which will inherit from BaseViewModel (a class generated by MvxScaffolding which inherits from MvxViewModel that’s part of MvvmCross).
public class SecondViewModel : BaseViewModel
{
}
Next, I’ll add a new ContentPage called SecondPage (note the convention here that there is a pairing between the page and the ViewModel ie [PageName]Page maps to [PageName]ViewModel)
MvvmCross supports automatic registration of pages and ViewModels but it does require that the page inherits from the Mvx base class, MvxContentPage. I just need to adjust the root XAML element from
<ContentPage …
to
<views:MvxContentPage x_TypeArguments=”viewModels:SecondViewModel” …
The inclusion of the TypeArguments means that the generic overload of MvxContentPage is used, providing a helpful ViewModel property by which to access the strongly typed ViewModel that is databound to the page.
Now that we have the second page, we just need to be able to navigate from the HomePage. I’ll add a Button to the HomePage so that the user can drive the navigation:
<Button Text=”Next” Clicked=”NextClicked” />
With method NextClicked as the event handler (here I’m just using a regular event handler but in most cases this would be data bound to a command within the HomeViewModel):
private async void NextClicked(object sender, EventArgs e)
{
await ViewModel.NextStep();
}
And of course we need to add the NextStep method to the HomeViewModel that will do the navigation. The HomeViewModel also needs access to the IMvxNavigationService in order to invoke the Navigate method – this is done by adding the dependency to the HomeViewModel constructor.
public class HomeViewModel : BaseViewModel
{
private readonly IMvxNavigationService navigationService;
public HomeViewModel(IMvxNavigationService navService)
{
navigationService = navService;
}
public async Task NextStep()
{
await navigationService.Navigate<SecondViewModel>();
}
}
As you can see from this example the HomeViewModel only needs to know about the SecondViewModel, rather than the explicit SecondPage view. This makes it much easier to test the ViewModel as you can provide a mock IMvxNavigationService and verify that the Navigate method is invoked.
Prism
Now let’s switch over to Prism and I’ve used the Prism Template Pack to create a new project. To add a second page I’ll add a SecondPageViewModel, which in the case of Prism inherits from ViewModelBase and requires the appropriate constructor that provides access to the INavigationService. Note that the naming convention with Prism is slightly different from MvvmCross where the ViewModel name is [PageName]PageViewModel (ie both the page and the viewmodel have the Page suffix after the PageName eg SecondPage and SecondPageViewModel)
public class SecondPageViewModel : ViewModelBase
{
public SecondPageViewModel(INavigationService navigationService) : base(navigationService)
{
}
}
I’ll add a new ContentPage called SecondPage but unlike MvvmCross I don’t need to alter the inheritance of this page. Instead what I do need to do is register the page so that it can be navigated to. This is done in the App.xaml.cs where there is already a RegisterTypes method – note the additional line to register SecondPage.
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.RegisterForNavigation<NavigationPage>();
containerRegistry.RegisterForNavigation<MainPage, MainPageViewModel>();
containerRegistry.RegisterForNavigation<SecondPage, SecondPageViewModel>();
}
Similar to the MvvmCross example, I’ll add a button to the MainPage (the first page of the Prism application created by the template) with code behind to call the NextStep method on the MainViewModel
private async void NextClicked(object sender, EventArgs e)
{
await (BindingContext as MainPageViewModel).NextStep();
}
Note that because the MainPage just inherits from the Xamarin.Forms ContentPage there’s no property to expose the data bound viewmodel. Hence the casting of the BindingContext, which you’d of course do null checking and error handling around in a real world application.
public async Task NextStep()
{
await NavigationService.NavigateAsync(“SecondPage”);
}
The NextStep method invokes the NavigateAsync method using a string literal for the SecondPage – I’m really not a big fan of this since it a) uses a string literal and b) requires the the ViewModel knows about the view that’s being navigated to. So let’s adjust this slightly by changing the way that pages and ViewModels are registered. The RegisterForNavigation method accepts a parameter that allows you to override the navigation path, meaning we can set it to be the name of the ViewModel instead of the name of the page.
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.RegisterForNavigation<NavigationPage>();
containerRegistry.RegisterForNavigation<MainPage, MainPageViewModel>(nameof(MainPageViewModel));
containerRegistry.RegisterForNavigation<SecondPage, SecondPageViewModel>(nameof(SecondPageViewModel));
}
The navigation methods would then look like:
public async Task NextStep()
{
await NavigationService.NavigateAsync(nameof(SecondPageViewModel));
}
But I think we an improve this further still by defining a couple of extension methods
public static class PrismHelpers
{
public static void RegisterForViewModelNavigation<TView, TViewModel>(this IContainerRegistry containerRegistry)
where TView : Page
where TViewModel : class
{
containerRegistry.RegisterForNavigation<TView, TViewModel>(typeof(TViewModel).Name);
}
public static async Task<INavigationResult> NavigateAsync<TViewModel>(this INavigationService navigationService)
where TViewModel : class
{
return await navigationService.NavigateAsync(typeof(TViewModel).Name);
}
}
Using these extension methods we can update the registration code:
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.RegisterForNavigation<NavigationPage>();
containerRegistry.RegisterForViewModelNavigation<MainPage, MainPageViewModel>();
containerRegistry.RegisterForViewModelNavigation<SecondPage, SecondPageViewModel>();
}
And then the navigation code:
public async Task NextStep()
{
await NavigationService.NavigateAsync<SecondPageViewModel>();
}
The upshot of these changes is that there’s almost no difference between the MvvmCross method of navigation and what can be done with a little tweaking with Prism.
Hello thank you for your sharing. I would like to ask why we need to this implementation for prism forms? I am living performance problem when navigating. I think this issue occours from xaml first compile. Can I achive that with this? Thank you in advance
Kerberos, this isn’t required for Prism but it does provide an alternative to the url based navigation that comes out of the box.
When you say performance issues, can you elaborate a bit please (connect on Twitter if you want to chat https://twitter.com/thenickrandolph)