Skip to content

7.1.0 RTM
Compare
Choose a tag to compare
@dansiegel dansiegel released this 15 Oct 16:11
· 1491 commits to master since this release
v7.1.0
9d05095
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.

General Notes

In addition to the typical bug fixes Prism 7.1 brings a much more consolidated approach to developing applications. Perhaps this is most clear with Prism.Modularity now being defined entirely in the Prism.Core providing a consistent API for Prism.Forms and Prism.WPF, as well as making it available for the first time to Prism.Windows (in an upcoming preview).

Due to the major changes in where certain types are for Modularity (and Navigation for Prism.Forms), you may experience binary incompatibility issues when using libraries that target older versions of Prism.

Container Notices

Going forward we will only consider support for containers that work properly for Prism. The Prism team advises all developers to update projects to use the new PackageReference, this will help simplify maintaining which packages you need to update by simply targeting the Prism Container package (see Unity notice).

Autofac

After much discussion the Prism team has decided that this will be the final release for Autofac. Modularity is a core capability for Prism, which requires the use of a Mutable container. The fact that the Autofac team has chosen to make Autofac Immutable prevents us from being able to support the use of containers.

MEF

Similarly the Prism team has decided that we will no longer be shipping or supporting MEF for WPF, nor will support be added for any other platforms.

Unity

Unity continues to be a very popular and fully supported container. For those upgrading to Prism 7.1 from Prism 6.X, note that you will need to uninstall the Unity references in your existing projects as the new maintainer for Unity has completely rearchitected the Unity Container. This included changing namespaces and changing how the library was shipped forcing the Prism Team to change the NuGet that we target from Unity to Unity.Container.

Prism.Core

  • #1348: Navigation Alignment - moved all navigation interfaces into Prism Core (currently hidden from WPF)
  • #1476: Module Alignment - moved Exceptions, ModuleInfo, and several Modularity interfaces to Prism.Core from WPF combining with some Prism.Forms definitions.
    • IModuleManager.ModuleDownloadProgressChanged (available in net45 aka WPF ONLY)
  • #1505: Memory problem with EventAggregator and never published message
  • #1509: Module Alignment Updates: Introduce IModuleInfo
  • #1511: Module Alignment
    • All modularity interfaces and base & supporting types moved to Prism.Core

Prism.Forms

  • #1348: Navigation alignment
    • Added INavigationParameters
    • Added INavigationParametersInternal
    • Added INavigationResult
    • Convert all methods using NavigationParameters to use the new INavigationParameters BREAKING
    • Changed Task INavigationService.NavigateAsync to Task<INavigationResult> INavigationService.NavigateAsync
    • Changed Task<bool> INavigationService.GoBackAsync to Task<INavigationResult> INavigationService.GoBackAsync BREAKING
  • #1347: ContainerProvider - Allows Declaring Types in XAML that require the Container to Resolve them
  • #1353: NavigationFrom not called when navigate to different Hamburger Menu Page
  • #1354: INavigationAware methods are not called on children of a CarouselPage
  • #1403: Remove pages from NavigationStack without pushing another one
  • #1414: Changed from Unity NuGet to Unity.Container BREAKING
  • #1425: XAML Navigation
  • #1439: DependencyResolver
  • #1456: Relative back navigation does not work with INavigationParameters
  • #1463: DryIoc Default Rules Change. By default DryIoc will attempt to resolve types based on an available constructor with resolvable types. Secondary registrations will now replace any initial registration by default.
  • #1464: Unity and Autofac no longer require INavigationService to be named navigationService inside of a ViewModel.
  • #1469: Make Xamarin.Forms DependencyResolver Opt-In
  • #1476: Module Alignment BREAKING
    • ModuleInfo.ModuleType has changed from System.Type to System.String and is equal to Type.AssemblyQualifiedName
    • IModuleManager.LoadModuleCompleted - Forms will now invoke this event when a new module has been loaded. Note there is not currently a default handler provided by PrismApplication. This event will contain any caught exception that was thrown while attempting to load a Module.
    • Moved all Modularity interfaces except IModuleCatalog to Prism.Core
  • #1509: Module Alignment
    • Adds IModuleInfo
    • ModuleInfo moved back to Prism.Forms. ModuleInfo will now return Module Dependencies when decorated with the ModuleDependencyAttribute if dependencies are not set at Registration.
  • #1511: Module Alignment - All modularity interfaces and base & supporting types moved to Prism.Core
  • #1519: Support Partial Views in Xamarin Forms
  • #1546: MasterDetailPage navigation on iOS is unexcepted
  • #1549: EventToCommandBehavior.OnEventRaised NullReferenceException

Partial Views

The concept of a Partial View is to support a custom layout which may be reused across multiple pages, and eliminate ViewModel logic duplication by allowing that custom layout to rely on its own ViewModel. To use a Partial View you must set the ViewModelLocator.AutowirePartialView property with a reference to the containing page as shown here. You should not set the ViewModelLocator.AutowireViewModel property on the Partial View unless you are explicitly opting out as setting this property to true directly may result in the ViewModel being incorrectly set.

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:local="clr-namespace:AwesomeApp.Views"
             xmlns:prism="clr-namespace:Prism.Ioc;assembly=Prism.Forms"
             xmlns:mvvm="clr-namespace:Prism.Mvvm;assembly=Prism.Forms"
             x:Name="self"
             x:Class="AwesomeApp.Views.ViewA">
  <StackLayout>
    <local:AwesomeView mvvm:ViewModelLocator.AutowirePartialView="{x:Reference self}" />
    <Entry Text="{Binding SomeValue" />
  </StackLayout>
</ContentPage>

Dependency Resolver

Xamarin.Forms 3.1 introduces a new DependencyResolver. This enables applications using Dependency Injection to use their Container to resolve Platform Renderers and Effects which makes it possible to inject any services such as a logger. Since the default constructor was deprecated in Android Renderers as of Xamarin.Forms 2.5, Prism now includes a specific Android binary that enables the DependencyResolver to resolve types using

ContainerProvider

The Container Provider now allows types like ValueConverters to include Dependency Injection of Types/Services in the ctor, and allows the converter to be declared in XAML

namespace Contoso.Converters
{
    public class MyValueConverter : IValueConverter
    {
        private ILoggerFacade _logger { get; }

        public MyValueConverter(ILoggerFacade logger)
        {
            _logger = logger;
        }

        public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
        {
            _logger.Log("Converting value", Category.Debug, Priority.None);
            return value;
        }

        public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
        {
            _logger.Log("Converting Value Back...", Category.Debug, Priority.None);
            return value;
        }
    }
}

This can then be used in XAML using the ContainerProvider as follows:

<ContentPage xmlns="http://xamarin.com/schemas/2014/forms"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:ioc="clr-namespace:Prism.Ioc;assembly=Prism.Forms"
             xmlns:converters="using:Contoso.Converters"
             x:Class="Contoso.Views.ViewA">
    <ContentPage.Resources>
        <ResourceDictionary>
            <ioc:ContainerProvider x:TypeArguments="converters:MyValueConverter" x:Key="myValueConverter" />
        </ResourceDictionary>
    </ContentPage.Resources>
    <Entry Text="{Binding Demo,Converter={StaticResource myValueConverter}}" />
</ContentPage>

Navigation Improvements

**Implemented relative back behavior ("../../") **

Previously, when using the relative back feature ("../" ) you would be required to provide a page that would be pushed onto the navigation stack. That is no longer required. You may now chain together any number of relative go-back instructions to "go back".

For example:
Given your navigation stack looked like this: NavigationPage/UserList/UserDetails/LoginPage/EditUser

You can now indicate how many pages to remove, or "go back" by chaining the relative go-back instruction "../".

NavigationService.NavigateAsync("../../../");

This would result in going back three pages leaving you with the following navigation stack:

NavigationPage/UserList

NOTE - The pages in the stack prior to the current page (last page in the nav stack) will be removed without calling any INavAware methods. Only the current page (EditUser in this example) would perform a proper GoBackAsync and execute the INavAware methods.

NOTE - This feature is only supported while within the context of a NavigationPage.

XAML Navigation

You can now use XAML Navigation Extensions to Navigate. This works well for scenarios where you may have a partial "MenuView" that may be reused across multiple Pages or where there may be no real reason to implement Navigation inside of a ViewModel.

<!-- basic nav -->
<Button Text="Go To About" Command"{prism:NavigateTo 'About'}" />

<!-- basic nav without animation-->
<Button Text="Go To About" Command"{prism:NavigateTo 'About', Animated=False}" />

<!-- basic modal nav -->
<Button Text="Go To About" Command"{prism:NavigateTo 'About', UseModalNavigation=True}" />

<!-- custom can navigate support -->
<Button Text="Go To About" Command="{prism:NavigateTo 'About'}" prism:Navigation.CanNavigate="{Binding CanNavigate}" />

<!-- go to new page, but remove one along the way -->
<Button Text="Go To Settings" Command"{prism:NavigateTo '../Settings'}" />

<!-- nav with VM Parameters -->
<Button Text="Go To About" 
        Command"{prism:NavigateTo 'About'}" 
        CommandParameters="{Binding MyNavParams}" />

<!-- Go Back -->
<Button Text="Go Back" Command="{prism:GoBack}" />

<!-- Go Back To Root -->
<Button Text="Go Back To Root" Command="{prism:GoBack ToRoot}" />

<!-- Xaml defined parameters -->
<Button Text="Go To About" Command="{prism:NavigateTo 'About'}" >
    <Button.CommandParameter>
        <prism:XamlNavigationParameters Parent="{x:Reference this}">
            <prism:XamlNavigationParameter Key="MainPageViewModel" Value="{Binding .}" />
        </prism:XamlNavigationParameters>
    </Button.CommandParameter>
</Button>

<!-- can navigate on a parent object-->
<ContentView>
    <ContentView prism:Navigation.CanNavigate="False">
        <ContentView>
            <Button Text="Cannot Navigate" Command="{prism:GoBack}" /> 
        </ContentView>
    </ContentView>
</ContentView>

Prism.WPF

  • #30: Removing from, or opting out of registration, in the IRegionNavigationJournal
  • #993: RemoveAll throws if KeepAlive is false
  • #1013: MEF DirectoryModuleCatalog - problem with diacritics since 6.3
  • #1120: Prism.Autofac RegisterTypeForNavigation issue
  • #1128: ViewModelLocator triggers in design mode
  • #1161: Ninject - Prism creating new view even if view exists in region
  • #1165: Change PopupWindowAction.CreateDefaultWindow to virtual
  • #1175: Upgraded to Unity 5 Breaking
  • #1211: Upgrade to CommonServiceLocator 2.0.1 Breaking
  • #1217: Add OnInitialized methdo to bootstrapper
  • #1242: AssemblyResolver - File path in FileNotFoundException
  • #1261: ListDictionary TKey and TValue same type Breaking
  • #1264: Is it possible to provide a type safe way to read parameter
  • #1321: Added support for regions targeting FrameworkContentElements
  • #1327: Include correct version of System.Windows.Interactivity
  • #1328: Regions attached to DependencyObject sometimes won't register
  • #1414: BREAKING Changed from Unity NuGet to Unity.Container
  • #1463: DryIoc Default Rules Change. By default DryIoc will attempt to resolve types based on an available constructor with resolvable types. Secondary registrations will now replace any initial registration by default.
  • #1476: Module Alignment BREAKING
    • Moved Exceptions to Prism.Core
    • Moved ModuleInfo to Prism.Core (see #1509)
    • Moved IModuleCatalogItem to Prism.Core
    • Moved IModuleInitializer to Prism.Core
    • Moved IModuleManager to Prism.Core
  • #1479: Fixes issue that prevented Prism.Autofac apps from starting
  • #1493: Fixes issue that prevented Prism.Ninject apps from starting
  • #1504: Memory problem with EventAggregator and never published message
  • #1509: Module Alignment
    • Introduced new IModuleInterface and moved concrete implementations back to the Platform level. This fixes a break that would affect any ModuleCatalogs defined in XAML caused by changing the resolving assembly in the XML Namespace.
  • #1511: Module Alignment
    • All modularity interfaces and base & supporting types moved to Prism.Core
  • #1543: Calling ToString() on NavigationParameters causes NullReferenceException when parameter is null.

New PrismApplication Base Class

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.

Note: The Bootstrapper class is not being removed, it is only marked obsolete to drive awareness of the new PrismApplication class.

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.

Assets 2
Loading