Navigation-driven Silverlight applications tend to share some common pieces of UI.  Traditionally, this has required sprinkling HyperlinkButtons throughout the application’s XAML.  For ASP.NET a number of controls intended to drive navigation exist.  These controls are driven by a sitemap, integrate well with authorization and roles (through sitemap trimming), and provide common user experiences around hierarchical application structures such as a TreeView-based list of hyperlinks and Breadcrumbs or navigation paths.  These controls provide the user with context as to where in the application/site they currently are as well as where within the application they can go.

In this post, I’ll introduce a few controls that attempt to mimic this behavior in a Navigation-driven Silverlight application.  I have added these controls to SLaB, and you’re welcome to use and modify them – or use them as examples for your own development – as you see fit.  The controls are:

• TreeViewNavigator – a control which represents a sitemap as a TreeView

• BreadCrumbNavigator – a control which represents your current location within the sitemap’s link hierarchy and allows navigation back up the hierarchy as well as to siblings of any node within the hierarchy

If you’ve been following the evolution of my sample projects, you may have noticed some navigation UI that’s not built into the default navigation application template and has controls that look like the ones I’ve described above.  Surprise, surprise!   You can see this in action here.

How does this type of UI work?

At its core, these controls have the same common set of functionality:

• Rendering UI based on a sitemap
• Keeping UI synchronized with the current page within the application
• Trimming the sitemap based upon the roles the current user belongs to and the metadata in the sitemap

The goal of these controls is to allow the navigation structure of an application to be exposed to a user in a declarative fashion, much as one can do using ASP.NET sitemaps.  The API for the controls above uses Sitemaps that can be specified in XAML, but follow the same general structure as in ASP.NET.

For example, the sitemaps displayed above are produced by the following XAML:

    <SLaB:Sitemap x:Key="Sitemap"
                  Title="DavidPoll.com"
                  Description="My homepage.  Check it out and see what it's all about!">
        <SLaB:SitemapNode TargetName="ContentFrame"
                          Title="Home"
                          Description="The home page."
                          Uri="/Views/Home.xaml" />
        <SLaB:SitemapNode Title="SLaB Features"
                          Description="Demonstrations of Silverlight and Beyond features.">
            <SLaB:SitemapNode Title="Navigation">
                <SLaB:SitemapNode Title="Local Pages">
                    <SLaB:SitemapNode TargetName="ContentFrame"
                                      Title="About"
                                      Description="The about page."
                                      Roles="Foo"
                                      Uri="/Views/About.xaml" />
                    <SLaB:SitemapNode TargetName="ContentFrame"
                                      Title="A broken link"
                                      Uri="/Views/NonExistent.xaml" />
                </SLaB:SitemapNode>
                <SLaB:SitemapNode Title="On-Demand Xaps"
                                  Description="Pages in Xaps that will be loaded on-demand."
                                  TargetName="ContentFrame"
                                  Uri="/Views/SitemapPage.xaml?sitemapname=OnDemandSitemap">
                    <SLaB:SitemapNode Title="This Domain">
                        <SLaB:SitemapNode TargetName="ContentFrame"
                                          Title="Page in a big xap"
                                          Uri="pack://siteoforigin:,,SecondaryXap.xap/SecondaryXap;component/Page1.xaml" />
                        <SLaB:SitemapNode TargetName="ContentFrame"
                                          Title="Awesome Page"
                                          Uri="pack://siteoforigin:,,TernaryXap.xap/TernaryXap;component/AwesomePage.xaml" />
                        <SLaB:SitemapNode TargetName="ContentFrame"
                                          Title="Penguins (mapped Uri + metadata)"
                                          Uri="/remote/TernaryXap/AwesomePage.xaml?Site=http://www.davidpoll.com&amp;First Name=David&amp;Last Name=Poll&amp;Title=Penguins!&amp;Please rate..." />
                    </SLaB:SitemapNode>
                    <SLaB:SitemapNode Title="Cross-Domain">
                        <SLaB:SitemapNode TargetName="ContentFrame"
                                          Title="http://open.depoll.com Page"
                                          Uri="pack://http:,,open.depoll.com,SimpleApplication,SimpleApplication.xap/SimpleApplication;component/Depoll.xaml?Source=http://open.depoll.com&amp;File=wildlife.wmv" />
                    </SLaB:SitemapNode>
                </SLaB:SitemapNode>
                <SLaB:SitemapNode Title="Printing"
                                  Description="Pages that demonstrate printing utilities that simplify pagination of data and printing of complex data sets."
                                  TargetName="ContentFrame"
                                  Uri="/Views/SitemapPage.xaml?sitemapname=PrintingSitemap">
                    <SLaB:SitemapNode Title="Collection Printing (DataGrid)"
                                      Uri="pack://siteoforigin:,,ScratchPrintingProject.xap/ScratchPrintingProject;component/PrintingPage.xaml"
                                      TargetName="ContentFrame" />
                    <SLaB:SitemapNode Title="Collection Printing (Template-based)"
                                      Uri="pack://siteoforigin:,,ScratchPrintingProject.xap/ScratchPrintingProject;component/ItemTemplatePrinting.xaml"
                                      TargetName="ContentFrame" />
                    <SLaB:SitemapNode Title="Pre-defined page printing (Template-based)"
                                      Uri="pack://siteoforigin:,,ScratchPrintingProject.xap/ScratchPrintingProject;component/PredefinedPages.xaml"
                                      TargetName="ContentFrame" />
                </SLaB:SitemapNode>
                <SLaB:SitemapNode Title="Useful XAML Tools">
                    <SLaB:SitemapNode TargetName="ContentFrame"
                                      Title="Demo (simple QueryString)"
                                      Uri="/Views/ObservableDictionaryDemo.xaml?a=b&amp;c=d&amp;e=f&amp;g=h" />
                    <SLaB:SitemapNode TargetName="ContentFrame"
                                      Title="Demo (more complex QueryString)"
                                      Uri="/Views/ObservableDictionaryDemo.xaml?a=b&amp;Name=David Eitan Poll&amp;Url=http://www.davidpoll.com&amp;No Value&amp;Order=Dictionary" />
                </SLaB:SitemapNode>
            </SLaB:SitemapNode>
            <SLaB:SitemapNode Title="DavidPoll.com">
                <SLaB:SitemapNode TargetName="_blank"
                                  Title="Home Page"
                                  Uri="http://www.davidpoll.com" />
                <SLaB:SitemapNode TargetName="_blank"
                                  Title="Navigation Posts"
                                  Uri="http://www.davidpoll.com/tag/navigation/" />
                <SLaB:SitemapNode TargetName="_blank"
                                  Title="SLaB Posts"
                                  Uri="http://www.davidpoll.com/tag/silverlight-and-beyond-slab/" />
                <SLaB:SitemapNode TargetName="_blank"
                                  Title="SLaB Download Page"
                                  Uri="http://www.davidpoll.com/downloads-and-samples/#SLaB" />
            </SLaB:SitemapNode>
        </SLaB:SitemapNode>
    </SLaB:Sitemap>

You’ll note that the “About” link in the Sitemap above (bold/italic above) is missing from the TreeView.  This is because the sitemaps do principal-based trimming of the sitemaps, ensuring that users only see the links they’re authorized to see. 

In addition, the controls above stay in sync with the current page the user is viewing.

To get all of this functionality, there are three primary properties to set on the navigation controls (which derive from the Navigator abstract base class for this common functionality):

• Sitemap – usually, this is set to a Sitemap that is defined in resources somewhere, and may be shared across multiple navigation controls.
• CurrentSource – if the navigation control needs to stay in sync with the user’s current location (which is not always the case – e.g. on Error/404-ish pages), bind it to the CurrentSource of the Frame that it will be navigating
• Principal – if the navigation control should trim the sitemap based upon the User’s authorization, bind the Principal to be that of the current user.  In the case of RIA Services, this can be done through the WebContext

Ultimately, using these controls just requires some simple XAML.  For the TreeViewNavigator:

<SLaB:TreeViewNavigator CurrentSource="{Binding ElementName=ContentFrame, Path=CurrentSource}"
                        Principal="{Binding User, Source={StaticResource WebContext}}"
                        Sitemap="{StaticResource Sitemap}" />

And for the BreadCrumbNavigator:

<SLaB:BreadCrumbNavigator CurrentSource="{Binding CurrentSource, ElementName=ContentFrame}"
                          Principal="{Binding User, Source={StaticResource WebContext}}"
                          Sitemap="{StaticResource Sitemap}" />

What can I customize?

These controls are made to work with any ISitemap, which is, at its core, a container for a collection of ISitemapNodes.  You can provide custom implementations of these, customizing your sitemaps to your heart’s content!  For example, you might make sitemaps and sitemap nodes which:

• Retrieve their data from an ASP.NET xml-based sitemap file
• Authorize users for access to nodes based upon more than just roles
• Check authorization based on metadata on the page type itself, or by using a NavigationAuthorizer from the AuthContentLoader library
• Import one sitemap into another (I’ve actually provided an implementation of this in SLaB so that sitemaps and sub-sitemaps can be used)

Furthermore, the controls themselves are look-less, and you should be able to completely re-template them, customizing how hyperlinks are displayed, how much of the tree is expanded, and so on.  If there’s something I’m missing, let me know!

So, can I see it in action?

Of course!  You know I never leave you without a demo!  In fact, today I’ve got two for you!

First, the SLaB demo application itself uses these controls.  Click around and see how things behave.  You’ll notice the controls are the centerpiece of the navigation UI, but also make appearances throughout the application, such as on “category pages” that list only the links within a particular section of the site, and on error pages within the application, making it easier for users to get back to useful locations within the application.

The second demo application is meant to show role-driven sitemap trimming.  It uses WCF RIA Services to drive authentication and authorization, and shows and hides parts of the sitemap based upon the roles the user belongs to.  You can log in using the following credentials:

User: Test

Password: _Testing

Experiment with the application and what happens to the navigation controls as you log in and log out.  This also uses the AuthContentLoader from SLaB to perform additional authorization before actually loading any page.

The XAML for the sitemap in the application above shows how access can be restricted and how trimming takes effect:

<SLaB:Sitemap x:Key="Sitemap"
                Title="Scratch Business Application"
                Description="A sample RIA Services Business application that uses SLaB to represent its navigation and do authorization.">
    <SLaB:SitemapNode Title="Home"
                        Description="The home page for the application"
                        Uri="/Views/Home.xaml" />
    <SLaB:SitemapNode Title="Broken Link"
                        Description="A broken link"
                        Uri="/Views/NonExistentPage.xaml" />
    <SLaB:SitemapNode Title="Protected Pages (Non-Trimmed)"
                        Description="Pages protected by authorization">
        <SLaB:SitemapNode Title="About"
                            Description="The About page for the application"
                            Uri="/Views/About.xaml" />
        <SLaB:SitemapNode Title="Page for registered users"
                            Description="A page that can only be visited by registered users"
                            Uri="/Views/RegisteredUsersPage.xaml" />
    </SLaB:SitemapNode>
    <SLaB:SitemapNode Title="Protected Pages (Trimmed)"
                        Roles="Registered Users"
                        Description="Pages protected by authorization">
        <SLaB:SitemapNode Title="About"
                            Description="The About page for the application"
                            Uri="/Views/About.xaml?trimmed" />
        <SLaB:SitemapNode Title="Page for registered users"
                            Description="A page that can only be visited by registered users"
                            Uri="/Views/RegisteredUsersPage.xaml?trimmed" />
    </SLaB:SitemapNode>
    <SLaB:SitemapNode Title="Protected Pages (Leaf nodes trimmed)"
                        Description="Pages protected by authorization">
        <SLaB:SitemapNode Title="About"
                            Roles="Registered Users"
                            Description="The About page for the application"
                            Uri="/Views/About.xaml?leaftrimmed" />
        <SLaB:SitemapNode Title="Page for registered users"
                            Roles="Registered Users"
                            Description="A page that can only be visited by registered users"
                            Uri="/Views/RegisteredUsersPage.xaml?leaftrimmed" />
    </SLaB:SitemapNode>
    <SLaB:SitemapNode Title="DavidPoll.com"
                        Description="David Poll's homepage"
                        Uri="http://www.davidpoll.com"
                        TargetName="_blank" />
</SLaB:Sitemap>

Cool… but where are the bits?

Well, the good news is that you can get all of these controls in my Silverlight and Beyond (SLaB) libraries!  Give them a shot and let me know what you think.  What’s missing from these controls?  What other pieces of user experience are you looking for?  Are the behaviors of the TreeViewNavigator and BreadCrumbNavigator correct for your scenarios and desired UX?

With that said, here’s a summary of the links and access to the source!

At the beginning of the year, as part of a series of posts about the INavigationContentLoader extensibility point in Silverlight 4, I described a way to use a content loader to do authorization before allowing a user to navigate to a page.  With the content loader, you can either throw an exception when an unauthorized user tries to reach a protected Page, redirect your users to another Page, or return a different page (e.g. a Login page) in its stead.  This makes for a fairly nice experience for your users, wherein they are taken directly to a login page (or at least a page with more information about why they cannot access the given page) when they lack the credentials to reach the page they are requesting.

The trouble with this, however, was that once your application reached the login page and your user attempted to log in, there was no clear/easy/universal way to get the user back to the location he/she was originally requesting.  Ideally, an application would keep its context (i.e. the Uri wouldn’t change) when it sends a user to a login page, and take the user to the restricted content once the right credentials are acquired.

When I wrote my original post, I was aware of this limitation, and didn’t have a great solution for it.  Attempting to re-navigate to the requested page was unhelpful because navigating twice to the same Uri is a no-op.  Starting with the Silverlight 4 RC (and continuing into the RTW release, of course), however, such a solution exists!  We quietly added an API to Frame and NavigationService: Refresh().

How does refreshing help?

Calling Frame.Refresh() or NavigationService.Refresh() causes the entire page to be reloaded, meaning that a custom content loader will be called, providing an opportunity to return a different page (or redirect elsewhere).  Without having to make any changes to SLaB and the AuthContentLoader or ErrorPageLoader, we can now produce the desired experience!

Now, our ContentLoader XAML looks like this:

<navigation:Frame x:Name="ContentFrame"
                    Style="{StaticResource ContentFrameStyle}"
                    Source="/Home">
    <navigation:Frame.UriMapper>
        <uriMapper:UriMapper>
            <uriMapper:UriMapping Uri=""
                                    MappedUri="/Views/Home.xaml" />
            <uriMapper:UriMapping Uri="/{pageName}"
                                    MappedUri="/Views/{pageName}.xaml" />
        </uriMapper:UriMapper>
    </navigation:Frame.UriMapper>
    <navigation:Frame.ContentLoader>
        <SLaB:ErrorPageLoader>
            <SLaB:ErrorPage ExceptionType="UnauthorizedAccessException"
                            ErrorPageUri="/Views/LoginPage.xaml" />
            <SLaB:ErrorPage ErrorPageUri="/Views/ErrorPage.xaml" />
            <SLaB:ErrorPageLoader.ContentLoader>
                <SLaB:AuthContentLoader Principal="{Binding User, Source={StaticResource WebContext}}">
                    <SLaB:NavigationAuthorizer>
                        <SLaB:NavigationAuthRule UriPattern="^/Views/About\.xaml\??.*$">
                            <SLaB:Deny Users="?" />
                            <SLaB:Allow Users="*" />
                        </SLaB:NavigationAuthRule>
                        <SLaB:NavigationAuthRule UriPattern="^/Views/RegisteredUsersPage\.xaml\??.*$">
                            <SLaB:Allow Roles="Registered Users" />
                        </SLaB:NavigationAuthRule>
                    </SLaB:NavigationAuthorizer>
                </SLaB:AuthContentLoader>
            </SLaB:ErrorPageLoader.ContentLoader>
        </SLaB:ErrorPageLoader>
    </navigation:Frame.ContentLoader>
</navigation:Frame>

The primary difference between the XAML above and the original XAML I had posted was to remove the ErrorRedirector (which caused redirection to the login page rather than loading the login page in place of the requested page).  Because this was removed, we no longer need nested ErrorPageLoaders (which existed in order to redirect only in the login case, and load the error page without changing the Uri for other errors).  You’ll note that for the About page and the RegisteredUsers page, access is restricted.  When an UnauthorizedAccessException occurs, users will see the LoginPage.

In the login page, all we need to do now is call NavigationService.Refresh() when the user logs in.  My example uses WCF RIA Service’s WebContext find out this information, but you could just as easily attempt to refresh after a ChildWindow is closed or a Login button is clicked.

My LoginPage code looks like this:

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    WebContext.Current.Authentication.LoggedIn += Authentication_LoggedIn;
}

protected override void OnNavigatedFrom(NavigationEventArgs e)
{
    WebContext.Current.Authentication.LoggedIn -= Authentication_LoggedIn;
}

void Authentication_LoggedIn(object sender, AuthenticationEventArgs e)
{
    NavigationService.Refresh();
}

Yep, that’s all it takes!  Now, when a user logs in (either by clicking the login button on the page or logging in through some other dialog in the application), the Frame’s content is refreshed, and the AuthContentLoader attempts to verify the user’s credentials once again.

Cool!  Can I see it in action?

You know I would never leave you without a sample!  Click the image below to see the sample application (based on my original example, just updated for SL4).  First try navigating to the protected pages without logging in, then try logging in and note how the page automatically is refreshed based upon your new credentials.

Login information: Log in with User = “Test”, Password = “_Testing”

You can find the source for this application here.

Anything else I should know about Refresh()?

Without a doubt, Refresh()’s usefulness is not restricted to this scenario.  With custom content loaders, it’s particularly useful to be able to refresh the page, since the page returned as a result of that navigation may change from one attempt to the next.  Even without a custom content loader, Refresh() allows you to create a new instance of a page, making re-initializing the page you’ve navigated to clean and simple.  The behavior is identical to navigating to a new page – the only difference is that the old and new Uris are identical, and the NavigationMode of the operation is “Refresh”.

Please note: Refresh() will still respect the NavigationCacheMode of the Page and the CacheSize of the Frame.  If a Page is being cached, calling Refresh() will not create a new instance (but will still cause the Navigating/Navigated events and the corresponding overrides on Page to be raised/called).  To prevent this from happening, set the NavigationCacheMode of the page being refreshed to Disabled before the new page would be loaded (i.e. before Refresh() is called or while handling the Navigating event).

Is that it?

Yep, that’s it!   Let me know what you think!  What else would you like to see?

Way back in July, shortly after Silverlight 3 was released, I posted a technique that allowed you to use the Navigation framework in the SDK to load pages in dlls that would be downloaded as part of the navigation process.  The solution relied on two things: a workaround to the navigation framework’s inability to navigate to Pages in dynamically-loaded assemblies, and a derived version of the Frame class that hid many methods in order to orchestrate downloads of dlls and their dependencies.

With Silverlight 4’s INavigationContentLoader extensibility point, we can address this scenario much more effectively, and are no longer locked into the workarounds and strict constraints that Silverlight 3’s navigation feature placed on us.  In this post, I’ll walk through the use of another ContentLoader I’ve been working on and look at how it simplifies building multi-xap applications.

Getting a jump-start

If you’d like to get started quickly and see the magic of multi-xap applications, follow these steps (note: Requires the Silverlight 4 Beta and an active internet connection) or download the source for the steps below here (you may need to fix up the references after downloading SLaB):

1. Download and extract SLaB
2. Open Visual Studio 2010 and create a new Silverlight 4 project using the Silverlight Navigation Application template.  When prompted to create a corresponding ASP.NET web application, just click “OK” and let Visual Studio create a web project for you.
3. Add a reference to SLaB.Navigation.ContentLoaders.Xap.dll from the extracted Binaries folder.
4. Add the following line of code to App.xaml.cs: PackUriParser.Initialize();
5. Replace the Frame in MainPage.xaml with the following code (new code is bold/italic– the rest is identical to the default project xaml except for formatting):

<navigation:Frame x:Name="ContentFrame"
                  Style="{StaticResource ContentFrameStyle}"
                  Source="/Home"
                  Navigated="ContentFrame_Navigated"
                  NavigationFailed="ContentFrame_NavigationFailed">
    <navigation:Frame.UriMapper>
        <uriMapper:UriMapper>
            <uriMapper:UriMapping Uri=""
                                  MappedUri="/Views/Home.xaml" />
            <uriMapper:UriMapping Uri="/{pageName}"
                                  MappedUri="/Views/{pageName}.xaml" />
        </uriMapper:UriMapper>
    </navigation:Frame.UriMapper>
    <navigation:Frame.ContentLoader>
        <SLaB:XapContentLoader xmlns:SLaB="clr-namespace:SLaB.Navigation.ContentLoaders.Xap;assembly=SLaB.Navigation.ContentLoaders.Xap"
                               EnableCrossDomain="True" />
    </navigation:Frame.ContentLoader>
</navigation:Frame>

6. Run the application.
7. Replace “#/Home” in your browser’s address bar with “#pack://http:,,open.depoll.com,SimpleApplication,SimpleApplication.xap/SimpleApplication;component/Depoll.xaml?Source=http://open.depoll.com&File=wildlife.wmv”
8. Wait for a moment, and then enjoy the (admittedly underwhelming) show!

Whoa, what just happened?!

You just created an application that loaded a page in another xap!  It took only two actions to make this happen: registering the “PackUriParser” and setting the Frame’s ContentLoader to a XapContentLoader with cross-domain access enabled.  When you added the “pack://…” to the browser’s address bar, you told the content loader to downlaod a xap at http://open.depoll.com/SimpleApplication/SimpleApplication.xap (which is on my personal site, and has a very permissive cross-domain policy) and load the page “Depoll.xaml”.

The XapContentLoader makes loading pages in other xaps (and reducing your download sizes) as easy as coming up with a URI that points to the page.  Read on to learn more about how to use the XapContentLoader and some of the problems associated with multi-xap applications.

Why load pages in external xaps?

This has always been a particularly interesting scenario to me.  The size of your application’s xap file can have a big impact on your users’ experience with your Silverlight application.  Since the entire xap and its dependencies (e.g. cached assemblies) must download before users can interact with your application, keeping the xap’s size small means users can start using your application sooner and are less likely to give up and click away.

Partitioning your application into smaller-sized chunks that download only when users attempt to access that piece of functionality can also save bandwidth (since users need not download parts of the application they won’t use).

The folks behind both MEF (Package catalogs) and Prism (Modules) have great libraries that help you accomplish this partitioning.  To me, navigation is a natural delineator of application functionality – Pages represent pieces of functionality your users can access, so triggering loading of other assemblies/xaps as part of navigation means that users will get the pieces of the application when they want to use them.

In this post, I will be outlining a XapContentLoader, which makes loading pages in other Xaps a 2-lines-of-code problem to solve.  I’ve added this ContentLoader and some related utilities to SLaB, so you can use it yourself or play with the code if you like!

XapLoader

The first component I needed to make this scenario work was a way to download and load xap files.  As such, I wrote a XapLoader utility.  The strategy I used for loading xaps was the following:

1. Download the xap
2. Read the AppManifest.xaml within the xap to locate the assemblies therein
3. Load all assemblies within the xap
4. Download zip files for the “ExtensionParts” within the AppManifest (used for the “cached assemblies” feature)
5. Load the assembly associated with each zip file

Why worry about ExtensionParts?  My hope is to use this feature to solve the shared dependency problem.  For example, the System.Windows.Controls.Data.dll file in the SDK (containing the DataGrid control) is a fairly large assembly (446 kb uncompressed).  I’d like to avoid having users download this assembly when the app first loads, so I partition my application into four xaps: Main.xap, Foo.xap, Bar.xap, and Baz.xap.  Foo.xap and Bar.xap both use the DataGrid control.  Since I have no guarantees about the order in which my users will access the application, I need to make sure both of those xaps have access to that assembly, so I partition my application as follows:

This is a bit painful, since now when I download both Foo.xap and Bar.xap, I’m forced to download System.Windows.Controls.Data.dll twice!  Instead, if I turn on the assembly caching feature introduced in Silverlight 3, I can get both Foo.xap and Bar.xap to point to the same System.Windows.Controls.Data.dll.  By taking it out of the actual xaps and making it a separate download, I need only download it once (in fact, the browser’s cache will take care of it for me!).  Now, my application is partitioned in this way:

And now I’ve effectively partitioned the application without keeping redundant libraries around that would increase the overall download size of the application.

My implementation allows you to do this (using the same mechanism as “assembly caching”), but has the following limitations:

• Cached assembly .zip files must contain only one assembly per zip.
• The name of the .zip file must be the same as the assembly name (replacing “.dll” with “.zip”)

This loader returns a “Xap” object, which has all of the loaded assemblies related with the xap, a “Manifest”, which contains the same data as the Deployment defined in AppManifest.xaml within the xap, and a means to get the original streams from which each assembly was loaded (for use in keeping local copies, if that’s what you’d like to do).  The XapContentLoader, described below, uses this loader to find and load xaps that would contain additional pages.

XapContentLoader

The XapContentLoader is an implementation of INavigationContentLoader that will download an external xap and load a page in one of its assemblies.  This content loader uses a slightly modified version of the pack uri scheme (which I’m probably abusing a bit here, but oh well ).  Technically, it only takes two lines of code/XAML to use the XapContentLoader:

First, add the following line to your Application’s startup code (usually in App.xaml.cs), which registers the pack uri scheme with the built-in Uri class, so that you can create pack Uris in code and XAML without having exceptions be thrown:

PackUriParser.Initialize();

Then, in XAML:

<navigation:Frame x:Name="ContentFrame"
                  Source="/Views/Home.xaml">
    <navigation:Frame.ContentLoader>
        <xapLoader:XapContentLoader />
    </navigation:Frame.ContentLoader>
</navigation:Frame>

And that’s it!  Alright, that’s all.  See you later…

…

…

…

Ok, ok, I won’t leave you hanging like that!  Let’s look at how you would now use this content loader to load a page in another xap.  First, a quick review of the pack uri scheme as I understand it:

pack://<authority>/<path>

There are three parts to this Uri:

• “pack://” – this is the scheme name of the Uri.  All absolute pack Uris begin with this.
• “<authority>” – this is actually another Uri (just replace “/” with “,” and escape any other necessary characters).  For the XapContentLoader, this is a path to some xap.  For example, I might use the following authority: “http:,,www.davidpoll.com,xaps,MyApplication.xap”.  This indicates that I’ll be loading a page within the xap at that location.  I also support two other “special” authorities: “application:///” and “siteoforigin://”.  “application:///” cannot have an additional path attached to it, since I translate this as the location of the initial xap from which the application was loaded.  It’s basically equivalent to Application.Current.Host.Source.  “siteoforigin://” is replaced with the directory from which the application’s xap was loaded.  As such, any of the following authorities would be valid:
  • http:,,www.davidpoll.com,xaps,MyApplication.xap
  • https:,,www.davidpoll.com,securexaps,MySecureApplication.xap
  • application:,,,
  • siteoforigin:,,MyApplication.xap (equivalent to the first item in this list if MyApplication.xap was the entry point xap)
• “<path>” – this is the path within the xap.  Usually, this looks like: “/SomeLibrary;component/Views/Page1.xaml”.  If no assembly name is provided, I assume they are referring to the “EntryPointAssembly” referred to in the AppManifest.xaml file of the xap.

Some examples of valid Uris to navigate to (all equivalent assuming MyApplication.xap was the initial xap):

• /Views/Page1.xaml
• pack://application:,,,/Views/Page1.xaml
• pack://application:,,,/MyApplication;component/Views/Page1.xaml
• pack://http:,,www.davidpoll.com,xaps,MyApplication.xap/Views/Page1.xaml
• pack://http:,,www.davidpoll.com,xaps,MyApplication.xap/MyApplication;component/Views/Page1.xaml
• pack://siteoforigin:,,MyApplication.xap/Views/Page1.xaml
• pack://siteoforigin:,,MyApplication.xap/MyApplication;component/Views/Page1.xaml

Unfortunately, coming up with these Uris can be a bit of a pain, so I’ve provided a custom type of UriMapping that works on a per-xap basis to make this simpler:

<navigation:Frame.UriMapper>
    <navUtils:UriMapper>
        <xapLoader:PackUriMapping XapLocation="siteoforigin://TernaryXap.xap"
                                  Uri="/remote/{assemblyname}/{path}"
                                  MappedPath="/{path}" />
    </navUtils:UriMapper>
</navigation:Frame.UriMapper>

Now, I needn’t ever actually write a pack uri myself.  Instead, I can have hyperlinks like “/remote/TernaryXap/Views/Page1.xaml”, and these mappings will generate the appropriate pack uris for you.  They work just like the UriMapping built into the SDK in terms of replacing values in the MappedPath.  “{assemblyname}” is a special token (that you could omit if you set the PackUriMapping.AssemblyName property) that allows you to make the assembly name part of your path.

Enhancing the experience

Great, so now we’ve got navigation integrated with on-demand xap loading.  It takes very few lines of code, and is quick to set up.  Note that my xaps have no concrete knowledge of one another (even the hyperlinks are just text, and users could manually enter other hyperlinks).  But web requests are slow, and could fail.  How can we improve the experience around this type of navigation?

Well, I’ve got two ideas for you that you might recognize: BusyIndicator and ErrorPageLoader.

Since web requests can fail (lost connectivity, bad links, servers being down, or other random problems), we should make sure users don’t see exceptions under those circumstances.  For this, we’ll whip out the ErrorPageLoader from our trusty utility belt and use it to load a local error page if something goes wrong:

<loaders:ErrorPageLoader>
    <loaders:ErrorPageLoader.ContentLoader>
        <xapLoader:XapContentLoader />
    </loaders:ErrorPageLoader.ContentLoader>
    <loaders:ErrorPageLoader.ErrorContentLoader>
        <navigationLoader:PageResourceContentLoader />
    </loaders:ErrorPageLoader.ErrorContentLoader>
    <loaders:ErrorPage ErrorPageUri="/Views/ErrorPage.xaml" />
</loaders:ErrorPageLoader>

You’ll notice that I’ve used the built-in (SDK) PageResourceContentLoader as my ErrorContentLoader.  I did this because, presumably, something bad has happened with the XapContentLoader, so I want to use a ContentLoader with low likelihood of failure in order to display an error page.

Next, users shouldn’t be left hanging while they wait for a link to load.  We can use the BusyIndicator control in the toolkit in order to let the user know that something is going on.  The XapContentLoader has an “IsBusy” property as well as a “Progress” property.  We can make the BusyIndicator’s progress bar display progress and appear by binding it to these properties on the XapContentLoader.  The following handy XAML accomplishes this:

<toolkit:BusyIndicator IsBusy="{Binding ContentLoader.ContentLoader.IsBusy, ElementName=ContentFrame}"
                       DisplayAfter="0:0:0.1">
    <toolkit:BusyIndicator.BusyContent>
        <Grid>
            <Grid.RowDefinitions>
                <RowDefinition Height="Auto" />
                <RowDefinition Height="Auto" />
            </Grid.RowDefinitions>
            <TextBlock Text="Loading page..." Margin="0,0,0,4" />
            <ProgressBar Grid.Row="1"
                         Minimum="0"
                         Maximum="1"
                         Height="25"
                         Value="{Binding ContentLoader.ContentLoader.Progress, ElementName=ContentFrame}" />
        </Grid>
    </toolkit:BusyIndicator.BusyContent>
    <toolkit:BusyIndicator.ProgressBarStyle>
        <Style TargetType="ProgressBar">
            <Setter Property="Visibility" Value="Collapsed" />
        </Style>
    </toolkit:BusyIndicator.ProgressBarStyle>
    <navigation:Frame x:Name="ContentFrame"
                      Source="/Views/Home.xaml">
        <navigation:Frame.ContentLoader>
            <loaders:ErrorPageLoader>
                <loaders:ErrorPageLoader.ContentLoader>
                    <xapLoader:XapContentLoader />
                </loaders:ErrorPageLoader.ContentLoader>
                <loaders:ErrorPageLoader.ErrorContentLoader>
                    <navigationLoader:PageResourceContentLoader />
                </loaders:ErrorPageLoader.ErrorContentLoader>
                <loaders:ErrorPage ErrorPageUri="/Views/ErrorPage.xaml" />
            </loaders:ErrorPageLoader>
        </navigation:Frame.ContentLoader>
    </navigation:Frame>
</toolkit:BusyIndicator>

Note that I’ve hidden the BusyIndicator’s default progress bar, and added one to its BusyContent that binds to the XapContentLoader’s progress.  Now, when users navigate to pages and have to wait for them to load, they are presented with the BusyIndicator and a progress bar letting them know how much is left to be downloaded.  The application continues to appear responsive, and users can continue to work with the rest of the application.

Cross-domain considerations and limiting access

We’ve now unleashed a lot of power.  Your application can now load pages in any xap that Silverlight can get access to using a WebClient.  If the Frame control you’re using integrates with the browser, users can type any uri into the browser to navigate to, and right now, the XapContentLoader will blindly go and load their code.

This could be a bit of a security issue (I’m no expert, but this one sticks out like a sore thumb).

Suppose domain supersecret.com has a cross-domain policy that allows my domain (and only my domain), davidpoll.com, to access services on it.  My domain is using the XapContentLoader, and can load pages in any xap that WebClient can access.  A developer whose domain is evil.com realizes this, and decides to try to get access to supersecret.com’s services.  He’s able to do this by:

• Adding a cross-domain policy that allows davidpoll.com to access xaps on evil.com
• Pointing the Silverlight application on davidpoll.com to his xap on evil.com (this will work, since WebClient just checks evil.com’s cross-domain policy)
• Now that evil.com’s xap has been loaded and is running on davidpoll.com’s application, he can access supersecret.com’s services (since the evil.com’s code is now running on davidpoll.com)!

Because of this problem, I’ve disabled cross-domain loading on the XapContentLoader by default.  You can re-enable it, but please be aware of this potential problem.  The AuthContentLoader is a convenient way to restrict access to domains you don’t want users to be able to access just by changing the Uri.  Here, I’ve enabled cross-domain access, but restricted access only to my other domain (this one happens to be my personal website that I don’t update too often ):

<auth:AuthContentLoader>
    <auth:AuthContentLoader.ContentLoader>
        <xapLoader:XapContentLoader EnableCrossDomain="True" />
    </auth:AuthContentLoader.ContentLoader>
    <auth:NavigationAuthorizer>
        <auth:NavigationAuthRule UriPattern="pack://((siteoforigin:,,)|(authority:,,)|(http:,,open\.depoll\.com)).*">
            <auth:Allow Users="*" />
        </auth:NavigationAuthRule>
        <auth:NavigationAuthRule UriPattern="pack://.+:,,.*">
            <auth:Deny Users="*" />
        </auth:NavigationAuthRule>
    </auth:NavigationAuthorizer>
</auth:AuthContentLoader>

This allows users to access xaps on my site (open.depoll.com), while denying access to other pack uris.  Coupled with the ErrorContentLoader, a consistent, safe experience can be provided for users.

MEF and Prism

At this point, you might be asking yourself why I rolled my own solution to this problem?  MEF and Prism both have very effective implementations for modularization of applications, and you could certainly build very similar ContentLoaders based upon their libraries for loading xaps (in fact, I hope to see folks out there do so! ).  Really, the reason I rolled my own libraries for this is twofold:

• Support for cached assemblies – I wanted to make sure to attempt to solve the shared dependency problem described earlier
• Size – it’s important to keep the size of the bootstrapping assemblies small in order to reap the benefits of dynamic loading.  The total size of the libraries required for the XapContentLoader is about 25k compressed.  I’d still like to pare that down, so if folks have ideas, let me know

If you’ve got ideas for how best to use MEF or Prism with INavigationContentLoader, let me know!  If you’re already using them for modularization and want to integrate them with navigation, this is possible in Silverlight 4 thanks to INavigationContentLoader.

The goods

As you know by now if you’ve been following my blog, I never leave you stranded without code and a live sample!  Take a look!

Click around using the links on top and see what happens to the Uri in the browser’s address bar.  You’ll note the cross-domain access as well as the use of QueryStrings (which still work, of course!).  Open up Fiddler or some other tool to verify that xaps and zip files for cached assemblies are only downloaded once thanks to browser caching.  Enjoy it!

Finally, some source code for you:

Continuing my series of posts on ways to use INavigationContentLoader (a feature in the Silverlight 4 Beta SDK), in this post, I’ll explore another idea for a composable INavigationContentLoader that protects access to your pages based upon the credentials of the user of your Silverlight application.  To demonstrate its use, I’m using a WCF RIA Services application (purely for their Authentication/Authorization provisions).

The basic problem is this: as you would with a website, you build an application with multiple pages – some of which are intended for anonymous users or users in a particular role and some are intended for users with greater privileges.  How do you prevent such users from navigating to those pages and give them an appropriate user experience if they do try to reach pages for which they are not authorized?

To that end, I’ve added another INavigationContentLoader to my SLaB examples – the “AuthContentLoader” – that checks to see whether your user is authorized to view a page before navigating to it.  If the user is not authenticated, the AuthContentLoader throws, resulting in a NavigationFailed event on the Frame/NavigationService that you can handle in order to provide better feedback to your users if there is an UnauthorizedAccessException.

Cool – How does it work?

If you’re familiar with authorization with ASP.NET (settings you might add to your web.config file), this ContentLoader’s use should come pretty easily to you.  For example, in ASP.NET, you might have the following in your web.config:

<system.web>
  <authorization>
    <allow roles="Role1, Role2" />
    <allow users="SuperUser"/>
    <deny roles="Role3, Role4" users="LessImpressiveUser" />
    <deny users="?" />
    <allow users="*"/>
  </authorization>
</system.web>

I tried to keep the API for the AuthContentLoader quite similar.  With the AuthContentLoader, you can:

• Allow or deny users access to pages that match a Regular Expression (allowing you to scope the authorization to particular pages)
• Allow or deny users access to pages based upon their roles, authentication status, and user name
• Wrap any other INavigationContentLoader in order to protect access

To accomplish this, there are just a few steps:

1. Set your Frame.ContentLoader to an AuthContentLoader.
2. Bind AuthContentLoader.Principal to any IPrincipal (in my example, I’ll use the built-in authentication context in WCF RIA Services).  This is what the ContentLoader uses to check the user’s credentials.
3. Add rules for your pages.  If no rule matches a page, the page is assumed to be broadly accessible.

Put all of this together, and you end up with something like this:

<navigation:Frame ...>
    <navigation:Frame.ContentLoader>
        <authLoader:AuthContentLoader Principal="{Binding User, Source={StaticResource WebContext}}">
            <authLoader:NavigationAuthorizer>
                <authLoader:NavigationAuthRule UriPattern="^/Views/About\.xaml\??.*$">
                    <authLoader:Deny Users="?" />
                    <authLoader:Allow Users="*" />
                </authLoader:NavigationAuthRule>
                <authLoader:NavigationAuthRule UriPattern="^/Views/RegisteredUsersPage.xaml\??.*$">
                    <authLoader:Allow Roles="Registered Users" />
                </authLoader:NavigationAuthRule>
            </authLoader:NavigationAuthorizer>
        </authLoader:AuthContentLoader>
    </navigation:Frame.ContentLoader>
</navigation:Frame>

Here, we have rules for About.xaml (with any querystring) and RegisteredUsersPage.xaml (again, with any querystring).  Note that the UriPattern is a Regex, and must also take into account the possible query strings that could be attached to the request.  I know it looks a little arcane, but it does the trick, and allows you to specify whole sets of Uri’s that share the same authorization characteristics (e.g. any page in the “PrivateViews” folder could be restricted to Administrators).

The XAML snippet above places restrictions on two pages:

• About.xaml – anonymous (Principal == null || Principal.Identity == null || Principal.Identity.IsAuthenticated == false) users are denied, and all other users are allowed
• RegisteredUsersPage.xaml – only users that belong to the “Registered Users” role are allowed
• Users are granted access to all other pages

Like the ErrorPageLoader, the AuthContentLoader can take another ContentLoader (but defaults to the PageResourceContentLoader if none is specified), and will delegate the actual loading (after the user has been authorized) to that loader.

And there you go!  Easy as pie!  Feel free to give it a try and play around with it!  Happy New Year!

Wait!  Don’t stop yet!  Please tie this back to your other posts!

Relax!  I won’t leave you hanging!  After all, what’s the point of having two composable INavigationContentLoaders (AuthContentLoader and ErrorPageLoader) if you’re not going to use them together?

I made a very specific choice with the AuthContentLoader: when the user doesn’t have permission to access a page, the AuthContentLoader throws an exception.  That’s very convenient when you want to use the ErrorPageLoader to handle authentication failures.  The AuthContentLoader, by default, throws an UnauthorizedAccessException, so we can handle that exception explicitly using the ErrorPageLoader.  In this case, we’ll redirect users who visit an unauthorized page to another page that directs them to log in.  The XAML for this follows:

<errorLoader:ErrorPageLoader>
    <errorLoader:ErrorPageLoader.ErrorPages>
        <errorLoader:ErrorPage ExceptionType="UnauthorizedAccessException" ErrorPageUri="/LoginPage" />
    </errorLoader:ErrorPageLoader.ErrorPages>
    <errorLoader:ErrorPageLoader.ErrorContentLoader>
        <errorLoader:ErrorRedirector />
    </errorLoader:ErrorPageLoader.ErrorContentLoader>
    <errorLoader:ErrorPageLoader.ContentLoader>
        <authLoader:AuthContentLoader Principal="{Binding User, Source={StaticResource WebContext}}">
            <authLoader:NavigationAuthorizer>
                <authLoader:NavigationAuthRule UriPattern="^/Views/About\.xaml\??.*$">
                    <authLoader:Deny Users="?" />
                    <authLoader:Allow Users="*" />
                </authLoader:NavigationAuthRule>
                <authLoader:NavigationAuthRule UriPattern="^/Views/RegisteredUsersPage.xaml\??.*$">
                    <authLoader:Allow Roles="Registered Users" />
                </authLoader:NavigationAuthRule>
            </authLoader:NavigationAuthorizer>
        </authLoader:AuthContentLoader>
    </errorLoader:ErrorPageLoader.ContentLoader>
</errorLoader:ErrorPageLoader>

Cool!  Now, if users navigate to a page they’re not authorized to see, they’ll be redirected to a login page!  Note the exception type being handled (UnauthorizedAccessException), the ErrorPageUri (unmapped, because we’re using the ErrorRedirector, which will cause a brand new navigation to take place – including mapping), and the use of the ErrorRedirector to redirect to a new Uri rather than just loading alternate content (allowing the user to come back to the page rather than assuming that the login page is the real content).

Ok, we’re now in pretty good shape, but users can still hit problems besides the UnauthorizedAccessException, such as attempting to load a page that does not exist.  In my last post, we solved this using an ErrorPageLoader, and we’ll do the same this time.  In these cases, I actually do want to load alternate content rather than redirect to an error page, since this is the typical experience with web error pages (e.g. a 404 page).  I can accomplish this by adding a second ErrorPageLoader to the mix, like so:

<errorLoader:ErrorPageLoader>
    <errorLoader:ErrorPageLoader.ErrorPages>
        <errorLoader:ErrorPage ErrorPageUri="/Views/ErrorPage.xaml" />
    </errorLoader:ErrorPageLoader.ErrorPages>
    <errorLoader:ErrorPageLoader.ContentLoader>
        <errorLoader:ErrorPageLoader>
            <errorLoader:ErrorPageLoader.ErrorPages>
                <errorLoader:ErrorPage ExceptionType="UnauthorizedAccessException" ErrorPageUri="/LoginPage" />
            </errorLoader:ErrorPageLoader.ErrorPages>
            <errorLoader:ErrorPageLoader.ErrorContentLoader>
                <errorLoader:ErrorRedirector />
            </errorLoader:ErrorPageLoader.ErrorContentLoader>
            <errorLoader:ErrorPageLoader.ContentLoader>
                <authLoader:AuthContentLoader Principal="{Binding User, Source={StaticResource WebContext}}">
                    <authLoader:NavigationAuthorizer>
                        <authLoader:NavigationAuthRule UriPattern="^/Views/About\.xaml\??.*$">
                            <authLoader:Deny Users="?" />
                            <authLoader:Allow Users="*" />
                        </authLoader:NavigationAuthRule>
                        <authLoader:NavigationAuthRule UriPattern="^/Views/RegisteredUsersPage\.xaml\??.*$">
                            <authLoader:Allow Roles="Registered Users" />
                        </authLoader:NavigationAuthRule>
                    </authLoader:NavigationAuthorizer>
                </authLoader:AuthContentLoader>
            </errorLoader:ErrorPageLoader.ContentLoader>
        </errorLoader:ErrorPageLoader>
    </errorLoader:ErrorPageLoader.ContentLoader>
</errorLoader:ErrorPageLoader>

And that’s it!  Now, when users access your site, they’re protected from any type of error and have access restricted appropriately!  Give it a shot with my live sample application:

Note: Log in with User = “Test”, Password = “_Testing”

Also Note: I’ve been having a little trouble with my server, so if this doesn’t work for you, feel free to try downloading and running the code locally (see below for a link).

First, try clicking on the restricted links at the top of the application and observe the login page that appears.  Next, click the broken link (or type something random into your browser after the “#” in the URL), and observe the error page that appears.  Now, log in to the application (feel free to create your own account or use the test account above – any account should give you access to the pages that are currently restricted), and try visiting those pages again!

Ok, I think I’m beginning to get it.  Give me the goods so I can go play with it!

As always, I can’t leave you empty-handed.  I’ve added the AuthContentLoader to SLaB, which you can download to get both binaries and code.  I’ve also included the source (which requires WCF RIA Services and the Silverlight 4 Beta) for the demo application I linked to above:

• Live Sample (source)
• SLaB v0.0.2 (includes source, a sample app, some tests, and binaries)
  • For the latest version, please check out SLaB on my Downloads and Samples page.
  • The v0.0.2 download of SLaB includes:
    • AuthContentLoader and related classes
    • ErrorPageLoader moved into its own assembly (to keep its size down)

In Conclusion…

In my humble opinion, there is a lot of power in composing these types of INavigationContentLoaders.  With the AuthContentLoader, you can prevent Uri’s from being loaded in the context of your application.  Whether you’re just trying to provide a good user experience or actually prevent users from reaching certain Uri’s (e.g. dynamically downloaded XAPs/assemblies that should only be accessible if you’re logged in) a ContentLoader like this could be useful.  The AuthContentLoader works well with WCF RIA Services, which provides easy access through its “WebContext” concept to a User that represents both an IPrinciple and an IIdentity.  Stay tuned for more ideas – I’m still working on some fun little experiments.  Hopefully these posts inspire some cool ideas!  If you’ve got ‘em, I’d love to hear ‘em!

Remember, SLaB is just a collection of the samples and experimental components I’ve been putting together so that they’re all in one place.  I can’t make any guarantees about maintaining them, fixing bugs, not making breaking changes, etc., but you’re more than welcome to try them out, use them, and let them inspire your development (or show you what not to do if you really dislike something I’m doing!) .

Disclaimer

The AuthContentLoader does not protect your data in any way – it simply provides a user experience around navigating to pages that may have restricted access.  Users can still open up your XAP and see its contents (so the XAML/code for those restricted pages isn’t protected), but it does do an effective job of limiting what users are able to access within your application.  You should still be aggressively securing your application if need be. 

Don’t you have something else to say?

Oh, yeah!  Happy New Year!  Here’s to (and good riddance to) the noughties, bring on the teens!  I hope you all have had a wonderful holiday season, and enjoy prosperity in the year ahead.

Last week, I gave an introduction to INavigationContentLoader, a Silverlight 4 Beta SDK extensibility point that allows you to load arbitrary content in conjunction with the Silverlight navigation feature, and walked you through building a Typename-based content loader.  That’s all well and good, but it’s an awful lot of work to go to in order to build a simple INavigationContentLoader (following the async pattern, fully implementing the interface, etc.).  Sometimes, all you really want to do is handle a few events in order to be up and running, fully integrated with Silverlight navigation.  Furthermore, because of the nature of the feature, Navigation has a high potential for error conditions.  For example, what happens if a user tries to follow a broken link or types a bad address into the browser’s address bar (with a browser-integrated frame)?  How do you gracefully let your users know that something went wrong and give them some options about what to do next?

In this post, I’ll use the INavigationContentLoader extensibility point in the Silverlight 4 Beta SDK to address these two issues.  For convenience, starting with this post, I’ll be compiling my helper classes and utilities into a set of libraries I’ll call “Silverlight and Beyond” (SLaB), which you’re more than welcome to download and use (although I make no guarantees about its functionality or that I won’t introduce breaking changes as I make additions).

An Event-Based INavigationContentLoader

For simple custom content loading like we did with the Typename-based content loader, writing a full implementation of an INavigationContentLoader can really be overkill.  For quick-and-dirty navigation scenarios, it would be much easier to just use a generic INavigationContentLoader and handle some events in order to perform a load operation.  In the simplest case, loading is just a synchronous operation that creates an instance of a page based on your logic (a simple switch statement might be appropriate, and this gives you an opportunity to provide constructor parameters or do other initialization on your pages).

With that in mind, I threw together a SynchronousEventContentLoader that simplifies these cases.  Now, you we can rewrite the Typename-based content loader as follows:

In MainPage.xaml:

<navigation:Frame x:Name="ContentFrame"
              Source="/TypenameEventContentLoader.Views.Home">
    <navigation:Frame.ContentLoader>
        <loader:SynchronousEventContentLoader Load="SynchronousEventContentLoader_Load"
                                              CanLoad="SynchronousEventContentLoader_CanLoad" />
    </navigation:Frame.ContentLoader>
</navigation:Frame>

In MainPage.xaml.cs, we handle the Load/CanLoad events as follows (virtually identical to our previous impelementation):

private LoadResult SynchronousEventContentLoader_Load(Uri targetUri, Uri currentUri)
{
    Type t = Type.GetType(GetTypeNameFromUri(targetUri), false, true);
    object instance = Activator.CreateInstance(t);
    var result = new LoadResult(instance);
    return result;
}

private bool SynchronousEventContentLoader_CanLoad(Uri targetUri, Uri currentUri)
{
    string typeName = GetTypeNameFromUri(targetUri);
    Type t = Type.GetType(typeName, false, true);
    if (t == null)
        return false;
    var defaultConstructor = t.GetConstructor(new Type[0]);
    if (defaultConstructor == null)
        return false;
    return true;
}

private string GetTypeNameFromUri(Uri uri)
{
    if (!uri.IsAbsoluteUri)
        uri = new Uri(new Uri("dummy:///", UriKind.Absolute), uri.OriginalString);
    return Uri.UnescapeDataString(uri.AbsolutePath.Substring(1));
}

And that’s it!  If you just want a quick switch statement so that you can add initialization (constructor parameters, etc.) to your pages, this is a nice, easy way to go.  If there’s a need for something similar that supports asynchronous operations, making a similar INavigationContentLoader for that is fairly straightforward.

Handling Errors using an INavigationContentLoader

There’s a large variety of errors that can occur during navigation – the Uri may not resolve to anything real, the Page may throw an exception while being constructed, your user doesn’t have permission to see a particular page, or your particular INavigationContentLoader may hit an exceptional condition (no network access, invalid syntax when parsing a config file, etc.).  In order to develop a robust application, we need to be able to handle these error conditions gracefully.  For those of you familiar with web development, this is not too dissimilar from writing error pages to handle 404 (page not found) conditions, etc.

One way to handle error conditions with the Navigation framework is to handle the NavigationFailed event on the Frame or NavigationService, but this means that when navigation does fail, your only options are to navigate to a new page altogether (resulting in extra history entries and the potential for further failures) or to show some other UI, which may leave your users with a blank page in front of them (in the Frame) if they navigate to the page directly (rather than from a link in your application).  Our approach will be to load a different page altogether when loading content fails.  For this, I’ve created an ErrorPageLoader, another INavigationContentLoader.

Of additional importance is that this content loader doesn’t really own the content loading process from end to end.  In order for the ErrorPageLoader to be generalized, it must be composable, allowing it to delegate loading to another INavigationContentLoader except during error conditions.  In this case, the ErrorPageLoader has two INavigationContentLoaders that it may delegate its work to:

• ErrorPageLoader.ContentLoader, which is what the ErrorPageLoader will attempt to use in order to service standard load requests.  This defaults to the PageResourceContentLoader built into Silverlight 4, which is what the Frame/NavigationService use by default.
• ErrorPageLoader.ErrorContentLoader, which is what the ErrorPageLoader will use to load pages in case the ErrorPageLoader.ContentLoader fails.  If this value is null, the ErrorPageLoader uses ErrorPageLoader.ContentLoader to load the error pages.

This dichotomy allows you to delegate to a more reliable INavigationContentLoader (e.g. the PageResourceContentLoader) should your primary one fail.  For example, if I use an INavigationContentLoader that downloads external assemblies on the fly, and the downlaod fails, error pages should be loaded locally rather than trying to load from a remote location.

Next, we need a way to specify what Uri to load as an error page based on the type of error that occurred.  The ErrorPageLoader has an ErrorPages property that takes a set of IErrorPages – an interface that maps an exception type to a Uri.  I’ve provided a default implementation for use in XAML that takes a name of an Exception type to handle (or none at all, in which case it becomes a catch-all handler) and a Uri (unmapped) to load using the ErrorContentLoader when those error conditions arise.

With these things in mind, the usage of the ErrorPageLoader looks like this:

<navigation:Frame x:Name="ContentFrame"
                  Source="/Home">
    <navigation:Frame.UriMapper>
      <uriMapper:UriMapper>
        <uriMapper:UriMapping Uri="" MappedUri="/Views/Home.xaml"/>
        <uriMapper:UriMapping Uri="/{pageName}" MappedUri="/Views/{pageName}.xaml"/>
      </uriMapper:UriMapper>
    </navigation:Frame.UriMapper>
    <navigation:Frame.ContentLoader>
        <loaders:ErrorPageLoader>
            <loaders:ErrorPage ExceptionType="System.InvalidOperationException"
                               ErrorPageUri="/Views/InvalidOperationErrorPage.xaml" />
            <loaders:ErrorPage ExceptionType="System.InvalidCastException"
                               ErrorPageUri="/Views/InvalidCastErrorPage.xaml" />
            <loaders:ErrorPage ErrorPageUri="/Views/DefaultErrorPage.xaml" />
        </loaders:ErrorPageLoader>
    </navigation:Frame.ContentLoader>
</navigation:Frame>

There are just a few things to note here:

• Because I didn’t specify an ErrorPageLoader.ContentLoader in the example above, the PageResourceContentLoader will be used to load pages normally.
• The ExceptionType isn’t actually of type Type, since Silverlight XAML doesn’t support custom properties of type Type at the moment.
• The ErrorPageUri is an unmapped Uri (i.e. it does not follow the UriMapper-based scheme)
• When an error page is loaded, the CurrentSource of the Frame/NavigationService (or the browser if the Frame is browser-integrated) remains the same.  If you want the Uri to change, use the ErrorRedirector INavigationContentLoader that I’ve provided to redirect to the error Uri.

The final step in the process of error handling is to provide some good feedback to your users about what went wrong.  In order to do this, it’s useful to know what exception occurred that caused the error page to be loaded.  As such, the ErrorPageLoader has an attached “Error” property, which it attaches to any page loaded using the ErrorContentLoader.  This attached property holds the exception that was thrown during loading.

I threw together a little example of an error page that uses this attached property, like so (alternatively, I could have bound to it in XAML):

protected override void OnNavigatedTo(NavigationEventArgs e)
{
    this.errorInformation.Content = ErrorPageLoader.GetError(this);
    this.uriLink.NavigateUri = e.Uri;
}

You can see an example of the ErrorPageLoader in action here:

And here are some things to try:

• A good link: http://www.davidpoll.com/Samples/ErrorContentLoaderSample/TestPage.html#/Home
• A broken link: http://www.davidpoll.com/Samples/ErrorContentLoaderSample/TestPage.html#/NonExistent
• A link to a page that throws an exception when it’s being constructed: http://www.davidpoll.com/Samples/ErrorContentLoaderSample/TestPage.html#/BrokenPage

Notice what happens to the Uri (everything after the “#” in the URL) when navigating to pages that are in error.  Try changing the URI to anything you can think of – you’ll always be able to navigate there, but the links will just lead you to error pages.

If you’re really brave, here are some other experiments to consider:

• Wrap the ErrorPageLoader around the Typename-based content loader from my previous post, and try navigating to Types without a default constructor or that don’t exist
• Wrap the ErrorPageLoader around your own INavigationContentLoader (or the SynchronousEventContentLoader).  When do you expect loading to fail?  What should the user experience be when something does go wrong?  (here’s an idea: throw an exception if the user isn’t logged in, and use the ErrorPageLoader to show a login page)

So… How does it work?

Well, the behavior of the ErrorPageLoader is pretty straightforward:

• Try to load the page from the targetUri using the ErrorPageLoader.ContentLoader
• If an exception is thrown during that INavigationContentLoader’s BeginLoad or EndLoad, or if the loader returns something invalid (e.g. the LoadResult contains something that’s not a Page or a UserControl)…
  • Find the first IErrorPage in ErrorPageLoader.ErrorPages
  • If an IErrorPage was found, try to load the Uri that the IErrorPage maps to using ErrorPageLoader.ErrorContentLoader
    • If the LoadResult has a Page rather than a redirect, attach the Exception using the Error attached property
  • Otherwise, throw the exception during EndLoad() (i.e. allow the exception to fall through)
• Return the LoadResult

And really, that’s the nature of a composable INavigationContentLoader: add some functionality around an existing INavigationContentLoader, and pass the remaining results on through to the Frame/NavigationService.  Such content loaders make it easy to decorate existing loaders with functionality that applies to your application.  I’ve got a few ideas for these, but I’d love to hear what you think!  Here are a few that I have on my mind:

• Error pages (in case you didn’t just finish reading about those )
• Authenticating/Authorizing (redirect me to a login page or an error page if I’m not authorized to see the one I requested)
• QueryString initialization (reflect over properties on the page to set based upon the query string of the Uri)
• Chainer (if the first INavigationContentLoader in my list didn’t work, try the next one!)

With that said, what else would you like to see?  If something particularly compelling arises, I’d be happy to add it to my “Silverlight and Beyond (SLaB)” library!

And, as always, the goods…

You didn’t really think I’d leave you without some code and samples, did you?

• Live sample
• SLaB v0.0.1 (includes source, a sample app, some tests, and binaries)
  • For the latest version, please check out SLaB on my Downloads and Samples page.
  • The v0.0.1 download of SLaB includes:
    • ErrorPageLoader and related classes
    • SynchronousEventContentLoader

P.S.  What on Earth is SLaB?

I mentioned it briefly at the beginning of this post, but my plan is to start putting all of my utility classes, tools, controls, and so forth in one easily-downloadable and easy-to-use package.  For now, I’m calling this SLaB, or “Silverlight and Beyond” (just because I’m into really corny acronyms).  Hopefully you’ll find it useful either as an example of what to do (or if you really dislike me – what not to do ), or to use within your own applications.  If you’re curious about how or why I did something, or if you find a bug, let me know!  Who knows?  Maybe you’ll inspire another blog post!

Just one note: it’s just little ol’ me working on SLaB, and I make no guarantees of correct behavior, frequent updates, lack of breaking changes, full documentation, support, or anything of the sort.  Nonetheless, I look forward to adding to it whenever my curiosity is piqued enough to make something useful or demonstrative, and I hope you find it useful too!

Quick links to followup posts:

• Event-based and Error-Handling INavigationContentLoaders
• Authentication/Authorization in an INavigationContentLoader
• On-demand loading of assemblies with Silverlight Navigation – Revisited for Silverlight 4 Beta

If you haven’t noticed by now (or been following my previous blog posts), I happen to really enjoy exploring the Navigation feature in Silverlight.  A while back, I posted a number of workarounds and tips for some desirable scenarios using the Navigation feature in Silverlight 3.  Then… I went silent.  And the reason: I’ve been waiting for an extensibility point to be opened up in Silverlight navigation.  In the Silverlight 4 beta, that extensibility point has arrived as the INavigationContentLoader.

The ContentLoader extensibility point allows developers to handle the page loading process themselves, much as you would with a GenericHandler in ASP.NET.  You’re given some context on what to load (in this case a target Uri), then it’s up to you as the developer to decide how to load it.  Your handling of these requests can be as specialized or as generalized as you find appropriate.

On the surface, opening up this extensibility point is a rather small change, but it’s actually very powerful when used to solve general problems.  In this post, I’ll build a basic INavigationContentLoader that loads pages based on class name rather than project file structure.  In future posts, I hope to explore some more general (and possibly composable) ContentLoaders.

So… Tell me about this INavigationContentLoader interface.

Fundamentally, the INavigationContentLoader interface just provides a cancellable asynchronous pattern for loading content based upon a target Uri.  You can set a ContentLoader on the Frame control, which will cause the NavigationService to use your ContentLoader rather than built-in one, which is publicly available as the PageResourceContentLoader.

Here’s what the interface looks like:

public interface INavigationContentLoader
{
    IAsyncResult BeginLoad(Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState);
    void CancelLoad(IAsyncResult asyncResult);
    bool CanLoad(Uri targetUri, Uri currentUri);
    LoadResult EndLoad(IAsyncResult asyncResult);
}

The basic flow of its use with the Frame control and the NavigationService in the Silverlight SDK is as follows:

• Frame/NavigationService receives a request to navigate to a Uri
• Frame/NavigationService uses its UriMapper to map the Uri it was given to a Uri for use by the content loader
• Frame/NavigationService passes the current (post-mapping) Uri to the content loader as well as the target (post-mapping) Uri to the content loader, calling BeginLoad
• Frame/NavigationService waits for a callback from the content loader.  If StopLoading() was called, the Frame/NavigationService calls CancelLoad
• Upon being called back, the Frame/NavigationService calls EndLoad() on the content loader, receiving a LoadResult
  • If the LoadResult contains a redirect Uri, the Frame/NavigationService begins a new load with that Uri as the target – without adding a history entry for the target Uri
  • Otherwise, the Frame/NavigationService attempts to display the fully-initialized UserControl or Page in the LoadResult

Great, I guess…  Can you show me how to write one?

Sure!  First, let’s choose a type of ContentLoader we’d like to create.  For this ContentLoader, we’ll begin to break free of the file structure-driven bonds of the existing ContentLoader provided in Silverlight 3.  Instead, we’ll allow navigation to Pages based upon the type name of the Page.  For example, if I have a page called “MyNamespace.MyPage”, I should be able to navigate a frame to the relative Uri “MyNamespace.MyPage” or “/MyNamespace.MyPage” rather than having to point to the XAML file for the Page.

There are two parts to writing a ContentLoader: implementing the interface and implementing IAsyncResult to store the results of your asynchronous operation.  There is ample documentation for writing an IAsyncResult out there, so I’ll conveniently ignore that for now .

So, here’s our plan:

• Implement INavigationContentLoader
  • Write a helper function that extracts a type name from a Uri
  • Implement CanLoad to check to see if the type specified by the targetUri can be found and has a default constructor
  • Implement BeginLoad to produce an instance of the page specified by the type in targetUri, store it in an IAsyncResult, and call the consumer’s callback
  • Implement EndLoad to wrap the page in a LoadResult and return it to the consumer
• Implement IAsyncResult
  • Add a “Result” property to hold the constructed page
• Use the ContentLoader
  • Specify the ContentLoader in XAML
  • Update Hyperlinks to navigate using our new Uri scheme

Alright, let’s hop to it!

Implementing INavigationContentLoader

Let’s start by implementing the interface:

public class TypenameContentLoader : INavigationContentLoader
{
}

Ok – easy!  Granted, it’s a little empty, but it’s a start!  Now, let’s flesh it out!

To make sense of our Uri scheme, we’ll write a method to extract a Type name from a relative Uri:

private string GetTypeNameFromUri(Uri uri)
{
    if (!uri.IsAbsoluteUri)
        uri = new Uri(new Uri("dummy:///", UriKind.Absolute), uri.OriginalString);
    return Uri.UnescapeDataString(uri.AbsolutePath.Substring(1));
}

This method is pretty straightforward.  First, it turns the relative Uri into an absolute one, using a dummy protocol.  Then, it uses the Path of that Uri as the Type name (minus a leading slash and after unescaping any Uri-encoded values (e.g. %20 becomes a space character, so assembly-qualified type names can be used).  The reason we don’t just use the OriginalString on the uri is because the Uri may contain a query string or a fragment (e.g. “TypeName?query=string#fragment”) – in this case we only want the Path in the Uri.

Next, we’ll implement CanLoad, which is called by the Frame/NavigationService before attempting to load.  Here, we’ll check to see that the type exists and has a default constructor – both of which we’ll need in order to create an instance of the page:

public bool CanLoad(Uri targetUri, Uri currentUri)
{
    string typeName = GetTypeNameFromUri(targetUri);
    Type t = Type.GetType(typeName, false, true);
    if (t == null)
        return false;
    var defaultConstructor = t.GetConstructor(new Type[0]);
    if (defaultConstructor == null)
        return false;
    return true;
}

By implementing CanLoad, we can now safely assume (barring any concurrency-related race condition that could arise, but doesn’t apply for the ContentLoader we’re writing in this post because it operates neither statefully nor asynchronously) that the Frame/ContentLoader will only call BeginLoad after making this check.  As such, our BeginLoad can just go ahead and try to create an instance of the type specified in the targetUri.  Then, it must store the instance in an IAsyncResult, invoke the userCallback, and wait for EndLoad to be called:

public IAsyncResult BeginLoad(Uri targetUri, Uri currentUri, AsyncCallback userCallback, object asyncState)
{
    var result = new TypenameContentLoaderAsyncResult(asyncState);
    Type t = Type.GetType(GetTypeNameFromUri(targetUri), false, true);
    object instance = Activator.CreateInstance(t);
    result.Result = instance;
    userCallback(result);
    return result;
}

Our implementation of EndLoad will extract the instance of the page from the IAsyncResult and wrap it in a LoadResult.  LoadResult is a simple class we introduced to represent the result of a load operation.  It currently allows for two possible outcomes from a ContentLoader: (1) return/display a Page or UserControl, (2) provide a Uri to which users should be redirected (no history entry for the original page will be created).

public LoadResult EndLoad(IAsyncResult asyncResult)
{
    return new LoadResult(((TypenameContentLoaderAsyncResult)asyncResult).Result);
}

The final method of the INavigationContentLoader interface is CancelLoad.  In our case, creating an instance of the page happens synchronously, so cancellation doesn’t really have any meaning or value.  Other ContentLoaders, however, might use this method to stop a download or abort a large operation:

public void CancelLoad(IAsyncResult asyncResult)
{
    return;
}

And that’s it!  Our Typename-based content loader is complete!  A simple implementation of IAsyncResult will allow us to compile:

internal class TypenameContentLoaderAsyncResult: IAsyncResult
{
    public object Result { get; set; }

    // Other IAsyncResult members
}

Consuming the ContentLoader

Consuming our new ContentLoader is as simple as setting the ContentLoader property on your Frame in XAML:

<navigation:Frame xmlns:loader="clr-namespace:TypenameContentLoader.ContentLoader"
                  x:Name="ContentFrame"
                  Source="/TypenameContentLoader.Views.Home">
                  <navigation:Frame.ContentLoader>
                      <loader:TypenameContentLoader />
                  </navigation:Frame.ContentLoader>
</navigation:Frame>

You’ll note that in addition to setting the ContentLoader, I’ve set the source for the Frame control to match our new Uri scheme.  We must also do the same for other hyperlinks in the application:

<HyperlinkButton x:Name="Link1" Style="{StaticResource LinkStyle}"
                 NavigateUri="/TypenameContentLoader.Views.Home" TargetName="ContentFrame" Content="home"/>

<HyperlinkButton x:Name="Link2" Style="{StaticResource LinkStyle}"
                 NavigateUri="/TypenameContentLoader.Views.About, TypenameContentLoader, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" TargetName="ContentFrame" Content="about"/>

<HyperlinkButton x:Name="Link3" Style="{StaticResource LinkStyle}"
                 NavigateUri="/TypenameContentLoader.Views.ParameterizedPage?a=100&amp;b=1000"
                 TargetName="ContentFrame" Content="parameterized?a=100&amp;b=1000"/>

And there you have it!  The application is fully configured to use the new ContentLoader.  You’ll notice that the Frame will happily pass along the complex Uris in all three of the hyperlinks above, and the loader will load them correctly.  Query string values still get parsed by the navigation service, and all is well with the world

Ok, so now I can build a ContentLoader – can I actually see the code?

Yep, and I’ll do you one better!  You can also try the live sample!

• TypenameContentLoader source
• Live sample

And, just to prove that query strings “just work”, try this link into the application with a long list of key/value pairs that get used by the page:

Feel free to play around with it and let me know what you think!

(Also note the screenshot above using Google Chrome – now a supported browser with Silverlight 4!)

Ok, so all of this is cool, but why is it useful?  What’s next?

This Typename-based content loader is a neat trick to try, but its usefulness is still pretty limited.  The extensibility point itself, however, is very powerful.  Instead of having to come up with hacks and workarounds for things like on-demand downloading of assemblies containing pages as I did before, we can bake that logic right into a content loader!  If you are an adherent of the MVVM pattern, you can use your content loader to connect your view to your model.  If all you need to do is specify constructor parameters to your pages, you now have that option!  If you need to pre-load data from a web service before navigating to a page, a content loader can help!

The ContentLoader extensibility point introduced in the Silverlight 4 beta really opens up Silverlight Navigation, allowing you to interject in the page loading process and enabling you to make navigation work with whatever framework or application structure you choose.

I’ve got a bunch of ideas for useful ContentLoaders that I’ll explore (and hopefully blog about) going forward.  If you’ve got ideas, questions, or feedback, please let me know!  I look forward to hearing from you!

If you haven’t noticed already, I happen to like the Navigation feature in Silverlight quite a bit (I wonder why? ).  In my other posts on Navigation, I’ve spent some time exploring how you can navigate to Pages in assemblies other than the main application assembly and how those assemblies can be loaded on-demand (granted, it uses some workarounds, but it gets us where we want to go!).

This is all well and good, but it presents an annoying problem that impacts the maintainability of such code.  Specifically, it forces every hyperlink within each of the external assemblies to know how to refer to its assembly by name (this is akin to the problem with absolute URLs in hyperlinks on web pages – those links become tightly coupled to the page for which they were created, and can’t be copied into other projects).

Technically, almost all Uris used by the navigation framework today are relative Uris (unless UriMappings are used to turn absolute ones into relative ones), but they are application-relative and never Page-relative.  This means that if you have a page at “/Views/Page1.xaml” and want to link to another page at “/Views/Page2.xaml” from within Page1, you must refer to the entire path (“/Views/Page2.xaml”) rather than just the relative path to the other page (e.g. “Page2.xaml” or “./Page2.xaml”).

In this post, we’ll look at a way to allow Page-relative navigation within your Silverlight Pages.  The approach I’ll use will take advantage of the INavigate interface that was added in Silverlight 3 and the HyperlinkButton control that uses this interface to perform navigation when clicked.

The INavigate interface looks like this:

public interface INavigate
{
    // Methods
    bool Navigate(Uri source);
}

It’s a simple interface with a simple purpose: allow a component to provide a way to handle navigation to a Uri.  Right now, the only component built into Silverlight that actually takes advantage of it is the HyperlinkButton control.  We use this control quite often in Navigation-enabled applications, since it allows us to target a particular Frame control to navigate to a Page by Uri.  In the Silverlight Navigation Application project template, you’ll see XAML like this:

<navigation:Frame x:Name="ContentFrame" Style="{StaticResource ContentFrameStyle}"
                  Source="/Home" Navigated="ContentFrame_Navigated" NavigationFailed="ContentFrame_NavigationFailed">
</navigation:Frame>

And:

<HyperlinkButton x:Name="Link2" Style="{StaticResource LinkStyle}"
                 NavigateUri="/About" TargetName="ContentFrame" Content="about"/>

This all works because the Frame control implements INavigate.  In other words, there’s no magic there – you can use it too!  Here’s the way the HyperlinkButton works when you’re trying to target an INavigate (approximately ):

• For each parent FrameworkElement going up the visual tree from the HyperlinkButton…
  • Check to see if the FrameworkElement is an INavigate and that its name matches TargetName (ignored if TargetName is null or empty)
    • If so, call INavigate.Navigate() on the FrameworkElement
    • Otherwise, recursively search for an INavigate that’s properly named within each of the children of the FrameworkElement
  • If no properly named INavigate was found, keep moving up the visual tree

In other words, the HyperlinkButton will search its way up and down the visual tree (technically doing a pre-order breadth-first search from each parent of the HyperlinkButton, working its way up the visual tree) for an appropriate INavigate to call.

So, what does all this INavigate stuff mean to me?

With that technical detail out of the way, the question that arises is: how can we use this to enable Page-relative navigation?  Well, the reason navigation of a Frame works within Pages today is because the Frame control implements INavigate, and the HyperlinkButton works its way up the visual tree until it finds this.

For our purposes, this is great, since it means we can intercept the call to INavigate.Navigate() by implementing the interface somewhere between the HyperlinkButton and the Frame.  There’s a convenient place for this, since applications that use Page/Frame and HyperlinkButtons within those pages have a visual tree like this:

• Application
  • Layout
    • Frame
      • Page
        • HyperlinkButton
        • Other controls
    • Other Controls

What I’m suggesting is that the Page we navigate to implement INavigate and turn page-relative Uri’s into application-relative Uri’s before handing them off the NavigationService (or the Frame) to actually perform the navigation.

I’ve gone ahead and extended my DynamicNavigation library to make DynamicPage implement INavigate to do what we want, but you could do the same on any subclass of Page (including every one of your Pages if you didn’t want a common base class).  Here’s my simple implementation (with a switch to turn off this feature on DynamicPages):

public bool RelativeLinks
{
    get { return (bool)GetValue(RelativeLinksProperty); }
    set { SetValue(RelativeLinksProperty, value); }
}

public static readonly DependencyProperty RelativeLinksProperty =
    DependencyProperty.Register("RelativeLinks", typeof(bool), typeof(DynamicPage), new PropertyMetadata(true));

private static readonly Uri basePlaceHolderUri = new Uri("none:///", UriKind.Absolute);

#region INavigate Members

public bool Navigate(Uri navigateUri)
{
    string original = navigateUri.OriginalString;
    if (RelativeLinks && !navigateUri.IsAbsoluteUri && !original.StartsWith("/"))
    {
        Uri result;
        if (NavigationService.CurrentSource.IsAbsoluteUri)
        {
            result = new Uri(NavigationService.CurrentSource, navigateUri);
        }
        else
        {
            Uri baseUri = new Uri(basePlaceHolderUri, NavigationService.CurrentSource);
            result = new Uri("/" + basePlaceHolderUri.MakeRelativeUri(new Uri(baseUri, navigateUri)).OriginalString,
                UriKind.Relative);
        }
        return NavigationService.Navigate(result);
    }
    else
    {
        return NavigationService.Navigate(navigateUri);
    }
}

#endregion

Now, within the page, you can use Page-relative Uri’s on HyperlinkButtons.  All you need to do is avoid setting a TargetName (either through a style or directly on the HyperlinkButton), and the Page will handle the navigation!

Page-relative Uri’s can take a variety of forms.  Assuming the Page you’re currently on is “/MyLibrary;component/Views/Main/Page1.xaml”, the following transformations will occur (as an example):

• “Page2.xaml” –> “/MyLibrary;component/Views/Main/Page2.xaml”
• “./Page2.xaml” –> “/MyLibrary;component/Views/Main/Page2.xaml”
• “../Page3.xaml” –> “/MyLibrary;component/Views/Page3.xaml”
• “../Secondary/Page3.xaml” –> “/MyLibrary;component/Views/Secondary/Page3.xaml”
• “../../BasePage.xaml” –> “/MyLibrary;component/BasePage.xaml”
• “SubMain/Page4.xaml” –> “/MyLibrary;component/Views/Main/SubMain/Page4.xaml”
• “SubMain/Page4.xaml?a=b&c=d” –> “/MyLibrary;component/Views/Main/SubMain/Page4.xaml?a=b&c=d”
• “/MyLibrary;component/Views/Main/Page5.xaml” –> “/MyLibrary;component/Views/Main/Page5.xaml” (no change)

Cool!  Can I see it in action?

Of course!   As always, you can play around with a running app that does this here:

Click the link at the bottom of that page to peform a relative navigation that should take you on a journey between a number of pages – all of which navigate using relative navigation.

For reference, here is the file structure for the sample application.

So, what’s your point?

Well, to sum it up – being able to do page-relative navigation increases the portability of your Pages.  It’s especially useful if you use it in conjunction with UriMapping.  With the technique above, the “relative-ness” refers to the user-facing Uri.  This means that you can create UriMappings in order to create a “virtual” file structure, and all of your relative links should continue to work (and new ones might be possible!).  Give it a shot and let me know what you think!  I’m continuing to experiment with Navigation, always on the lookout for things that might improve the experience when working with it.

Enough already!  Give me the goods!

Patience!  You didn’t really think I’d leave you hanging, did you?  Here you go:

• DynamicNavigation libraries (see my other posts for an introduction to what it provides and how to use it – 1, 2)
• Sample Source

Stop talking to yourself!

Okay.

As those of you who’ve been reading my blog may know, I’ve been spending a bit of time with some enhancements to navigation in Silverlight surrounding the use of dynamically-loaded assemblies.  I’ve still got a bunch of things I’d like to try to implement, but in the meantime I thought I’d share what I’ve got so far.

Now that I have a mechanism for navigating to Pages in dynamically-loaded assemblies in Silverlight, the question arises: how can I improve the user and developer experience around partitioning applications in this way?

In particular, this is the flow I’d like to be able to create:

• Developer knows the set of Pages his user will be able to navigate to, and partitions them into assemblies that he will load at runtime
• Furthermore, the developer knows the dependencies those assemblies have on other dynamically-loaded assemblies (e.g. multiple assemblies contain Pages that use DataGrid, but System.Windows.Controls.Data should be shared/downloaded when the first of those assemblies is downloaded)
• The user is presented with some sort of navigation UI (e.g. HyperlinkButtons, buttons that call Frame.Navigate(), etc.)
• When the user requests a page in an assembly that has not yet been downloaded, it should be automatically downloaded, and navigation with the Frame should only complete once the Page can be loaded.

With this on-demand loading behavior, deep-linking into applications with dynamically-loaded assemblies can be re-enabled (you’ll notice if you try to deep-link into my sample from my previous post about dynamically-loaded assemblies, you get an exception, since the assembly hasn’t been loaded yet).

I’m developing some utilities that will make this flow easier to accomplish.  Please note that at this point all of the API, etc. is subject to change, and I’m definitely not making any assurances around bugs, quality, or anything of the sort, but I thought I’d share what I’ve been working on and start getting some feedback from you folks!

Anyhoo, let’s take this step by step:

Dividing an application into multiple assemblies

This is fairly straightforward, and something I’m sure most of you have been doing for a long time.  For our purposes, there are a number of things to consider:

• Pages in these assemblies that will be dynamically loaded should use the DynamicPage and DynamicPageShim (or some other workaround you may have come up with) described in my earlier post
• Any dynamically-loaded assemblies need to be in a place accessibly using the WebRequest APIs in Silverlight.  I usually put them in my ClientBin folder, and I used a post-build task to copy any dlls for those assemblies into the correct folder (feel free to see my Sample project for an example of this)
• The libraries I’ve built support loading DLLs as well as XAP and ZIP files with dlls in them. Just using DLLs is probably the easiest way to go, but using ZIP or XAP files will keep the transfer time/size small.
• Remember to take careful note of any dependencies between the libraries.  You’ll need to make sure they’re all loaded into your application before attempting to use the assemblies.

One thing I might do in the future is (attempt to) make a project template that will create a XAP class library that places the XAP in the ClientBin folder for you.  I’m still experimenting with how to do this, but it’s still worth noting that using XAPs can be problematic if you’re sharing libraries (VS will automatically package shared assemblies into your XAP, so you might end up with copies of System.Windows.Controls.Navigation.dll in 3 or 4 XAPs, and since they’re all packaged up with the rest of the assemblies, you’ll end up downloading the same DLL multiple times.

Describing how to load assemblies dynamically

I’ve created a little utility that I call “DynamicLoader,” which allows you to declare, in XAML, where your dynamic DLLs can be downloaded from and their interdependencies.  In my App.xaml, I specify the various libraries that may be loaded dynamically (incidentally, some of these libraries are also in my XAP, and the loader will use the ones built into the XAP rather than re-downloading them automatically).  I also describe the various interdependencies between my libraries.  Some are unnecessary (because the dependencies are already in the XAP), but I chose to be explicit for some of the more complex ones to remove all doubt.  An example (from my sample project) can be seen below.

<load:DynamicLoader x:Key="loader">
    <load:AssemblyDescription AssemblyName="DynamicallyLoadedLibrary"
                              Location="./DynamicallyLoadedLibrary.dll" />
    <load:AssemblyDescription AssemblyName="DynamicallyLoadedLibraryVB"
                              Location="./DynamicallyLoadedLibraryVB.dll" />
    <load:AssemblyDescription AssemblyName="LargeDynamicallyLoadedLibrary"
                              Location="./LargeDynamicallyLoadedLibrary.dll">
        <load:Dependency AssemblyName="System.Windows.Controls" />
        <load:Dependency AssemblyName="System.Windows.Controls.Data" />
        <load:Dependency AssemblyName="System.Windows.Controls.Data.DataForm.Toolkit" />
        <load:Dependency AssemblyName="System.Windows.Controls.Data.Input" />
        <load:Dependency AssemblyName="System.Windows.Controls.DataVisualization.Toolkit" />
        <load:Dependency AssemblyName="System.Windows.Controls.Navigation" />
        <load:Dependency AssemblyName="System.Windows.Data" />
        <load:Dependency AssemblyName="System.ComponentModel.DataAnnotations" />
    </load:AssemblyDescription>
    <load:AssemblyDescription AssemblyName="System.Windows.Controls"
                              Location="./System.Windows.Controls.dll" />
    <load:AssemblyDescription AssemblyName="System.Windows.Controls.Data"
                              Location="./System.Windows.Controls.Data.dll">
        <load:Dependency AssemblyName="System.ComponentModel.DataAnnotations" />
        <load:Dependency AssemblyName="System.Windows.Controls.Data.Input" />
        <load:Dependency AssemblyName="System.Windows.Data" />
    </load:AssemblyDescription>
    <load:AssemblyDescription AssemblyName="System.Windows.Controls.Data.DataForm.Toolkit"
                              Location="./System.Windows.Controls.Data.DataForm.Toolkit.dll">
        <load:Dependency AssemblyName="System.ComponentModel.DataAnnotations" />
        <load:Dependency AssemblyName="System.Windows.Data" />
    </load:AssemblyDescription>
    <load:AssemblyDescription AssemblyName="System.Windows.Controls.Data.Input"
                              Location="./System.Windows.Controls.Data.Input.dll">
        <load:Dependency AssemblyName="System.ComponentModel.DataAnnotations" />
    </load:AssemblyDescription>
    <load:AssemblyDescription AssemblyName="System.Windows.Controls.DataVisualization.Toolkit"
                              Location="./System.Windows.Controls.DataVisualization.Toolkit.dll" />
    <load:AssemblyDescription AssemblyName="System.Windows.Controls.Navigation"
                              Location="./System.Windows.Controls.Navigation.dll" />
    <load:AssemblyDescription AssemblyName="System.Windows.Data"
                              Location="./System.Windows.Data.dll" />
    <load:AssemblyDescription AssemblyName="System.ComponentModel.DataAnnotations"
                              Location="System.ComponentModel.DataAnnotations.dll" />
</load:DynamicLoader>

The Location specified in each AssemblyDescription is a URI.  In this case, all of my dlls are in my ClientBin directory, so they all begin with “./”, but these could be any URI that can be reached by the Silverlight application.  Furthermore, if you wish to use the new ClientHttp networking stack to do the downloading, you can choose to do so (as part of the AssemblyDescription).

The loader will asynchronously load any requested library (by name), and will only fire Loaded events once all of each assembly’s dependencies have been loaded.  This allows us to know when it’s safe to try to navigate to a Page in a dynamically-loaded assembly.

Creating Navigation UI

Nothing too special to share here.  HyperlinkButtons use the exact same URI scheme as before (for navigating to pages in referenced/dynamically-loaded assemblies).  Here’s what my XAML for my navigation bar looks like:

<Border x:Name="LinksBorder" Style="{StaticResource LinksBorderStyle}">
    <StackPanel x:Name="LinksStackPanel" Style="{StaticResource LinksStackPanelStyle}">

        <HyperlinkButton x:Name="Link1" Style="{StaticResource LinkStyle}"
                     NavigateUri="/Home" TargetName="ContentFrame" Content="home"/>

        <Rectangle x:Name="Divider1" Style="{StaticResource DividerStyle}"/>

        <HyperlinkButton x:Name="Link2" Style="{StaticResource LinkStyle}"
                     NavigateUri="/About" TargetName="ContentFrame" Content="about"/>

        <Rectangle x:Name="Divider2" Style="{StaticResource DividerStyle}"/>

        <HyperlinkButton x:Name="csharp" Style="{StaticResource LinkStyle}" IsEnabled="True"
                     NavigateUri="/DynamicallyLoadedLibrary;component/CSDynamicPage.dyn.xaml" TargetName="ContentFrame" Content="C# Class Library"/>

        <Rectangle x:Name="Divider3" Style="{StaticResource DividerStyle}"/>

        <HyperlinkButton x:Name="vb" Style="{StaticResource LinkStyle}" IsEnabled="True"
                     NavigateUri="/DynamicallyLoadedLibraryVB;component/VBDynamicPage.dyn.xaml" TargetName="ContentFrame" Content="VB Class Library"/>

        <Rectangle x:Name="Divider4" Style="{StaticResource DividerStyle}"/>

        <HyperlinkButton x:Name="large" Style="{StaticResource LinkStyle}" IsEnabled="True"
                     NavigateUri="/LargeDynamicallyLoadedLibrary;component/LargeDynamicPage.dyn.xaml" TargetName="ContentFrame" Content="Large Class Library"/>
    </StackPanel>
</Border>

Again, nothing too scary here – the XAML remains identical to its form without the dynamically-loaded libraries.

Adding on-demand navigation

The other important piece of this puzzle is a Frame control that uses the loader to ensure that dynamically-loaded libraries are loaded into the AppDomain before attempting to navigate to pages within those libraries.  I’ve provided a derived Frame class (DynamicNavigation.Utilities.Controls.Frame) that does precisely this.  As with my DynamicPage class, you should expect a few quirks, since the Frame class from which it derives doesn’t have any virtual methods.  Don’t cast my Frame to a System.Windows.Controls.Frame if you don’t want to get a bunch of extra events for Loading, Loaded, etc.  Also, since I couldn’t replace the NavigationService, if you subscribe to events on that service, you’ll see a large number of extra events being raised.  Neither of these eccentricities should hamper functionality, but you may see some unexpected activity if you watch those events!

My Frame class takes an DynamicLoader and delegates all loading of dynamic libraries to it.  Here’s what my XAML declaration of the Frame looks like (plus or minus some extraneous attributes):

<dnav:Frame x:Name="ContentFrame" Style="{StaticResource ContentFrameStyle}"
            DynamicLoader="{StaticResource loader}"
            Source="/Home">
    <dnav:Frame.UriMapper>
        <uriMapper:UriMapper>
            <uriMapper:UriMapping Uri="" MappedUri="/Views/Home.xaml"/>
            <uriMapper:UriMapping Uri="/{a};component/{p}" MappedUri="/{a};component/{p}" />
            <uriMapper:UriMapping Uri="/{pageName}" MappedUri="/Views/{pageName}.xaml"/>
        </uriMapper:UriMapper>
    </dnav:Frame.UriMapper>
</dnav:Frame>

And that’s it!  With my custom Frame class, it take *zero* code to get dynamic loading up and running – only XAML is necessary.  Attach an Activity control to the loader, and you’re hot to trot!

In Conclusion

Well, there you have it!  I’d like to remind folks that none of the APIs here are intended to be concrete, and I make no guarantees of quality – I’m just trying to demonstrate how it can be done, and if the interest is there, I’ll keep investing some time in exploring this.  I’ve got a bunch of ideas for where I can go from here, things I’d like to change/improve, and I look forward to playing some more with these prototypes.

Without further ado, here are the links I’m sure you’re all waiting for:

• DynamicNavigation libraries (for your consumption)
• Live Sample
• Sample Source

What’s next?

Well, I’ve got a lot of ideas, and I’d love to hear some from you all.  Here are some of mine (not making any promises – I’m just experimenting with these):

• Cache to IsoStore – downloaded libraries could be stored in Isolated Storage and loaded from there if they’re already on the machine
• Install – When the application is taken out of browser, automatically download the assemblies to Isolated Storage and load from there, allowing the entire application to be run offline
• URI scheme/custom loading – I’d love to be able to just specify the whole deal in a URI to a page, such as “pack://http:,,www.davidpoll.com,Samples,ClientBin,MyLibrary.dll;component/Page2.dyn.xaml” and not need the big manifest with assembly name/location mappings and dependencies.
• Dependencies for particular URIs – allows the Frame control to pre-load assemblies before a particular page is loaded, even if the page is a local one (thanks, Austin, for this idea!)

Anyway, I’ve got a thousand other ideas racing through my mind right now, but those are just a few.  What do you think?  Is there anything you dislike about my approach or anything you particularly like?  Speak up!

Continuing with my recent theme of enhancing the built-in support for Navigation in Silverlight 3, I thought I’d use this post to look briefly at enhancing user experience during navigation.  On the surface, the Frame control is pretty unexciting from a UX perspective – its job is really just to display pages as a result of requests to navigate (either through the browser’s address bar, responding to HyperlinkButton clicks, or direct calls to Frame.Navigate()).  It has barely any UI of its own, and can usually be thought of as an enhanced ContentControl (incidentally, it is one!).

Most of the time, all the Frame is doing is displaying a Page, and this (in my opinion at least) is an appropriate presentation – the Frame shouldn’t get in the way of displaying my Pages.  Where I do want the Frame to intervene now and then is during page changes, allowing me to provide rich transitions when navigating from Page to Page.  The Frame control provided in the Silverlight 3 SDK doesn’t do anything for us as far as transitions go out of the box, but with a little templating magic and the Silverlight Toolkit’s TransitioningContentControl (which Jesse Liberty has a great blog post on), I think we can get the desired effect!

Let’s begin by taking a peek at the ControlTemplate for the Frame control:

<ControlTemplate TargetType="navigation:Frame">
    <Border HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
            VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
            Background="{TemplateBinding Background}"
            BorderBrush="{TemplateBinding BorderBrush}"
            BorderThickness="{TemplateBinding BorderThickness}">
        <ContentPresenter Cursor="{TemplateBinding Cursor}"
                          HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
                          Margin="{TemplateBinding Padding}"
                          VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
                          Content="{TemplateBinding Content}"/>
    </Border>
</ControlTemplate>

As you can see, there’s very little to it: a Border and a ContentPresenter – with all the appropriate TemplateBindings.

All we have to do to get transitions on the Frame control is replace that ContentPresenter with the TransitioningContentControl:

<ControlTemplate x:Key="TransitioningFrame" TargetType="navigation:Frame">
    <Border Background="{TemplateBinding Background}"
            BorderBrush="{TemplateBinding BorderBrush}"
            BorderThickness="{TemplateBinding BorderThickness}"
            HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
            VerticalAlignment="{TemplateBinding VerticalContentAlignment}">
        <toolkit:TransitioningContentControl Content="{TemplateBinding Content}"
                                             Cursor="{TemplateBinding Cursor}"
                                             Margin="{TemplateBinding Padding}"
                                             HorizontalAlignment="{TemplateBinding HorizontalContentAlignment}"
                                             VerticalAlignment="{TemplateBinding VerticalContentAlignment}"
                                             HorizontalContentAlignment="{TemplateBinding HorizontalContentAlignment}"
                                             VerticalContentAlignment="{TemplateBinding VerticalContentAlignment}"
                                             Transition="<Transition Name>" />
    </Border>
</ControlTemplate>

The “toolkit:” xml namespace uses the following definition (since you can find the TransitioningContentControl in the System.Windows.Controls namespace and the System.Windows.Controls.Layout.Toolkit assembly): xmlns:toolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Layout.Toolkit"

To change the type of transition the Frame will use, just change the value of the Transition property on the TransitioningContentControl.

There’s not much more to it!  Short, sweet, and to the point .

Check out the live sample and source if you’re curious:

• Sample
• Sample Source

Caveats and Questions

I know you’d be disappointed if I really left it at that, so here’s the one caveat I’ve observed with this technique:

My dynamically-loaded libraries with navigation workaround will cause a few problems with this technique, since it sets the Frame’s Content property twice (once to load the DynamicPageShim, the other to load the DynamicPage itself).  The result is that you will see the Frame transition to a blank page and then to the DynamicPage with your content.  So here’s the question: how important is this transitioning behavior to you?  There are two options for how I proceed here, neither of which are truly ideal:

1. Leave DynamicPage and DynamicPageShim as-is and live with the slight wonkiness during transitions.
2. Make DynamicPageShim avoid changing the content of the Frame twice (making transitions work just fine ).  This will mean that you won’t be able to use the DynamicPageexactly as you would the standard Page (e.g. binding to "Frame.Content.MyCustomPropertyOnMyPage” won’t be possible… instead you’d have to bind to “Frame.Content.Content.MyCustomPropertyOnMyPage”).

Neither of these options significantly hampers functionality – just impacts either user experience or developer experience, but I’d love to hear your thoughts!  Do you prefer option 1 or option 2?

In the meantime, I’m working on some fun little utilities that will make dynamically loading assemblies with navigation much simpler and more declarative, and am looking forward to blogging it when it’s ready!

Update: Credit where credit is due

About 10 minutes after I posted this, I came across someone (Koen Zwikstra) who posted almost the exact same thing before me, and I want to make sure he gets fair mention for getting there before me

You can find his post here: http://firstfloorsoftware.com/blog/animated-page-navigation-in-sl3/

Sorry for duplicating!  Great stuff!

In my last post on the new navigation feature in Silverlight, I explored how you can navigate to pages in assemblies/projects referenced by your main application.  Almost immediately, a number of you asked how you can navigate to pages in assemblies that have been dynamically loaded, allowing you to delay downloading certain pieces of your application until users request them.  This allows you to reduce the initial size (and thereby load/download time) of your application to something more appropriate for your users and avoid using bandwidth to download components to users’ machines that they may never actually user/encounter.

Out of the box, Silverlight 3’s navigation feature only allows navigating to Pages in assemblies referenced by your application project and packaged in your XAP.  There are a number of technical reasons behind this that I know we’d like to explore and hopefully address in future versions, but I won’t go into the details here.  There is, however, one exception to this rule that prevents us from navigating to Pages in dynamically-loaded assemblies: you can load Pages with no code behind that live in such assemblies.

After a few months of thinking about this problem in the back of my mind, it finally clicked for me: this exception is the way in!  All of the other workarounds I was able to think of required Pages located in the XAP that would load their contents dynamically and didn’t really take advantage of the Navigation feature at all.

Anyway, I think I finally found a reasonably good workaround, and while it’s a little hacky-er than I would’ve liked, it doesn’t fundamentally change the feel of using Silverlight navigation.  Here’s the gist of my strategy:

• Load an assembly containing a Page dynamically
• Include in this assembly a “shim” Page with no code behind.  In its XAML, reference the real page with code behind, and forward any navigation-related information (events, title, query strings, etc.) to that Page
• When that page is navigated to, replace the Frame’s content with the real page.
• From the application, navigate to the “shim” page in the dynamically-loaded assembly

Ok, I know that sounds a little roundabout, but I think I’ve made it pretty easy to accomplish for a developer now.  More importantly – it works!

Let me go into a little more detail…

The Library

I’ve created a tiny little assembly that I’ve called “DynamicNavigation”.  It contains two classes, both of which are made for use in XAML:

• DynamicPage: A descendant of the Page class that allows the Shim to communicate with it.  If I did my job correctly, for 99% of cases, you can navigate directly to this page (rather than its Shim) if you haven’t dynamically loaded the assembly.  There shouldn’t really be any new public interface (except for some “new” properties that hide the original Page properties, since they aren’t virtual).
• DynamicPageShim:  Another descendant of the Page class, meant to be used in XAML with no code behind.  This class will forward any navigation events, etc., to the DynamicPage it takes as its content.  The goal here was to minimize the XAML so that the additional size due to these files is small.  There may be further optimizations I can do, but it’s getting pretty close

The Developer Experience

Ok, that’s all great, but what do I have to do to use it?

Well, instead of 2 files (<PageName>.xaml and <PageName>.xaml.cs/vb), creating a Page now takes 3 files:

• <PageName>.dyn.xaml:

<dyn:DynamicPageShim xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
           xmlns:dyn="clr-namespace:DynamicNavigation;assembly=DynamicNavigation"
           xmlns:my="clr-namespace:DynamicallyLoadedLibrary;assembly=DynamicallyLoadedLibrary">
    <my:PageName />
</dyn:DynamicPageShim>

I’ve underlined two important lines here.  First, “assembly=DynamicallyLoadedLibrary” – normally, this would be unnecessary in an xmlns definition, since I can refer to the library in which the XAML file exists without the “assembly=” syntax.  For the same technical reasons that we normally can’t load a Page in a dynamically-loaded assembly, this name needs to be fully specified, since it allows the XAML loader to find the dynamically-loaded assembly in which your DynamicPage resides.  Next, you can see that this Shim takes an instance of the DynamicPage as its content.  This allows it to forward navigation-related information to the Page and ensure that the Frame has the correct content.

• <PageName>.xaml

<dyn:DynamicPage x:Class="DynamicallyLoadedLibrary.CSDynamicPage"
           xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
           xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
           xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
           xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
           xmlns:dyn="clr-namespace:DynamicNavigation;assembly=DynamicNavigation"
           xmlns:navigation="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Navigation"
           mc:Ignorable="d"
           d:DesignWidth="640" d:DesignHeight="480"
           Title="Page Title">
    <Grid x:Name="LayoutRoot">

       ...

    </Grid>
</dyn:DynamicPage>

As you can see, there’s really nothing special about the DynamicPage except that the open/close tags are of type DynamicPage rather than Page.  Gotta love it!

• <PageName>.xaml.cs/vb

I won’t show an example here, but there’s really nothing special about this.  You’ll develop exactly as though the DynamicPage were a real Page.  The only thing to watch out for: please don’t cast the DynamicPage to a Page, since this will cause it to refer to hidden properties that may not be set.  Again, for 99% of cases, this is probably not an issue, but it bears a little bit of consideration.

The last piece of the puzzle is actually navigating to the page.  Well, it’s pretty straightforward: navigate just as we did in my other post (using “;component” pack URI syntax).  The only difference: instead of navigating to <PageName>.xaml, you’ll navigate to <PageName>.dyn.xaml.

And that’s it!  The rest should just work!

So, without further ado, I’ve got some tools for you!

The Goods

• DynamicNavigation Download

The download above is a zip containing 3 things:

1. DynamicNavigation.dll – an assembly you should reference in both your application project (and include in your xap) as well as any assemblies you wish to dynamically load (so that you can include the XAML files above)
2. DynamicPageCS.zip – this is a Visual Studio item template that will help get you started.  Drop this zip (without extracting) in “<My Documents>\Visual Studio 2008\Templates\Item Templates\Visual C#”.  Now, if you open Visual Studio and a C# Silverlight 3 project, right-click the project (in the solution explorer) and choose “Add new…”.  Select “Silverlight Dynamic Page” and choose a name for your page.  The item template will create the 3 files for you.  Open up “<PageName>.xaml” and start editing!
3. DynamicPageVB.zip – I didn’t forget about you VB guys!  Follow the same instructions above (but placing the item template in the VB folder instead of the C# one), and you should be set to go!

I’m sure there are some bugs and issues with what I did (for example, the item templates don’t add a reference to DynamicNavigation.dll to your project yet… I hope to fix this once I figure out how!).  Let me know if something’s causing you problems, and I’ll see if I can work it out in my (not so) copious free time

The Sample

You know me – I can’t leave you without a live sample of this thing in action!  Take a look here (for your viewing pleasure):

• Sample
• Sample Source

Enjoy!  You may even find a cameo from a previous post in there!

The Tips

When using my DynamicNavigation tools, there are a few things you should keep in mind.  Hopefully this list will get smaller going forward, but in the meantime, these are some things to remember:

• It’s still up to you to load the assemblies dynamically into your AppDomain before attempting to navigate to them.  A super-simple example of how to do this can be found in the code-behind of my MainPage.xaml.  You can also use tools like Prism to accomplish something similar.  There are definitely some tricks that would make this feel more on-demand than what I’ve done in the sample, but that’s a topic for a future post!
• Along those lines, please make sure any assemblies your dynamically-loaded assembly is dependent upon are loaded before trying to navigate.  I don’t do anything to try to resolve those dependencies.
• Try to avoid casting your DynamicPage to its parent type – Page.  If you do, you’ll find some properties aren’t set to your desired values (such as Title, NavigationCacheMode, etc.).
• My libraries should replace Frame’s Content with the intended page, so feel free to bind into Frame.Content just as you would otherwise.  You may find that Frame.Content does change twice during a navigation rather than just once, but otherwise, you should get the same events/virtual methods called/etc. on your Page.
• Expect Caching and Title to still be honored properly on your page!
• Once you’ve created your <PageName>.dyn.xaml file, you should rarely, if ever, need to modify it.  It’s just a shim, and any other work you’d like to do should be possible directly through the DynamicPage files (.xaml and .xaml.cs/vb)

I tried to keep the library as small as possible.  Anything I build on top of this, I intend to put in a separate library, so that you’re not forced to take additional overhead for the simplest of cases, where you’ve already done your dynamic loading and just want to navigate to pages in those libraries.

The Conclusion

My hope is that this will get you started down the road to navigating to dynamically-loaded assemblies.  I know it’s a bit obtuse, and still harder to do than it ought to be, but what I’d like to do going forward is take this development and create an SL3 library that will make it really simple to download assemblies from your server on-demand during navigation (and perhaps devise some other nifty features).

Please, let me know what you think.  Should I spend more time on these things?  How valuable is using navigation in this way to you?  What kinds of scenarios would you still like to see enabled?

If I’ve confused the heck out of you, I sincerely apologize.  I know I found myself struggling to describe this adequately, so please, ask questions!  I’m happy to share my thoughts/experiences.

Comment away!

P.S. I’m finally on Twitter (at least partially to my dismay ).  You can find me at @depoll

Update: Julian Biddle has posted a wholly different strategy that would allow you to divide your Silverlight application across multiple XAPs on his blog: http://anoriginalidea.wordpress.com/2009/07/22/how-to-build-huge-dynamic-cross-platform-silverlight-business-applications/.  Take a look – it’s an interesting read/approach