It has been 7 months since the last release of Prism 6.2, and I have been hard at work trying to make it better.  I have fixed a number of bugs, added a number of new features, and unfortunately introduced a number of breaking changes.  Hopefully, you have been testing out the Previews on NuGet I have been releasing over the last 7 months to give feedback and prepare for all of the changes.  Those of you that did will find the upgrade process very easy.  Others… well not so much.  Keep in mind that nearly all of these features and changes were driven by you, the community.  To date, Prism has had 355 closed Pull Requests, and 622 closed Issues.  I think that makes for a very powerful community effort.  Let’s go ahead and see what’s new, and what’s broken, in the latest 6.3 release.


Let’s start first with the core Prism functionality that all platform use.


In previous versions of Prism, there was only a PubSubEvent<T> where T would be the payload type of your parameter.  The problem is that not every event you send needs to have a parameter passed with it.  Sometimes you just want a simple notification.  No need to pass a parameter, so why require one?  Well, now you can define a PubSubEvent without having to define a payload.

public class MyEvent : PubSubEvent { }

Removed DelegateCommand.FromAsyncHandler – Breaking

Back in October, I announced that I was going to drop support for the DelegateCommand.FromAsyncHandler method.  You may be asking why.  To make a long story short, it never worked properly, and broke normal usages of DelegateCommand.  So I had to remove it to fix it.  So how do you fix your code?  Easy!

DelegateCommand myCommand = new DelegateCommand(async () => await MyHandler());

private Task MyHandler()
    //your code here

or even:

DelegateCommand myCommand = new DelegateCommand(MyHandler);

private async void MyHandler()
    //your code here

Now you may be saying, “but Brian… you’re not supposed to have async void“.  Well if you read the docs and Stephen Cleary’s Async/Await article, it specifically states that ICommand should be considered an event handler and async void is allowed.

DelegateCommand Internal API Changes – Breaking

You will only care about this if you have a custom command that is deriving from DelegateCommand.  This is actually related to the removal of the DelegateCommand.FromAsyncHandler change.  DelegateCommand has been broken for a long time, and in order to fix it we has to make some changes to the internal workings of the DelegateCommand class.  For example, Execute is no longer a task, but a proper void method.  If you have a custom command that derive from DelegateCommand, you should be overriding the Execute(object parameter) and CanExecute(object parameter) methods.

DelegateCommand.ObservesCanExecuteChanged Signature Change – Breaking

Another break we have with DelegateCommand is that the signature of the ObservesCanExecuteChanged method has been changed.  This was based on a ton of feedback about the discrepancy between the ObservesProperty method.  Now you no longer have to provide a parameter for your expression.


DelegateCommand command = new DelegateCommand(Execute).ObservesCanExecute((vm) => CanExecute);


DelegateCommand command = new DelegateCommand(Execute).ObservesCanExecute(() => CanExecute);

Prism for Xamarin.Forms

Prism for XF is slowly maturing and becoming more and more stable.  With every release, we learn something new based on all the feedback from the community.  While we do have some breaking changes for XF, they aren’t really that bad and were done to move to framework forward.  Prism for Xamarin.Forms got a ton of love in this 6.3 release.  So much, that I am not going to list everything, but just the highlights.  For a list of all changes, go check out the release notes.

EventToCommand Behavior

The EventToCommandBehavior class provide a convenient way to, in XAML, “bind” events to ICommand according to MVVM paradigm to avoid code behind.  This is used in just about every XAML application you will write.  It is so common, the we decided to add one to Prism.

Of course the prism EventToCommand isn’t your standard EventToCommand.  We make it easier to pass the parameters you need using a number of approaches.  Use property paths, use converters, or use the standard CommandParameter property.

Hardware/Software Back Button Support

This was a major limitation in the Prism navigation service.  Previously, when you would use the hardware back buttons, or the software back button to navigate back to a previous View, the INavitaionAware methods would never fire.  This has now been fixed!  The only limitation is when using the hardware/software back buttons, the new OnNavigatingTo method will not be invoked.  Only the OnNavigatedFrom and OnNavigatedTo methods will be invoked.  This is because when using the hardware/software back buttons, I have no way of invoking the OnNavigatingTo prior to the popping action occurring.

TabbedPage IActiveAware

Another need feature is that TabbedPages can now be IActiveAware.  This means that when the ViewModels of your tabs implement IActiveAware, Prism will keep track of which tab is the active tab.  This is very powerful when combined with CompositeCommands.


Another pain point in Xamarin.Forms development is memory leaks.  Xamarin.Forms is notorious for not cleaning itself up.  So, now you can use the IDestructible interface for both Views and ViewModels to clean up any resources you may have.  Remove event handlers, unregister from CompositeCommands, close any streams that may be open.  Whatever you need.  I know what you are going to ask, “but Brian, why didn’t you use IDisposable?”.  Well, I tried, but then quickly realized that Prism shouldn’t be the one calling IDisposable.  Doing so caused a number of issues and exceptions.  So, I had to introduce this new interface.

Support Arrays in NavigationParameters – Breaking

NavigationParameters is no longer a simple Dictionary.  It is now an IEnumerable.  This change was made for a number of reason, but the primary reason was because the Prism URI navigation scheme was not 100% compliant with the web.  When using a URI on the web, it is very common to pass parameters as an array. For example;  In this example we are passing a collection of cars to the view as a parameter.

In order to support this behavior, we need to change the base class of the NavigationParameters class from a Dictionary to be an IEnumerable.  We added the most common Dictionary methods like TryGetValue in order to minimize the number of breaks in your app.

This also sets us up to do more dynamic things in Prism such as dynamically generate tabs for a TabbedPage. Imagine NavigateAsync(“MyTabbedPage?createTab=TabA&createTab=TabB”).  Now that will be cool.

INavigationAware API Changes – Breaking

Based on very popular demand, there is a new OnNavigatingTo method being added to the INavigationAware interface.  This method was added to fix the issue of trying to initialize ViewModels with data being passed in as parameters.  Currently, if you pass parameters to the target ViewModel and set properties, there is a visible delay when the View updates to reflect those values.  This is because the View has already been pushed onto the navigation stack, and then the bindings are updated after the properties have been set.  Now, you can use the new OnNavigatingTo, which is called before the target View is pushed onto the navigation stack, in order to initialize your data.  Now, you will no longer have that delay in displaying your data.

IConfirmNavigation/IConfirmNavigationAsync Changes – Breaking

This is probably not that big of a deal, but the IConfirmNavigation and IConfirmNavigationAsync interfaces no longer depend on the INavigationAware interface.  I had a ton of feedback that when using IConfirmNavigation, you may not always be dealing with handling the INavigationAware methods.  So this dependency has been removed.  Chances are, you won’t even notice it.


Add this interface to your Views or ViewModels so you can respond to when your app is going to sleep or resuming.


The IApplicationStore gives you access to the Application.Properties property and the ability to save properties from your Views or ViewModels.


The last feature that was added was a new IDeviceService interface which gives you access to the Xamarin.Froms Device properties and methods.  You can now perform Device functions without having to reference a static class in your ViewModels.  You are just a little more testable now.

Prism for WPF and UWP

Prism for WPF and UWP didn’t get a ton of changes.  They mainly got just a few bug fixes.  One thing that I want to point out is that WPF now has a brand new set of samples to help you learn Prism for WPF.  They are listed in numeric order so you can work your way through them and slowly build your knowledge one concept at a time.  You can check them out here:


Well, that about wraps it up for the important stuff.  Make sure to check out the release notes for a list of all the changes.  I will be working on updating the documentation, which as you know is always the last thing that a developer does.  I will also work on getting some new samples in the repo that covers all the cool features Prism for Xamarin.Forms provides.  I have also started work on a brand new Prism for Xamarin.Forms Pluralsight course.  It’s coming along slow, but it’s coming.  So keep an eye out on my course list which can be seen on my author page for this new course.

Please, get involved with the project on GitHub.  Be sure to provide your feedback, submit issues, submit features, and submit PR’s.  This is your project, so make it what you want it to be.  As always, feel free contact me on my blog, connect with me on Twitter (@brianlagunas), or leave a comment below for any questions or comments you may have.

Brian Lagunas

View all posts

1 comment

  • Thanks for the WPF samples, I’ll be going through those soon. Looking forward to the Pluralsight course for Xamarin.Forms as well. Keep up the good work!

Follow Me

Follow me on Twitter, subscribe to my YouTube channel, and watch me stream live on Twitch.