Prism is a framework for building loosely coupled, maintainable, and testable XAML applications in WPF, Xamarin Forms, and Uno / Win UI Applications..
Major Changes included in this release:
.NET Standard Support
Added method to clear all errors on ErrorsContainer
Removed requirement for parameter in delegate definition of DelegateCommand.ObservesCanExecute Breaking
Example:
Old (v6.3): ObservesCanExcute((**vm**) => Property)
New (v7.0): ObservesCanExecute(() => Property)
Add capability to DelegateCommand's ObservesProperty to observe properties of complex types
Example:
ObservesProperty(() => Property.NestedProperty.NestedPoperty)
The Bootstrapper has been marked obsolete and it is recommended to use the PrimsApplication class going forward. This results in less code to get started, and an easier and more intuitive API.
Added new Prism.Ioc namespace to handle DI container abstractions. Interacting with the container is now done via the IContainerProvider and the IContainerRegistry interfaces. The IContainerProvider interface is used to resolve services from the container. The IContainerRegistry is used to register types with the container. Access to the actual DI container can be achieved by using the GetContainer() extension method off of the IContainerRegistry and IContainerProvider interfaces.
#650: Navigating between Tabs Breaking
#683: .NET Standard support
#765: Deep linking within a NavigationPage results in an incorrect ContentPage Title on Android
#921: Add ability to Remove pages from the navigation stack
#946: Support designating useModalNavigation for specific segments in Uri navigation
#1007: Re-license to MIT, following the Microsoft led projects
#1008: NavigationParameters: Not possible to specify parent type as generic parameter T
#1109: Retrieve current URI from Prism Xamarin.Forms NavigationService
#1111: Include pdb file in nuget package
#1024: XF: NavigationService swallowing Exceptions
#1025: Xamarin.Forms deprecated the Device.OS property in favor of the RuntimePlatform property. The following changes were made to accommodate these changes: IDeviceService
deprecated OnPlatform methods
added DeviceRuntimePlatform property - this mimics the XF API and returns a string
added RuntimePlatform property which returns an Enum of type RuntimePlatform and wraps the XF string-based values
#1027: Support macOS
#1044: When Detail of MasterDetailPage is null, Modal Navigation is possible
#1045: When calling NavigateAsync with NavigationPage, old page's Destroy on the stack is not called
#1046: When calling DeepLink from Navigation Stack, the second page becomes Modal navigation
#1054: When deep linking within NavigationPage, page order is reversed
#1063: Master of MasterDetailPage will not be destroyed
#1074: Optimize Xamarin Forms DryIoc adapter performance
#1085: Error occurs if null path is specified in EventToCommandBehavior
#1089: DebugLogger does not work in nuget-package
#1099: Introduce a Behavior factory into the navigation service
#1132: Prism Forms Modularity extension methods
#1133: IModuleCatalog AddModule returns wrong type
#1139: Modularity Enhancements
#1175: Upgraded to Unity 5 Breaking
#1076: IActiveAware not working when ContentPage (as child of a TabbedPage) is wrapped into a NavigationPage
#1166: Custom NavigationPage is not working properly Prism 7
#1187: Change TabbedPage navigation behavior Breaking
#1198: Rename IApplicationLifecycle to IApplicationLifecycleAware Breaking
#1200: Add GoBackToRoot method
#1232: PageNavigationService should check for MultiPage Parent
#1225: OnNavigatedTo Contains Extra Parameter
#1254: remove support for DependenyService autoresolution Breaking
#1286: Adding modules to Prism in newest PR version
added IPageLifecycleAware and PageLifecycleAwareBehavior to enable responding to the Page's Appearing and Disappearing events
Container Extensions
Container.RegisterTypeForNavigationOnPlatform<MainPage, MainPageViewModel>("Main",
new Platform<MainPage_Android>(RuntimePlatform.Android),
new Platform<MainPage_iOS>(RuntimePlatform.iOS));
Added new Prism.Ioc namespace to handle DI container abstractions. Interacting with the container is now done via the IContainerProvider and the IContainerRegistry interfaces. The IContainerProvider interface is used to resolve services from the container. The IContainerRegistry is used to register types with the container. Access to the actual DI container can be achieved by using the GetContainer() extension method off of the IContainerRegistry and IContaierProvider interfaces.
Notable changes:
ModuleCatalog propertyConfigureModuleCatalog() to ConfigureModuleCatalog(IModuleCatalog moduleCatalog)
RegisterTypes() to RegisterTypes(IContainerRegistry containterRegistry)
CreateContainer() methodCreateNavigationService() methodCreateLogger() methodCreateModuleManager() methodCreateModuleCatalog() methodContainer property is now of type IContainerProviderConfigureContainer to RegisterRequiredTypes(IContainerRegistry containterRegistry)
RegisterTypeForNavigation to RegisterForNavigation
Initialize() method - move all existing code into RegisterTypes and OnInitialized methodsRegisterTypes(IContainerRegistry containerRegistry) method - used to register types with the containerOnInitialized() method - used to perform any action after the module has been created, and types have been registered with the container.NavigateAsync("TabbedPage/ViewA/ViewB") will select the tab ViewA in the TabbedPage if it exists, then continue navigating. If ViewA does not exist as a tab, then you will continue to navigate as expected.
NavigateAsync("TabbedPage/NavigationPage/ViewA/ViewB") would search the TabbedPage for the first instance of a tab that was a NavigationPage, then navigate within the Navigation page the remaining ViewA and ViewB pages. This provided the ability to deep link into a tab's nested navigation page, but there was no way to opt-out of this behavior.
Also, the INavigationAware methods did not get called to all tabs meaning that you would be responsible for forwarding any parameters to all your tabs.
NavigateAsync("TabbedPage/ViewA/ViewB") will no longer select any tabs, but rather continue processing the navigation as separate pages on the navigation stack.
If you wish to select a tab, you will now use a parameter called "selectedTab" to indicate which tab you would like to select.
NavigateAsync("TabbedPage?selectedTab=MiddleTab/ViewA/ViewB")
This will navigate to the TabbedPage, selected the "MiddleTab" and continue navigating ViewA and ViewB onto the navigation stack.
For tabs that are wrapped inside a NavigationPage, you do not need to change anything. The syntax is the same. This will search each tab to see if it is a navigation page and if the CurrentPage of the NavigationPage matches "MiddleTab", the tab will be selected. This is much more flexible than the existing behavior as before it would take the first instance of the NavigationPage found. Now you can choose which tab exactly.
There is a constant in the KnownNavigationParameters called SelectedTab that you can use instead of a string.
NavigateAsync($"TabbedPage?{KnownNavigationParameters.SelectedTab}=MiddleTab")
Some INavigationAware methods are now fired on all Tabs:
Note: the parameter key selectedTab is now a reserved parameter name. Similar to a reserved keyword in C#. If you use this in your app as a key, you may experience undesired behavior.
Note: At this time there is no native support for deep linking into a Tab that is a navigation page. Please let me know if you need this functionality.
You can now dynamically create tabs when navigating to a TabbedPage by using the KnownNavigationParameters.CreateTab constant or by using the "createTab" parameter name.
_navigationService.NavigateAsync("MyTabbedPage?createTab=ViewA&createTab=ViewB");
This will create a TabbedPage and then create two tabs, ViewA and ViewB.
To create a tab that wraps a page in a NavigationPage, simply denote this as a nested hierarchy using the | character.
_navigationService.NavigateAsync("MyTabbedPage?createTab=NavigationPage|ViewA");
This feature allows you to remove pages form the navigation stack of a NavigationPage while at the same time navigating to a new page. For each page you wish to remove, prefix your navigation path with ../.
Example Our app requires a user to login in order to edit "User" profile information. This will require the user to be prompted to login and then once successful continue to edit the profile. This leaves us with the following navigation stack:
"NavigationPage/UserList/UserDetails/LoginPage/EditUser"
If we were to hit the back button from the EditUser page, we would be returned to the LoginPage. This is not the desired experience. Instead, we want to go back to the UserDetails which was just updated. To achieve this we provide the following navigation URI from the LoginPage page with a successful login attempt.
NavigationService.NavigateAsync("../EditUser");
This would remove the LoginPage and then immediately navigate to the "EditUser" page which we now have access to.
You can chain the ../ instruction for each page that needs to be removed from the stack.
Given: "NavigationPage/ViewA/ViewB/ViewC/ViewD"
Navigate from ViewD with: NavigationService.NavigateAsync("../../../ViewE");
Results in: "NavigationPage/ViewA/ViewE"
Note: This only works when navigating within a NavigationPage! Modal pages are not supported.
You can now control the various segments of a deep ink by setting the useModalNavigation parameter on any specific navigation segment in the URI.
NavigatAsync("NavigationPage/ViewA/ViewB/NavigationPage?useModalNavigation=true/ViewC/ViewD");
You can also use the built-in constant KnownNavigationParameters.UseModalNavigation
NavigatAsync($"NavigationPage/ViewA/ViewB/NavigationPage? {KnownNavigationParameters.UseModalNavigation} =true/ViewC/ViewD");
Note: the parameter key useModalNavigation is now a reserved parameter name. Similar to a reserved keyword in C#. If you use this in your app as a key, you may experience undesired behavior.
.NET Standard Support
Added method to clear all errors on ErrorsContainer
Removed requirement for parameter in delegate definition of DelegateCommand.ObservesCanExecute Breaking
Example:
Old (v6.3): ObservesCanExcute((**vm**) => Property)
New (v7.0): ObservesCanExecute(() => Property)
Add capability to DelegateCommand's ObservesProperty to observe properties of complex types
Example:
ObservesProperty(() => Property.NestedProperty.NestedPoperty)
#650: Navigating between Tabs Breaking
#683: .NET Standard support
#765: Deep linking within a NavigationPage results in an incorrect ContentPage Title on Android
#921: Add ability to Remove pages from the navigation stack
#1007: Re-license to MIT, following the Microsoft led projects
#1008: NavigationParameters: Not possible to specify parent type as generic parameter T
#1111: Include pdb file in nuget package
#1024: XF: NavigationService swallowing Exceptions
#1025: Xamarin.Forms deprecated the Device.OS property in favor of the RuntimePlatform property. The following changes were made to accommodate these changes: IDeviceService
deprecated OnPlatform methods
added DeviceRuntimePlatform property - this mimics the XF API and returns a string
added RuntimePlatform property which returns an Enum of type RuntimePlatform and wraps the XF string-based values
#1027: Support macOS
#1044: When Detail of MasterDetailPage is null, Modal Navigation is possible
#1045: When calling NavigateAsync with NavigationPage, old page's Destroy on the stack is not called
#1046: When calling DeepLink from Navigation Stack, the second page becomes Modal navigation
#1054: When deep linking within NavigationPage, page order is reversed
#1063: Master of MasterDetailPage will not be destroyed
#1074: Optimize Xamarin Forms DryIoc adapter performance
#1085: Error occurs if null path is specified in EventToCommandBehavior
#1089: DebugLogger does not work in nuget-package
#1099: Introduce a Behavior factory into the navigation service
#1132: Prism Forms Modularity extension methods
#1133: IModuleCatalog AddModule returns wrong type
#1139: Modularity Enhancements
#1175: Upgraded to Unity 5 Breaking
#1076: IActiveAware not working when ContentPage (as child of a TabbedPage) is wrapped into a NavigationPage
#1166: Custom NavigationPage is not working properly Prism 7
#1187: Change TabbedPage navigation behavior Breaking
#1198: Rename IApplicationLifecycle to IApplicationLifecycleAware Breaking
#1200: Add GoBackToRoot method
#1232: PageNavigationService should check for MultiPage Parent
#1225: OnNavigatedTo Contains Extra Parameter
#1254: remove support for DependenyService autoresolution Breaking
added IPageLifecycleAware and PageLifecycleAwareBehavior to enable responding to the Page's Appearing and Disappearing events
Container Extensions
Container.RegisterTypeForNavigationOnPlatform<MainPage, MainPageViewModel>("Main",
new Platform<MainPage_Android>(RuntimePlatform.Android),
new Platform<MainPage_iOS>(RuntimePlatform.iOS));
NavigateAsync("TabbedPage/ViewA/ViewB") will select the tab ViewA in the TabbedPage if it exists, then continue navigating. If ViewA does not exist as a tab, then you will continue to navigate as expected.
NavigateAsync("TabbedPage/NavigationPage/ViewA/ViewB") would search the TabbedPage for the first instance of a tab that was a NavigationPage, then navigate within the Navigation page the remaining ViewA and ViewB pages. This provided the ability to deep link into a tab's nested navigation page, but there was no way to opt-out of this behavior.
Also, the INavigationAware methods did not get called to all tabs meaning that you would be responsible for forwarding any parameters to all your tabs.
NavigateAsync("TabbedPage/ViewA/ViewB") will no longer select any tabs, but rather continue processing the navigation as separate pages on the navigation stack.
If you wish to select a tab, you will now use a parameter called "selectedTab" to indicate which tab you would like to select.
NavigateAsync("TabbedPage?selectedTab=MiddleTab/ViewA/ViewB")
This will navigate to the TabbedPage, selected the "MiddleTab" and continue navigating ViewA and ViewB onto the navigation stack.
For tabs that are wrapped inside a NavigationPage, you do not need to change anything. The syntax is the same. This will search each tab to see if it is a navigation page and if the CurrentPage of the NavigationPage matches "MiddleTab", the tab will be selected. This is much more flexible than the existing behavior as before it would take the first instance of the NavigationPage found. Now you can choose which tab exactly.
There is a constant in the KnownNavigationParameters called SelectedTab that you can use instead of a string.
NavigateAsync($"TabbedPage?{KnownNavigationParameters.SelectedTab}=MiddleTab")
Some INavigationAware methods are now fired on all Tabs:
Note: the parameter key selectedTab is now a reserved parameter name. Similar to a reserved keyword in C#. If you use this in your app as a key, you may experience undesired behavior.
Note: At this time there is no native support for deep linking into a Tab that is a navigation page. Please let me know if you need this functionality.
You can now dynamically create tabs when navigating to a TabbedPage by using the KnownNavigationParameters.CreateTab constant or by using the "createTab" parameter name.
_navigationService.NavigateAsync("MyTabbedPage?createTab=ViewA&createTab=ViewB");
This will create a TabbedPage and then create two tabs, ViewA and ViewB.
To create a tab that wraps a page in a NavigationPage, simply denote this as a nested hierarchy using the | character.
_navigationService.NavigateAsync("MyTabbedPage?createTab=NavigationPage|ViewA");
This feature allows you to remove pages form the navigation stack of a NavigationPage while at the same time navigating to a new page. For each page you wish to remove, prefix your navigation path with ../.
Example Our app requires a user to login in order to edit "User" profile information. This will require the user to be prompted to login and then once successful continue to edit the profile. This leaves us with the following navigation stack:
"NavigationPage/UserList/UserDetails/LoginPage/EditUser"
If we were to hit the back button from the EditUser page, we would be returned to the LoginPage. This is not the desired experience. Instead, we want to go back to the UserDetails which was just updated. To achieve this we provide the following navigation URI from the LoginPage page with a successful login attempt.
NavigationService.NavigateAsync("../EditUser");
This would remove the LoginPage and then immediately navigate to the "EditUser" page which we now have access to.
You can chain the ../ instruction for each page that needs to be removed from the stack.
Given: "NavigationPage/ViewA/ViewB/ViewC/ViewD"
Navigate from ViewD with: NavigationService.NavigateAsync("../../../ViewE");
Results in: "NavigationPage/ViewA/ViewE"
Note: This only works when navigating within a NavigationPage! Modal pages are not supported.
Breaking
Example:
Old (v6.3): ObservesCanExcute((**vm**) => Property)
New (v7.0): ObservesCanExecute(() => Property)
Example:
ObservesProperty(() => Property.NestedProperty.NestedPoperty)
Fixed #650: Navigating between Tabs Breaking
Fixed #683: .NET Standard support
Fixed #765: Deep linking within a NavigationPage results in an incorrect ContentPage Title on Android
Fixed #921: Add ability to Remove pages from the navigation stack
Fixed #1007: Re-license to MIT, following the Microsoft led projects
Fixed #1008: NavigationParameters: Not possible to specify parent type as generic parameter T
Fixed #1111: Include pdb file in nuget package
Fixed #1024: XF: NavigationService swallowing Exceptions
Fixed #1025: Xamarin.Forms deprecated the Device.OS property in favor of the RuntimePlatform property. The following changes were made to accommodate these changes: IDeviceService
deprecated OnPlatform methods
added DeviceRuntimePlatform property - this mimics the XF API and returns a string
added RuntimePlatform property which returns an Enum of type RuntimePlatform and wraps the XF string-based values
Fixed #1027: Support macOS
Fixed #1044: When Detail of MasterDetailPage is null, Modal Navigation is possible
Fixed #1045: When calling NavigateAsync with NavigationPage, old page's Destroy on the stack is not called
Fixed #1046: When calling DeepLink from Navigation Stack, the second page becomes Modal navigation
Fixed #1054: When deep linking within NavigationPage, page order is reversed
Fixed #1063: Master of MasterDetailPage will not be destroyed
Fixed #1085: Error occurs if null path is specified in EventToCommandBehavior
Fixed #1089: DebugLogger does not work in nuget-package
Fixed #1132: Prism Forms Modularity extension methods
Fixed #1133: IModuleCatalog AddModule returns wrong type
Fixed #1139: Modularity Enhancements
Fixed #1076: IActiveAware not working when ContentPage (as child of a TabbedPage) is wrapped into a NavigationPage
Fixed #1166: Custom NavigationPage is not working properly Prism 7
Fixed #1187: Change TabbedPage navigation behavior Breaking
Fixed #1198: Rename IApplicationLifecycle to IApplicationLifecycleAware Breaking
Fixed #1200: Add GoBackToRoot method
added IPageLifecycleAware and PageLifecycleAwareBehavior to enable responding to the Page's Appearing and Disappearing events
adds ability to create tabs in a TabbedPage dynamically through the querystring
You can now dynamically create tabs when navigating to a TabbedPage by using the KnownNavigationParameters.CreateTab constant or by using the "createTab" parameter name.
_navigationService.NavigateAsync("MyTabbedPage?createTab=ViewA&createTab=ViewB");
This will create a TabbedPage and then create two tabs, ViewA and ViewB.
To create a tab that wraps a page in a NavigationPage, simply denote this as a nested hierarchy using the | character.
_navigationService.NavigateAsync("MyTabbedPage?createTab=NavigationPage|ViewA");
Container Extensions
Container.RegisterTypeForNavigationOnPlatform<MainPage, MainPageViewModel>("Main",
new Platform<MainPage_Android>(RuntimePlatform.Android),
new Platform<MainPage_iOS>(RuntimePlatform.iOS));
NavigateAsync("TabbedPage/ViewA/ViewB") will select the tab ViewA in the TabbedPage if it exists, then continue navigating. If ViewA does not exist as a tab, then you will continue to navigate as expected.
NavigateAsync("TabbedPage/NavigationPage/ViewA/ViewB") would search the TabbedPage for the first instance of a tab that was a NavigationPage, then navigate within the Navigation page the remaining ViewA and ViewB pages. This provided the ability to deep link into a tab's nested navigation page, but there was no way to opt-out of this behavior.
Also, the INavigationAware methods did not get called to all tabs meaning that you would be responsible for forwarding any parameters to all your tabs.
NavigateAsync("TabbedPage/ViewA/ViewB") will no longer select any tabs, but rather continue processing the navigation as separate pages on the navigation stack.
If you wish to select a tab, you will now use a parameter called "selectedTab" to indicate which tab you would like to select.
NavigateAsync("TabbedPage?selectedTab=MiddleTab/ViewA/ViewB")
This will navigate to the TabbedPage, selected the "MiddleTab" and continue navigating ViewA and ViewB onto the navigation stack.
For tabs that are wrapped inside a NavigationPage, you do not need to change anything. The syntax is the same. This will search each tab to see if it is a navigation page and if the CurrentPage of the NavigationPage matches "MiddleTab", the tab will be selected. This is much more flexible than the existing behavior as before it would take the first instance of the NavigationPage found. Now you can choose which tab exactly.
There is a constant in the KnownNavigationParameters called SelectedTab that you can use instead of a string.
NavigateAsync($"TabbedPage?{KnownNavigationParameters.SelectedTab}=MiddleTab")
Some INavigationAware methods are now fired on all Tabs:
Note: the parameter key selectedTab is now a reserved parameter name. Similar to a reserved keyword in C#. If you use this in your app as a key, you may experience undesired behavior.
Note: At this time there is no native support for deep linking into a Tab that is a navigation page. Please let me know if you need this functionality.
This feature allows you to remove pages form the navigation stack of a NavigationPage while at the same time navigating to a new page. For each page you wish to remove, prefix your navigation path with ../.
Example Our app requires a user to login in order to edit "User" profile information. This will require the user to be prompted to login and then once successful continue to edit the profile. This leaves us with the following navigation stack:
"NavigationPage/UserList/UserDetails/LoginPage/EditUser"
If we were to hit the back button from the EditUser page, we would be returned to the LoginPage. This is not the desired experience. Instead, we want to go back to the UserDetails which was just updated. To achieve this we provide the following navigation URI from the LoginPage page with a successful login attempt.
NavigationService.NavigateAsync("../EditUser");
This would remove the LoginPage and then immediately navigate to the "EditUser" page which we now have access to.
You can chain the ../ instruction for each page that needs to be removed from the stack.
Given: "NavigationPage/ViewA/ViewB/ViewC/ViewD"
Navigate from ViewD with: NavigationService.NavigateAsync("../../../ViewE");
Results in: "NavigationPage/ViewA/ViewE"
Note: This only works when navigating within a NavigationPage! Modal pages are not supported.
ObservesProperty(() => Property.NestedProperty.NestedPoperty)
IDeviceService
Container Extensions
Container.RegisterTypeForNavigationOnPlatform<MainPage, MainPageViewModel>("Main",
new Platform<MainPage_Android>(RuntimePlatform.Android),
new Platform<MainPage_iOS>(RuntimePlatform.iOS));
NavigateAsync("TabbedPage/ViewA/ViewB") will select the tab ViewA in the TabbedPage if it exists, then continue navigating. If ViewA does not exist as a tab, then you will continue to navigate as expected.
NavigateAsync("TabbedPage/NavigationPage/ViewA/ViewB") would search the TabbedPage for the first instance of a tab that was a NavigationPage, then navigate within the Navigation page the remaining ViewA and ViewB pages. This provided the ability to deep link into a tab's nested navigation page, but there was no way to opt-out of this behavior.
Also, the INavigationAware methods did not get called to all tabs meaning that you would be responsible for forwarding any parameters to all your tabs.
NavigateAsync("TabbedPage/ViewA/ViewB") will no longer select any tabs, but rather continue processing the navigation as separate pages on the navigation stack.
If you wish to select a tab, you will now use a parameter called "selectedTab" to indicate which tab you would like to select.
NavigateAsync("TabbedPage?selectedTab=MiddleTab/ViewA/ViewB")
This will navigate to the TabbedPage, selected the "MiddleTab" and continue navigating ViewA and ViewB onto the navigation stack.
For tabs that are wrapped inside a NavigationPage, you can use the "|" symbol to indicate the hierarchy.
NavigateAsync("TabbedPage?selectedTab=NavigationPage|MiddleTab")
There is a constant in the KnownNavigationParameters called SelectedTab that you can use instead of a string.
NavigateAsync($"TabbedPage?{KnownNavigationParameters.SelectedTab}=MiddleTab")
This will search each tab to see if it is a navigation page and if the first page on the stack matches "MiddleTab". This is much more flexible than the existing behavior as before it would take the first instance of the NavigationPage found. Now you can choose which tab exactly.
Some INavigationAware methods are now fired on all Tabs:
Note: the parameter key selectedTab is now a reserved parameter name. Similar to a reserved keyword in C#. If you use this in your app as a key, you may experience undesired behavior.
Note: At this time there is no native support for deep linking into a Tab that is a navigation page. Please let me know if you need this functionality.
ObservesProperty(() => Property.NestedProperty.NestedPoperty)
IDeviceService
Container Extensions
Container.RegisterTypeForNavigationOnPlatform<MainPage, MainPageViewModel>("Main",
new Platform<MainPage_Android>(RuntimePlatform.Android),
new Platform<MainPage_iOS>(RuntimePlatform.iOS));
This release included some refactoring of PrismApplication, PrismUnityApplication, and PrismAutofacApplication to removed sealed on a couple members that were inadvertantly sealed in the 6.0.0 release, as well as to incorporate bootstrapping patterns for containers similar to what the Prism.Wpf bootstrappers do.