Now image this when you start your application. 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. 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. Pretty slick right! The result of this navigation will show the TabbedPage with the second tab selected (ViewB). _navigationService.Navigate(“MyMasterDetail/MyNavigationPage/ViewA/MyTabbedPage/ViewB”) Then you simply build up your navigation stack like so: How on earth would you do that with Prism, and from within your ViewModel? Easy!įirst, you have to make sure you register all your pages with the navigation service. 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. This goes for TabbedPages, CarouselPages, MasterDetailPages, NavigationPages, and regular ContentPages. 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. 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. The INavigationService will detect the type of page you are navigating from and automatically handle the navigation for you. The INavigationService now automatically handles navigation automatically no matter where you call Navigate from. This is probably the best feature yet! We worked very hard to make the INavigationService as smart as it can possibly be. _navigationService.Navigate( new Uri ( "", UriKind. _navigationService.Navigate( new Uri ( "MainPage", UriKind. This means that you can use an HTTP, or custom, protocol to dynamically create navigation links. The first improvement we made was the ability to support both relative and absolute URI’s for navigation. The INavigationService now has support for URI based navigation, deep linking while maintaining the navigation stack, and passing parameters via the GoBack method call. Probably the biggest improvement in the 6.2.0 preview is the complete rewrite of the INavigationService. 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. NavigationService.Navigate( "MainPage" ) Īs 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. Public class Bootstrapper : UnityBootstrapper This is what your bootstrapper will look like now: 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. The original CreateMainPage and InitializeShell methods have been marked as obsolete. I am happy to say that this has been fixed. For example how would you set the MainPage to a MasterDetail, and then immediately navigate to a different view as the Detail at startup? It was also very limiting on how you set the MainPage to other page type such as a MasterDetail, TabbedPage, or NavigationPage. This was because the original bootstrapper didn’t rely on the INavigationService to set the application’s MainPage. The first release of the bootstrapping process has some limitations with application startup and integrating with the INavigationAware OnNavigatedTo and OnNavigatedFrom methods. 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). Now, you may be asking yourself what’s new in this latest preview. With this preview we have support for the following containers: Of course, you don’t use Prism for Xamarin.Forms alone, you must have a dependency container to use with it. 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). Since then, there has been a ton of great feedback from the Xamarin community. Back in March I released the first preview of Prism for Xamarin.Forms.
0 Comments
Leave a Reply. |