Back in March I released the first preview of Prism for Xamarin.Forms. Since then, there has been a ton of great feedback from the Xamarin community. Today, I am happy to announce the next evolution of Prism for Xamarin.Forms available now on NuGet as a preview (6.1.0-pre1). Of course, you don’t use Prism for Xamarin.Forms alone, you must have a dependency container to use with it. With this preview we have support for the following containers:
- Unity – https://www.nuget.org/packages/Prism.Unity/6.2.0-pre1
- Ninject – https://www.nuget.org/packages/Prism.Ninject/6.2.0-pre1
Now, you may be asking yourself what’s new in this latest preview. Well, the navigation has been completely overhauled and the bootstrapping process has slightly changed to support more complex startup scenarios like deep linking (I’ll get to that later).
A New Bootstrapping Process
The first release of the bootstrapping process has some limitations with application startup and integrating with the INavigationAware OnNavigatedTo and OnNavigatedFrom methods. This was because the original bootstrapper didn’t rely on the INavigationService to set the application’s MainPage. It was also very limiting on how you set the MainPage to other page type such as a MasterDetail, TabbedPage, or NavigationPage. For example; how would you set the MainPage to a MasterDetail, and then immediately navigate to a different view as the Detail at startup?
I am happy to say that this has been fixed. The original CreateMainPage and InitializeShell methods have been marked as obsolete. Instead, you now override the OnInitialized method and navigate to the MainPage as you would any other page in your application using the new NavigationService property located in the bootstrapper. This is what your bootstrapper will look like now:
As you can see, you simply register your page for navigation like you normally would, but now you simply specify which page to navigate to in the OnInitialized method. This gives you a lot more flexibility on how you navigate when you first launch the app, as well as gives you the ability to pass parameters to your views during startup.
An Improved Navigation Service
Probably the biggest improvement in the 6.2.0 preview is the complete rewrite of the INavigationService. The INavigationService now has support for URI based navigation, deep linking while maintaining the navigation stack, and passing parameters via the GoBack method call. Let’s talk about each of these.
URI Based Navigation
The first improvement we made was the ability to support both relative and absolute URI’s for navigation. This means that you can use an HTTP, or custom, protocol to dynamically create navigation links. For example:
This is probably the best feature yet! We worked very hard to make the INavigationService as smart as it can possibly be. The INavigationService now automatically handles navigation automatically no matter where you call Navigate from. The INavigationService will detect the type of page you are navigating from and automatically handle the navigation for you. So if you are navigating from a MasterDetail, it will know that and set the MasterDetail.Detail property to your target view instead of navigating modally. Are you navigating from a NavigationPage? Don’t worry about setting that silly UseModalNavigation parameter again! The INavigationService will know where you are navigating from and handle the PushAsync call for you. This goes for TabbedPages, CarouselPages, MasterDetailPages, NavigationPages, and regular ContentPages.
So how does this all work? Deep linking! Let’s say that you want to navigate to a MasterDetailPage, then set the Detail to a NavigationPage, and then PushAsync to a COntentPage, and then PsuhAsync to a TabbedPage while selecting the second tab on that page. How on earth would you do that with Prism, and from within your ViewModel? Easy!
First, you have to make sure you register all your pages with the navigation service.
Then you simply build up your navigation stack like so:
Pretty slick right! The result of this navigation will show the TabbedPage with the second tab selected (ViewB). Your back stack will be just as you expect it to be as you use the hardware button, software button, or call GoBack on the INavigationService to navigate backwards. This gives you the ultimate control in navigation and takes all the work out of managing your more complex navigation scenarios all from within your nicely testable ViewModel.
Now image this when you start your application. You can now launch your Xamarin.Forms applications from a website and deep link to content within your app al while maintaining a proper back stack.
But Brian, what about parameters? I’m glad you asked. The parameter function in the newest preview of Prism for Xamarin.Forms is unlike anything you have ever seen out of any framework. Sure we support the simple scenarios of passing parameters via the INavigationService parameter option like this:
Since we support URI based navigation, we also support URI based parameters too. So now you can do this:
Pretty slick right? Well what if you have some parameters that are URI based, and others that are generated by your code that need ot be passed in? No problem. Just use both:
This will take the URI based parameters and the NavigationParameters, and combine them into a single set of parameters that can be used by your target ViewModels. Alright Brian, that looks very cool. But, what about passing parameters during deep linking scenarios? Prepare to have your mind blown:
Now pick your brains up off the floor, and scrap them off the walls! You can easily pass page specific parameters during deep linking navigation simply by providing the URI based parameters with the target page.
So not everything is going to go smooth with your upgrade. I do have a couple of breaking changes to discuss. Due to feedback from the community, and the complete rewrite to the INavigationService, I had to remove the following objects:
The objects allowed you to wrap the target page into another page type, like a NavigationPage, during a navigation process. Since the INavigationService is now smart enough to handle most navigation scenarios, this isn’t really needed anymore. Though, I would like to know the community’s thoughts on this. Maybe you don’t need to replace the page anymore, but maybe you still want to do some page setup, or initialization before the navigation completes? I don’t know. So I need your feedback on this. Maybe we add something closer to an IPageFormatter that allows you to do this instead. You guys have to let me know what you need.
I hope you are as excited as I am about the latest Prism for Xamarin.Forms preview release. I wanted to get this preview out to the community as quickly as possible in order to get your feedback on the direction Prism for Xamarin.Forms is going. Let me know what you think about the API. Tell me what sucks, but better yet, tell me what is great. If you have an idea that you would like to see implemented, be sure to fork our repository and submit a pull request.