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

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):

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 :)