This is post #12 in my series 31 Days of Silverlight. On Day #2, we talked briefly about screen transitions, and how to add some drama to moving between screens. Today, we’re going to address how you would handle this on a larger scale.

Also, starting today, you need to have AT LEAST the Silverlight 3 Beta plugin to view the demos. With Silverlight 3 released, we’re going to be moving on to some of the new things you can do with the new release. You can download the Silverlight 3 Beta plugin here.

The shortcomings of this.Content

For an application that has only one or two screen transitions (moving from one XAML file to another XAML file), this.Content is probably perfectly acceptable. The shortcoming is that each time you use this.Content to move from one file to the next, you’re not destroying the previous instance of the UserControl. So you end up building a large tree of UserControls, and eventually your app is going to collapse from the weight. If you’re managing a large application, where your user is constantly jumping from one screen to another, you’re going to find that you might want to approach it from a different angle.

The switcher

The reason that this post is written entirely seperate is because it almost requires a difference in architecture for your Silverlight application. The first sign of this is what I am calling the Switcher UserControl. It is a seperate XAML file (I name it Switcher.xaml, not surprisingly) that has the sole purpose of being the parent UserControl for our application. We then bring our child UserControls in as the Content of the Switcher, and when each one is “switched,” the previous instance gets marked for the Garbage Collector. Which means we are conserving memory by only holding the immediate UserControl in memory, instead of ALL of them, which is what this.Content would result in.

The switcher.xaml file has nothing in its body. Here’s the XAML for it:

<UserControl x:Class="SilverlightSwitcher.Switcher"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
</UserControl>

It’s the code-behind for Switcher that has all of the magic. In our startup method, we set the content of Switcher to our first page of our application. We also create another method, Navigate(), that we will call from each page to move to the next one. Here’s the source for the Switcher.xaml.cs file:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SilverlightSwitcher
{
    public partial class Switcher : UserControl
    {
        public Switcher()
        {
            InitializeComponent();
            if (this.Content == null)
            {
                this.Content = new Page();
            }
        }

        public void Navigate(UserControl nextPage)
        {
            this.Content = nextPage;
        }

    }
}

Making Switcher where we start

Ever wonder how your Silverlight application just knows to start with Page.xaml as your first page? It’s defined in your App.xaml file. There’s a method called Application_Startup that we need to modify in order to make Switcher the thing we load first. Here’s the modified method code:

        private void Application_Startup(object sender, StartupEventArgs e)
        {
            this.RootVisual = new Switcher();
        }

Moving from page to page

Now that we’ve fundamentally changed how we intend to navigate between XAML pages, you’d expect that we’re also going to have to do something different to get to those pages. You’re very insightful. On each page, we’re going to be calling the new Navigate function that we created in Switcher, instead of this.Content. To do this, we’ll need to get a reference to our parent UserControl, Switcher, and then call its Navigate() method. Here’s what the code looks like to do this:

            Switcher switcher = this.Parent as Switcher;
            switcher.Navigate(new Page2());

In each case, we are passing a new instance of the next UserControl to the parent, Switcher, as its content. I’ve created a very simple app below that jumps between two different XAML files using the method I’ve described in this article. If you’d like to see it running in a seperate browser, you can click here to see the Silverlight XAML Switching demo. If you’d like to download the demo code for this XAML Switching example, you can get it here.