Navigation
Navigation between windows and pages is a crucial point, both in web and desktop applications. If you are an experienced developer, you may remember those times when the event of a button was directly associated with instantiation and the call of a window show method. Nowadays, the tendency is to decouple navigation and windows along with using a Navigation Framework.
Navigating the Web
For those coming from web development using iFrames , the idea will sound familiar (better still, the Silverlight Navigation Framework integrates flawlessly in our Silverlight developments). Imagine a web application in which the header, which contains a navigation menu, is fixed. Finally, let us imagine that every menu option makes the content of our application (the page) change. However, what really happens is that it loads another page in the central iFrame in the backend. Roughly speaking, this is the Navigation Framework.
Another viewpoint (that of an ASP.NET developer) is thinking that we have a MasterPage and several pages associated with it. Silverlight, nevertheless, goes a step beyond, as one of our pages could contain another navigation control.
Let us have a look at the draft of a hypothetical application. The following screenshot displays a sample application that includes a menu and an area for content to be added. The content may differ according to the options selected from the menu:
We can identify two areas:
- One in the previous part, which contains a menu and whose content is fixed.
- Another one which occupies the greatest part of our application. It changes according to the option chosen in the menu. This was an iFrame, which contains another HTML page.
Silverlight Navigation Framework
Navigation Framework is defined as navigation architecture between the pages of a Silverlight application.
Until version 2 (The Silverlight Navigation Framework was introduced in version 3), the main options to lay out an application with several windows were the following:
- Defining UserControls for every page of the application and show/hide them manually, depending on the status of the application.
- Having several HTML container pages, with each one of them having a Silverlight object instantiated.
We wouldn't recommend the second option, since it implies an extra communication system, different XAP modules, and we don't find any advantage versus the first.
With the appearance of Navigation Framework, we are able to centralize navigation automatically from a single point. Navigation between pages is quite clean, thanks to the use of friendly URLs such as http://www.albloguera.com/Silverlight.html#home.
In this way, we are able to tell the application what we want to display.
Navigation Framework allows us to make use of the navigation history. This means that if we click Forward and Back, the application uses the navigation history and loads the page which it has indicated. This is not the only good feature. The navigation route can also show, apart from the page, parameters which initialize the application one way or another. In order to allow a Silverlight application to make use of the history, the page where the Silverlight object is instantiated must contain an iFrame object with the following name:
<iframe id="_sl_historyFrame" style="visibility:hidden;height:0px;width:0px;border:0px"></iframe>
An application created with the Navigation Template adds this iFrame by default. Finally, we would like to point out that we can disable the navigation history for everything that has taken place outside the application. That is, the Silverlight application will not register anything about the navigation that the user does outside. For example, if the user goes to another page, the navigation history of the application will not take that into account. In this respect, we must add the following property to iFrame:
<iframe id="_sl_historyFrame" style="visibility:hidden;height:0px;width:0px;border:0px" JournalOwnership="OwnsJournal">
Once we have gotten an idea of what navigation between different parts of an application is, let us go deeper into the UriMapper concepts.
We could think of UriMapper as the navigation control centre of our application. Here, we define the links or pages of the application (real URI) and assign it a friendly name (URI shown), so that the user does not see the physical address of the page shown, but a name describing it (for those coming from the ASP.NET MVC background, this concept will be quite familiar).
We can see several examples of URI mappings in the following table:
We can observe in the table that URIs do not have to define a fixed physical address, but they can define a flexible behavior, depending on the URI. To define a segment of the URI as a variable, we must add the value in braces; it will be later replaced in the real URI. This is quite useful for parameter passing in the URI.
Frame
This is the container of the application. For those who are familiar with ASP.NET, it is similar to the ContentPlaceHolder. For older users, it is the central iFrame. It is in charge of navigation and shows the different pages of the application.
<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>