Over the last month-and-a-half, I have been busting my butt trying to get Prism for Xamarin.Forms ready for prime time. Since the first preview release back on Dec 3rd, I have release two more previews. Today’s newest release is Prism for Xamarin.Forms 6.2.0 Preview 3. This preview has a lot of improvements and some major changes which won’t break you know, but they will when it RTM’s.
With this preview we have support for the following containers:
- Unity – https://www.nuget.org/packages/Prism.Unity/6.2.0-pre3
- Ninject – https://www.nuget.org/packages/Prism.Ninject/6.2.0-pre3
A New Bootstrapping Process – Yet Again!
So, after a ton of iterations, limited accessibility of native Xamarin.Forms features, and feedback from the community, it became obvious that the bootstrapping process as it existed just wouldn’t work anymore. In this latest preview, we had to move to a base application class. So this means that the Bootstrapper is out, and the PrismApplication is in. All the concepts are the same, but now instead of creating a Bootstrapper, you simply change your App.cs base class to derive from PrismApplication.
Now, if you modified your application to have an App.xaml and App.xaml.cs, then your App.xaml.cs will require you to move your call to InitializeComponent() from the App constructor to the OnInitialized() method before you navigate to your main view. So your new App.xaml.cs would look like this:
This will ensure that all your application resources are available when you navigate to the main view in your application.
For now, both the Prism.Unity.Forms, and the Prism.Ninject.Forms have a class named PrismApplication. I am considering changing the name f this class to be specific to each container. For example, I am considering changing the names to PrismUnityApplication, and PrismNinjectApplication respectively.
What do you think about that?
Deep Linking Change
There was a small change to the behavior of deep linking. Prior to Preview 3, if you were to provide a navigation URI with two or more segments (target pages) like this:
Then the navigation service would automatically disable animating the page transitions. This would essentially render the INavigationService.Navigate “animated” parameter useless, and if you tried to use it, the value you provided would have no impact on the behavior. This is obviously not a good API design. Start with Preview 3, if you are deep linking and do not want to animate the transition between the pages, you must manually specify the “animated” parameter.
_navigationService.Navigate(“MyMasterDetail/MyNavigationPage/ViewA/MyTabbedPage/ViewB”, animated: false);
As with every release, there have been a number of improvements made to the navigation service logic. The most noticeable improvement is with the INavigationService.GoBack() method. The GoBack method is now smarter about the page you are on, and the page you are going back to regardless of the navigation stack the current page belongs to.
When navigating from a mAsterDetailPage, we now close the drawer automatically, which is a nice little feature that you don’t have to worry about anymore.
There is a new interface called IConfirmNavigationAsync which allows you to provide an async implementation of the existing IConfirmNavigation functionality.
The INavigationService methods now returns a Task for async/await scenarios for when you must await a navigation action before continuing your logic execution.
Providing an absolute URI for navigation will now replace the applications entire navigation stack. Think of it as a reset, or clear all and start over type of navigation.
That about sums it up for this latest Prism for Xamarin.Forms Preview 3 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.