I'm happy to report that I have (at last!) moved these files to Azure so you can download them again. Here are the download links: 

• Helix Navigation Framework: A simple route-based navigation framework for Silverlight and WPF - Download
• Prism Template Pack: A set of Visual Studio solution and project templates to speed up your Prism development - Download.
• Be sure to remove the .zip file extension once you've downloaded the template pack (so that it has a .vsix file extension)!
• Prism Tabbed Interface Sample: A Prism sample showing how to implement a tabbed view interface (similar to Visual Studio) - Download.

Remember to remove the .zip extension (leaving the .vsix extension!) before double-clicking to install the templates.

The Prism Template Pack now provides templates for a quick-start solution, a shell and a module, for both Silverlight and WPF, and in C# and Visual Basic.NET. That’s a grand total of 24 individual templates (!!), which is one reason why it took so long to release this update.

To make it easier to find the right template, I’ve added MEF and Unity categories under the Prism node. This approach isn’t ideal but it means you won’t have to parse a large flat list of templates. In the near future I’ll investigate moving to a wizard-based approach where you can choose between MEF and Unity, and other configuration options, using a wizard dialog. That should allow the templates to support more variations without exponentially increasing the number of templates .

As always, please let me know what you think.

Prism regions make it easy to change the layout of views within an application. A region is a logical placeholder associated with a specific layout control. Displaying a view in a region causes the view to be added to the layout control. But because the region and the layout control are loosely coupled, you can easily swap the layout control for a different one without having to change the modules in the application. For example, you can change from a tabbed view to a single document view.

While Prism makes it easy to add views to regions, it isn’t obvious how to close and remove a view from a region, especially from the UI. A common scenario is when you have multiple views displayed in tab control and the user can close individual views using a close button on the tab header. You can see this tabbed view style of UI in Internet Explorer and in Visual Studio.

This sample shows how this can be done. It’s based on the quick start solution that’s provided by the Prism 4.0 Template Pack. There are really only a couple of minor changes to the quick start solution’s shell. All of the real work is done in a new re-usable Blend action class called CloseTabbedViewAction.

The Shell View

Before we dig into that class, let’s take a look at the changes in the shell’s view. The TabControl that is used to layout views in the Main region is declared as:

   1: <sdk:TabControl prism:RegionManager.RegionName="MainRegion" ...

   2:     prism:TabControlRegionAdapter.ItemContainerStyle=

   3:            "{StaticResource TabHeaderStyle}">

   4:     ...

   5: </sdk:TabControl>

   1: <Style x:Key="TabHeaderStyle" TargetType="sdk:TabItem">

   2:   <Setter Property="HeaderTemplate">

   3:     <Setter.Value>

   4:        <DataTemplate>

   5:         <StackPanel Orientation="Horizontal">

   6:           <Image ... />

   7:           <TextBlock ... />

   8:           <Button Content="x" ToolTipService.ToolTip="Close this view." ...>

   9:             <ei:Interaction.Triggers>

  10:               <ei:EventTrigger EventName="Click">

  11:                 <local:CloseTabbedViewAction />

  12:               </ei:EventTrigger>

  13:             </ei:Interaction.Triggers>

  14:           </Button>

  15:         </StackPanel>

  16:       </DataTemplate>

  17:     </Setter.Value>

  18:   </Setter>

  19: </Style>

The CloseTabbedViewAction Class

   1: private T FindVisualParent<T>( DependencyObject node ) where T : DependencyObject

   2: {

   3:     DependencyObject parent = VisualTreeHelper.GetParent( node );

   4:     if ( parent == null || parent is T ) return (T)parent;

   5:  

   6:     // Recurse up the visual tree.

   7:     return FindVisualParent<T>( parent );

   8: }

   1: public class CloseTabbedViewAction : TriggerAction<FrameworkElement>

   2: {

   3:     protected override void Invoke( object parameter )

   4:     {

   5:         RoutedEventArgs args = parameter as RoutedEventArgs;

   6:         if ( args == null ) return;

   7:  

   8:         // Find the parent tab item that contains the view to remove.

   9:         TabItem tabItem = FindVisualParent<TabItem>( args.OriginalSource as DependencyObject );

  10:  

  11:         // Find the parent tab control that represents the region.

  12:         TabControl tabControl = FindVisualParent<TabControl>( tabItem );

  13:  

  14:         if ( tabControl != null && tabItem != null )

  15:         {

  16:             // Get the view.

  17:             object view = tabItem.Content;

  18:  

  19:             // Get the region associated with the tab control.

  20:             IRegion region = RegionManager.GetObservableRegion( tabControl ).Value;

  21:             if ( region != null )

  22:             {

  23:                 region.Remove( view );

  24:             }

  25:         }

  26:     }

Integrating with Region Navigation

   1: private T Implementor<T>( object content ) where T : class

   2: {

   3:     T impl = content as T;

   4:     if ( impl == null )

   5:     {

   6:         FrameworkElement element = content as FrameworkElement;

   7:         if ( element != null ) impl = element.DataContext as T;

   8:     }

   9:     return impl;

  10: }

   1: private bool NotifyIfImplements<T>( object content,

   2:                  Action<T> action ) where T : class

   3: {

   4:     bool notified = false;

   5:  

   6:     // Get the implementor of the specified interface -

   7:     // either the view or the view model.

   8:     T target = Implementor<T>( content );

   9:     if ( target != null )

  10:     {

  11:         action( target );

  12:         notified = true;

  13:     }

  14:     return notified;

  15: }

   1: NavigationContext context = new NavigationContext( region.NavigationService, null );

   2:  

   3: // See if the view (or its view model) supports the INavigationAware interface.

   4: // If so, call the OnNavigatedFrom method.

   5: NotifyIfImplements<INavigationAware>( view, i => i.OnNavigatedFrom( context ) );

   6:  

   1: // See if the view (or its view model) supports the

   2: // IConfirmNavigation interface.

   3: // If so, call the ConfirmNavigationRequest method.

   4: // If not, just remove the view from the region. 

   5: if ( !NotifyIfImplements<IConfirmNavigationRequest>( view,

   6:     i => i.ConfirmNavigationRequest( context,

   7:     canNavigate => { if ( canNavigate ) if ( region != null )

   8:                                region.Remove( view ); } ) ) )

   9: {

  10:     // Remove the view.

  11:     region.Remove( view );

  12: }

The Prism 4.0 Template Pack contains Prism shell and module project templates and a quick-start solution template which creates a multi-project solution with a shell and two modules. All templates are available for both Silverlight and WPF and for C# or Visual Basic.NET.

The templates are deployed as a vsix package. Downloaded the template pack from here and then rename the file to remove the .zip file extension. Double click on the Prism.TemplatePack.1.3.vsix file, review and accept the license agreement, and the templates will be installed and available in the Visual Studio New Project Dialog under the Prism node. Release notes for the template pack are available here.

Prism 4.0 (also available on MSDN here) ships with signed binary assemblies. You can register these assemblies with Visual Studio by running the RegisterPrismBinaries.bat batch file. This allows Visual Studio to automatically resolve all assembly references in the newly generated projects. If you have built the Prism assemblies yourself you will have to manually fix up the project references to point to the Prism assembly locations on your system. Remember, for Silverlight projects, you will have to manually create Silverlight Application References in the Web project so that the shell and two modules XAP files are deployed to the hosting web site.

Note: To use the Quick Start Solution templates, you will need to have the Expression Blend SDK for Silverlight (here) and/or WPF (here) installed.

A Quick Tour

The templates provide boiler-plate code that demonstrates many of the features provided by Prism, including:

• The Model-View-ViewModel (MVVM) Pattern
• Dependency Injection using Unity
• Modularity
• Commands
• Interaction Requests
• Regions
• Navigation
• Loosely coupled events using the Event Aggregator

The quick start solution templates creates a simple multi-module Prism solution that shows all of these features working together. You can use this template to create a simple but working end-to-end application which you can evolve to your own requirements. For this release, I have updated the quick start solution quite a bit to illustrate some of the new features available in Prism 4.0, including those that support the MVVM pattern and region-based navigation.

The solution consists of two modules that are loaded into a shell that uses a tab control to organize views in the main region on the right. Module 1 provides a collection of data items that are displayed in a list box using a collection view. The user can use commands to navigate to views which are then displayed as tabs in the main region. Module 2 provides a single view that responds to loosely-coupled events that are fired when the user selects an item in Module 1’s list view.

The solution shows how to use some of the more advanced features of Prism’s region navigation support. Clicking on the arrow button for an item causes an Edit View for that item to be displayed in the main region. The Edit View uses an interaction request to prompt the user if they decide to navigate away from that view. The other button causes the Details View to be displayed. This view is re-used and updated to display the corresponding item. The navigational behavior of the views are defined by the INavigationAware and IConfirmNavigationRequest interfaces implemented by the view model classes.

I’ve tested the templates extensively but if you find anything that needs fixing or improving, please let me know. If everything is ok, I’ll put the template pack in the Visual Studio Code Gallery to make them available from within Visual Studio’s Extension Manager directly…

To install the templates, download the template pack from here, rename the file extension from .zip to .vsix, then double click it. You’ll be presented with the license. Once you accept everything will be installed into the Visual Studio Extension Manager. If you already have the RC version installed, it should be updated automatically.

If you used the Release Candidate release of the Template Pack, you’ll notice a few updates in this version:

• Both Visual C# and Visual Basic templates are now provided!!!
• The templates have been updated to target Prism 2.2 (available here), which uses the latest Unity 2.0 and EntLib 5.0 releases.
• Some folks reported problems installing the templates. It seems these problems were due to long path names in the vsix package. I’ve shortened the paths so hopefully this issue is now resolved. (Many thanks to Silverlight Dude for figuring this out!!!)
• I’ve also fixed a few minor bugs, and updated the readme files to cover the use of Unity 2.0 and EntLib 5.0. Apart from that, everything should work as before…

Now With Visual Basic Templates!!!

The biggest new feature of course, is that the Template Pack now provides Visual Basic .NET templates as well as C#. This was one of the reasons why it took me so long to update the templates – my VB was a bit rusty :-)

Please give them a whirl and let me know what you think. If there are no problems, I’ll post them up onto the Visual Studio Gallery.

One of the key questions that we’d like to get feedback on, is whether we should solely target .NET 4.0 and Silverlight 4.0, or whether we should also target .NET 3.5 SP1 and Silverlight 3.0. I’m sure there are many folks who have existing solutions and would like to take advantage of Prism 4.0. But, there are significant new features in .NET/SL 4.0 (such as the Managed Extensibility Framework) that greatly simplify app development.

Focusing on .NET/SL 4.0 would also allow us to greatly simplify Prism, which in turn would allow us to cover additional areas of guidance. The survey describes a number of these potential areas, including security, data/service access, designer-developer workflow, design-time support, out-of-browser applications, UI patterns, navigation, etc.

As you can see, there are a lot of areas that we could provide guidance on but we can’t tackle them all. We need to hear from you so that we can prioritize appropriately. So please take the survey and let us know what you think are the most important aspects for us to focus on.

The templates themselves are similar to those I released a while back – there are templates for Shell and Module projects, as well as ‘QuickStart Solution’ templates that provide a complete, pre-configured, multi-module solution that you can use as a starting point for a complete Prism application. All templates are available for both WPF and Silverlight. They are all in C# at the moment. I’ll work on VB.NET versions soon…

I’ve modified the templates a little to use some of the features that have been introduced since Silverlight 2.0. In particular, I updated the QuickStart Solution to use the Silverlight PagedCollectionView class so that the ViewModel can keep track of the current selection automatically.

The biggest change, though, is that the templates now come in a VSIX package and use the Visual Studio 2010 Extension Manager. This dramatically simplifies the installation and management of the templates!! You can download the VSIX package here – note that you will have to change the file extension from .zip to .vsix in order to install it – or you can find it in the Visual Studio Code Gallery. You can also read the Getting Started release notes here.

You can install the VSIX package by simply double-clicking it (once you’ve changed the file extension to .vsix). You’ll be prompted to accept the license but two clicks is pretty much all it takes. When you run Visual Studio 2010 and open the Extension Manager (from the Tools menu) you’ll see the Prism Template Pack is installed. You can uninstall it or disable it from here too.

The templates show up in the Visual Studio 2010 New Project dialog under the Prism category. There are Shell and Module project templates, as well as the QuickStart Solution templates, for Silverlight and WPF.

Once you’ve created a project using the templates, a ReadMe file will be shown that details the remaining steps you will need to take before the solution will compile and run. This mainly involves updating the project’s references to point to the Prism assemblies on your system. In some cases, you might also have to add Silverlight App References to the Web project so that the projects are linked together properly. I haven’t yet figured out how to do this automatically without requiring some kind of complicated Visual Studio automation but I’m still working on it…

These templates target the Release Candidate versions of Visual Studio 2010, and WPF and Silverlight 4.0. Once they are fully released, I will update the templates with any changes that are required. I’m also hoping that templates like these will be included ‘in the box’ for Prism 4.0.

In the meantime, I hope you find them useful. Let me know what you think!

• Can I use Prism for WPF/Silverlight 4.0 development?
• What’s going to be in Prism 4.0?

To answer the first question we’ve started to test Prism 2.1 against the Release Candidates of WPF 4.0 and Silverlight 4.0. Apart from a couple of very minor things in the Reference Implementation and some of the unit tests, we’ve found no issues with using Prism 2.1 for WPF 4.0 and Silverlight 4.0 development. Once .NET 4.0 and Silverlight 4.0 are released, we’ll complete our testing and release an updated version of Prism (which we’ll probably call Prism 2.2). This is an interim release to allow folks to continue to use Prism when targeting the latest and greatest versions of WPF and Silverlight.

In the meantime, we’re going to start work on the next version of Prism (which we’re going to call Prism 4.0) with a target release date around September 2010. As you know, we run a pretty agile ship here in patterns & practices, and we rely heavily on the community to help us guide our projects as we go along. What this means is that we won’t know exactly what’s going to be in Prism 4.0 until we ship it, but of course we do have a pretty good idea on the technical areas that we’d like to address.

For Prism 4.0 the four key technical areas that we’d like to cover are:

• Managed Extensibility Framework (MEF) Integration
• Extended Support for Model-View-ViewModel (MVVM)
• Data Access & Application Services
• Design-Time Support

The post provides much more detail on each of these areas. We’re looking to you folks to help us prioritize which aspects of these areas we should focus on. If you’d like to get involved, make sure you visit the Prism CodePlex site regularly and let us know what you think. We’ll be dropping code and updates there often once the project gets underway next month.

The Silverlight 3.0 navigation framework has some very interesting capabilities, but it does have some limitations too. One of these limitations is that all of the pages that can be navigated to have to be defined in the application’s primary XAP file. For composite applications, that typically consist of multiple XAP files, this has proven to be quite a problem. Various workarounds have been proposed but they are all pretty clunky. The underlying problem is that the Silverlight 3.0 navigation framework doesn’t provide any extensibility hooks to implement this capability properly.

The Good News

Happily, this is about to change in Silverlight 4.0, which will allow you to specify a Content Loader for each Frame instance:

   1: myFrame.ContentLoader = new CustomContentLoader();

The content loader is responsible for loading whatever content is associated with the target Uri. By giving folks the ability to create custom content loaders of their own, Silverlight 4.0’s navigation framework opens up some very interesting extensibility options. A custom content loader, for example, can remove the need for clunky shims and pass-through loader pages when navigating to pages located in other XAP files. They can also allow you to use navigation Uri’s which don’t necessarily have to map directly to UI content, or allow you to control the target page’s construction (so you can hook up it’s ViewModel), etc.

The Bad News

There is a rather large drawback with custom content loaders though: they are executed asynchronously. This makes them quite tricky to implement. A custom content loader implements the INavigationContentLoader interface which includes Begin and End methods and uses an IAsyncResult object to coordinate the asynchronous interaction between the Frame and the content loading logic. This asynchronous call pattern is known as the .NET Asynchronous Programming Model (APM). It’s notoriously tricky to implement properly – not least of which because you have to account for the 3 or 4 ways in which the caller can execute the call, and you have to handle exceptions, cancellations and wait handles very carefully.

So why is navigation executed asynchronously you may ask. That’s a very good question! I was involved in the early design discussions for the Silverlight navigation framework and argued against an asynchronous model for a couple of reasons. My main argument was that navigation invariably means you have to construct the new UI to which you’re navigating, and this has to happen synchronously on the UI thread. My other argument  was to do with user experience – more on this later.

Ah, yes, (so the counter-argument went) but what happens if you want to download some content/data from the host web site, or make a web service call, or load data from a database, or maybe do some complex calculation – you can’t tie up the UI thread! These are all valid things to do in an application of course, just not within the navigation operation itself!!! Apart from anything else, these are pretty advanced scenarios and by far the majority of navigation scenarios will just involve mapping Uri’s to UI content which just needs to be loaded (on the UI thread!!). In addition, all of these scenarios can be achieved fairly easily on top of a synchronous navigation model, and in a way that makes for a better user experience too.

Ok, rant over. I feel much better now :-) INavigationContentLoader is what it is. The Silverlight folks have worked hard to open up the navigation framework a little and given us a key extensibility point. We just have to try and leverage it as best we can…

So, in this post I’ll describe the implementation of a base class (ContentLoaderBase) that can be used to easily implement custom content loaders in Silverlight 4.0. You can use this base class to implement any number of different content loaders, including synchronous content loaders or asynchronous content loaders that download content in the background or that use a background thread for background processing. Hopefully this base class will provide you with a reasonable starting point for implementing whatever type of content loader you need in your application. At the end of this post I’ll talk briefly about how the ContentLoaderBase base class works.

You can download the sample code here.

It’s built on Visual Studio 2010 Beta 2 and Silverlight 4.0 Beta. The sample shows how to configure and use various synchronous and asynchronous content loaders and their effect on navigation. You can switch between the sample content loaders in MainPage.xaml.cs.

Implementing a Synchronous Content Loader

The ContentLoaderBase base class provides a small number of virtual methods. You can implement a synchronous or an asynchronous custom content loader simply by overriding the right methods. In the simple (and most common) case of an synchronous content loader, you simply need to override a single method – LoadContentSync – which looks like this:

   1: protected override object LoadContentSync( Uri targetUri,

   2:                                            Uri currentUri )

   3: {

   4:     return new ControlOrPage();

   5: }

In this method you simply create or load whatever UI content you need based on the new (and maybe the current) Uri. You can do this in any number of ways – using a switch statement or using a lookup table for example. The important thing to note is that this method is called on the UI thread so you don’t have to worry about creating UI content or making cross-thread calls.

Of course, since the call is made on the UI thread, you shouldn’t do crazy things like make a network call or do a lengthy calculation in this method. If you need to do anything like that then you may need an asynchronous content loader (though I’ll argue later that even if you do need to do anything like this you shouldn’t do it during navigation). In the meantime here’s how you can do it using the ContentLoaderBase class…

Implementing an Asynchronous Content Loader

You can implement an asynchronous content using the ContentLoaderBase class by overriding two virtual methods (and implementing one or two callbacks). The first method to override is the GetLoadBehavior method which defines whether the navigation operation for a particular Uri is synchronous or asynchronous (the default value is synchronous which is why we didn’t need to override this method in the synchronous case above).

   1: protected override LoadBehavior GetLoadBehavior( Uri targetUri )

   2: {

   3:     // Content is loaded asynchronously for all Uris.

   4:     return LoadBehavior.Asynchronous;

   5: }

In this example, navigation for all Uri’s is asynchronous, though we could of course have some Uri’s handled synchronously and some handled asynchronously (which is useful when, for example, we’ve cached content that was previously downloaded asynchronously so that subsequent navigations can be handled synchronously).

The other method you need to override is the LoadContentAsync method. This is where you initiate whatever asynchronous operation you need. When that operation is completed, you simply need to call the LoadContentAsyncComplete method in the base class to complete the navigation operation.

   1: protected override void LoadContentAsync(

   2:                     ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Initiate asynchronous operation here...

   5:  

   6:     // When the asynchronous operation is completed, call the

   7:     // LoadContentAsyncComplete method on the base class to

   8:     // complete the navigation operation.

   9: }

Broadly speaking, there are two types of asynchronous operations that you might want to do when loading content during a navigation operation. The first involves downloading some form of content, data or configuration from the host web site. The second involves performing some form of processing or calculation on a background thread.

Either way, once the async operation is completed you will still need to load or create the actual UI content to which you’re navigating on the UI thread. The way you do that in each of these two scenarios are slightly different and may require you to implement one or more callbacks. Let’s look at each of these scenarios in turn…

Downloading Content During Navigation

Retrieving or sending data from the host web site is a common scenario in Silverlight. The Silverlight WebClient class makes this fairly straightforward by providing an asynchronous event-based callback mechanism – you can start the download or upload process and the WebClient class will call you back when its complete. They key feature of this class is that the callback happens on the UI thread, which in turn means that you don’t have to worry about cross-thread UI access. It’s a pity that the navigation framework didn’t adopt the same event-driven approach… Ho hum…

To use the WebClient class in a content loader, we simply need to start a download process (or whatever we need) in the LoadContentAsync method and specify a callback method. Since the callback method is called on the UI thread we can load or create whatever UI content we need there. The completed sample looks something like this:

   1: protected override void LoadContentAsync(

   2:                             ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Use the WebClient class to download a file from the

   5:     // web server. This is an asynchronous method call and

   6:     // will return immediately.

   7:     webClient.OpenReadAsync(

   8:                 new Uri( "NavigationData.xml", UriKind.Relative ),

   9:                 asyncResult );

  10: }

  11:  

  12: private void OnOpenReadCompleted( Object sender,

  13:                                   OpenReadCompletedEventArgs e )

  14: {

  15:     ContentLoaderAsyncResult asyncResult =

  16:                     (ContentLoaderAsyncResult)e.UserState;

  17:  

  18:     // Since the WebClient callback is on the UI thread,

  19:     // we can create the UI we're navigating to here.

  20:     Object content = new ControlOrPage();

  21:  

  22:     // Inform the base class that the async request has

  23:     // been completed.

  24:     base.LoadContentAsyncComplete( content, asyncResult );

  25: }

Notice how the UI content  that was created in the callback method is passed back to the base class via the LoadContentAsyncComplete method call. The base class then completes the asynchronous navigation operation and passes the content to the Frame.

Background Processing During Navigation

The other scenario where you might want to use an asynchronous content loader is where you want to use a background thread to perform some kind of calculation or background process. In this case, the LoadContentAsync method might look something like this:

   1: protected override void LoadContentAsync(

   2:                             ContentLoaderAsyncResult asyncResult )

   3: {

   4:     // Use the thread pool to queue up a background operation.

   5:     ThreadPool.QueueUserWorkItem( BackgroundTask, asyncResult );

   6: }

Where BackgroundTask is the method that defines the background process. This method will of course be called on the background thread, not the UI thread, so when the calculation is finished how do we load the UI content that we need to navigate to? To do that, when we inform the base class that the calculation has finished, we provide another callback. The base class makes sure that this callback will be called on the UI thread so we can load our UI content there. The completed sample looks something like this:

   1: private void BackgroundTask( Object state )

   2: {

   3:     ContentLoaderAsyncResult asyncResult =

   4:                 (ContentLoaderAsyncResult)state;

   5:  

   6:     // Simulate some lengthy calculation or process.

   7:     Thread.Sleep( 4000 );

   8:  

   9:     // We can't create the necessary UI content

  10:     // here because we're on a background thread.

  11:     // So we create the UI in a callback method.

  12:     // The base class will call the callback on the UI thread.

  13:     base.LoadContentAsyncComplete( LoadContentUICallback,

  14:                                    asyncResult, asyncResult );

  15: }

  16:  

  17: private Object LoadContentUICallback( Object callbackState )

  18: {

  19:     Debug.WriteLine( "LoadContentUICallback" );

  20:  

  21:     ContentLoaderAsyncResult asyncResult =

  22:                 (ContentLoaderAsyncResult)callbackState;

  23:  

  24:     // Since THIS callback is on the UI thread, we can

  25:     // create the UI we're navigating to here.

  26:     return new ControlOrPage();

  27: }

TODO: Cancelation

The above code snippets are simplified a little to show you the essentials. If you have an asynchronous content loader you will find that a navigation operation will often be canceled. To implement an asynchronous content loader properly you will therefore have to account for cancelation.

Why is navigation canceled so often? Because the navigation framework does not provide any built-in mechanism to give feedback to the user during an asynchronous navigation operation. Since the user expects navigation to be instantaneous, they have a tendency to click the navigate button or hyperlink control multiple times, and each time they do, the previous navigation operation will be cancelled. So it’s very important to handle cancellations properly, otherwise you can easily run into tricky-to-handle exceptions during navigation. The irony of course, is that asynchronous navigation was meant to improve the user experience…

To illustrate the effects of network latency or lengthy processing during navigation, the sample code includes artificial delays. For the download sample, a HTTP handler is used to introduce an artificial delay during the download of the dummy file. Similarly, the background thread sample includes a 3 second Thread.Sleep in the background task method.

When navigation is asynchronous, you’ll quickly notice that clicking on the navigation links during an existing navigation operation will cause the previous navigation operation to be canceled. The sample code shows how you might handle this situation but there are some complications that have not yet been ironed out (see the comments in the code for more details). In the download case you will need to somehow cancel the previous download operation. In the background thread case you will have to find a way to abort or cancel the calculation or background process gracefully if navigation is cancelled…

ContentLoaderBase Class Implementation Details

The key to the ContentLoaderBase Class is the object that implements the IAsyncResult interface. For that I leveraged the excellent coding skills of Jeffery Richter and his MSDN magazine article (here) from a few years back. That article and the accompanying code, describes many of the subtle details that you have to worry about when implementing the APM. With the IAsycnResult object implemented properly, the ContentLoaderBase class ‘simply’ has to make sure that the right virtual methods are called in the right order and that the LoadContentUICallback is executed on the UI thread.

An Easier Approach

The ContentLoaderBase class simplifies things quite a bit, especially when implementing a synchronous content loader. But I think you can probably see that asynchronous content loaders are still a little complicated to implement properly. I’m sure that I have not even begun to iron out all of the subtle issues that inevitably show up when you’re doing anything asynchronously (e.g. cancelation as noted above).

For reasons of complexity, plus the bad user experience that can result, I would recommend using only synchronous content loaders wherever possible. But what about those situations where you absolutely need to download or calculate something during navigation? My advice is to do these things outside of the navigation framework and to do them in the target page itself.

So for example, for the two scenarios above, you would navigate to a page (synchronously) that will then download the content or perform the calculation (in its ViewModel of course). Furthermore, while the page is downloading the content or performing the calculation, it can provide visual feedback to the user! To the user, the navigation is instantaneous, even though the target page might take a while to initialize itself. By providing visual feedback while this happens you will likely prevent the user from getting frustrated and repeatedly clicking the navigate button or link.

I’ll explore this approach, plus some other interesting things you can do with a custom content loader, in a future post…

First of all, it’s important to note that Prism and MEF are very much complementary technologies. MEF allows you to create extensible applications by providing support for automatic component discovery and composition. It does not focus on application- or UI-level patterns or on any specific UI technology. Prism on the other hand provides support for creating modular composite client applications built on Silverlight and/or WPF. As such it supports a wide range of patterns including the higher level UI patterns and concepts that are need to support composite clients – such as modularity, module deployment, loosely coupled communication, commanding, and separated presentation patterns such as Model-View-ViewModel, etc.

There is clearly some overlap between MEF and Prism (since modular composite client applications are by definition extensible!!) but MEF by itself in no way replaces or obviates the need for Prism – they are each targeted at different parts of the overall puzzle. MEF in fact is fantastic news for Prism, because it means that we can now leverage core capabilities that are provided by the .NET Framework, whereas in the past we’ve had to build those capabilities as part of Prism itself.

Prism 4.0

In the next version of Prism (Prism 4.0) we’ll be focusing on leveraging MEF as much as possible and ensuring that Prism and MEF work seamlessly together. We’ll be kicking off the Prism 4.0 project early next year and, as always, we’ll be providing drops every two weeks during development so you’ll be able to provide feedback and direct the scope and focus of the project as we go. But since MEF integration is likely be one of the first things that we’ll tackle, I think it’s worth describing our current thinking on how we think Prism can leverage MEF and how they can complement each other so that you can provide feedback to us before we start. In the rest of this post I’ll outline a couple of the areas where I think MEF and Prism can be closely integrated. Let me know what you think.

Component Composition

Firstly, let’s talk about component composition. Prism uses the Dependency Injection pattern (DI) quite extensively because it helps to maintain loose coupling between the various components in an application. I’m not going to get into the “is MEF a DI container or isn’t it” discussion here :-) but suffice it to say that there are similarities and differences between the way MEF works and the way that typical Dependency Injection containers work. The upshot is that there are things that MEF does well and there are things that DI containers do well, but the important thing is that both MEF and DI containers promote loose coupling between components, which is a very good thing.

In the Prism 2.0 Quick Starts and the Reference Implementation we use the Unity Application Block as our DI container of choice. However, it’s important to note that the Prism code libraries themselves do NOT depend explicitly on Unity, or in fact on any specific DI container implementation. This is an important point. It was an explicit design decision to allow the use of any other DI container (such as CastleWindsor, StructureMap, AutoFac, Ninject, etc) or the use of any other kind of component composition strategy that suites your needs – such as the component composition strategy supported by MEF!

So the design of Prism allows you to use MEF with Prism 2.0 today, even though Prism 2.0 was shipped early this year way before MEF was broadly available. It’s pretty easy to use MEF instead of a DI container within a Prism module to help you wire up Views, ViewModels, Controllers, or Presenters, or to get references to EventAggregator or RegionManager instances provided by the Shell. In fact, using MEF like this can actually simplify the code somewhat since it can automatically discover available types without you having to register them explicitly with the DI container. You can also use MEF’s meta-data support to do conditional component composition. We’ll be exploring and providing guidance for these scenarios in Prism 4.0.

Another interesting possibility is to use both MEF and a DI container together in the same application. There are some advantages to this since it allows you to leverage the strengths of each in various situations. In fact, Unity 2.0 (which is currently in development as part of EntLib 5.0) will support the hybrid use of MEF and a DI container and make it seamless and straightforward. In Prism 4.0, we’ll be exploring and providing guidance for the use of MEF + DI container hybrid approaches in the context of composite client application development.

Catalogs and Modules

The use of MEF and/or DI container to help with component composition is pretty straightforward, and largely independent of the higher level constructs and patterns in Prism. But one area where the overlap between MEF and these higher level Prism concepts is not quite as clear cut is in the area of Catalogs and Modules. This area has caused some confusion in part because of overlapping terminology and, in some cases, because of the similar concepts applied at different levels of granularity.

To recap, Prism uses the notion of a module to represent a collection of features, components, and resources that make up a functional unit within the application. Prism modules can be developed, tested and deployed independently. They frequently consist of multiple assemblies and other resources packaged up into an easily deployable unit (for example in a XAP file). Prism provides infrastructure for the flexible deployment of modules. In the case of Silverlight, for example, modules can be downloaded with the core application, or can be downloaded in the background or on-demand.

Prism applications use a module catalog to tell it which modules to load. Module catalogs can be static (i.e. the list of modules is predetermined before run-time) or dynamic (i.e. the list of modules is determined at run-time and can take into account the user’s ID, role, configuration, installed modules, wind direction, etc). Dynamic module catalogs can be used to extend an application after its initial deployment. They can be implemented in many different ways. For example, you can build a dynamic catalog by reading a (local or remote) config file, or by using a web service that specifies the modules to load, or by scanning a particular folder to see what modules have been installed.

Once a module is loaded, Prism looks for an entry type that supports the IModule interface. This interface has only one method – Initialize – and can be used to provide any initialization logic that the module provides. Typically, this method is used to register types within the module with the DI container so that they can be accessed by other modules and the shell. Another common use of this method is to register Views contained within the module with UI regions. The module can do anything it needs to though, including kicking off background threads, making web service calls or downloading additional data or resources. Of course, you don’t have to provide any initialization logic if your module doesn’t require it.

Now, MEF too has the concept of a component catalog. When you import a type in MEF (i.e. you’ve expressed a dependency in one class to another class of a certain type), its resolves that type by looking in the MEF catalog which defines all of the types that are available for export (i.e. types that can be used by MEF to satisfy imports). This is a very powerful feature of MEF and allows you to express dependencies between components and have them fulfilled for you pretty much automatically, without having to explicitly register types with a DI container or having to resort to closely-coupled techniques like ‘new’ or CreateInstance. Note, I say ‘type’ here to keep things simple but MEF generalizes the relationship between importer and exporter using contracts, but contracts most often equate to types, and types can be interfaces.

So Prism module catalogs are really not the same as MEF catalogs since they’re specifying things at completely different levels of granularity. In addition, MEF does not provide any support for the packaging or conditional deployment of functional units within an application. However, there is clearly some overlap here since, at a lower level, Prism modules essentially contain a bunch of components that can import and export types so that they can be hooked up to components from other modules or the shell.

You can imagine using both Prism module catalogs and MEF catalogs together. The key here I think is for Prism to focus on the packaging, deployment and activation of coarse grained functional units (modules), as defined by either a static or dynamic module catalog, and to use MEF to support the flexible, meta-data driven composition of components within and across modules and the shell.

For example, imagine using Prism to build modules that represent functional units within an application and having it take care of their packaging and deployment via a dynamic or static module catalog. As each Prism module is loaded, the component dependencies within it (i.e. imports and exports) can be made available to MEF for component composition. In a sense, each module represents a catalog of components that MEF can use to fulfill and resolve component dependencies. There are other possibilities I am sure, and we’ll be exploring these as part of Prism 4.0…

Prism 4.0 Needs You!

Our goal for Prism 4.0 is to leverage MEF, and other .NET 4.0 and Silverlight 4.0 features, as much as possible so that we can provide a flexible and powerful environment for building modular, composite client applications on WPF and Silverlight 4.0. MEF is an exciting new technology and it’s great to see some level of support for loosely coupled component composition finally make it into the .NET Framework. I’m looking forward to exploring the possibilities here and I think it’s going to be pretty cool…

As well as MEF integration, for Prism 4.0 we’re looking at also providing more guidance on the ViewModel pattern, navigation, out of browser applications, developer/designer workflow, user experience patterns, visual studio templates, and a whole host of other areas. Which ones we tackle will depend on you, so as always, if you have any ideas or feedback, please let us know!