Windows Presentation Foundation (WPF) supports browser-style navigation that can be used in two types of applications: standalone applications and XAML browser applications (XBAPs). To package content for navigation, WPF provides the Page class. You can navigate from one Page to another declaratively, by using a Hyperlink, or programmatically, by using the NavigationService. WPF uses the journal to remember pages that have been navigated from and to navigate back to them.
Page, Hyperlink, NavigationService, and the journal form the core of the navigation support offered by WPF. This overview explores these features in detail before covering advanced navigation support that includes navigation to loose Extensible Application Markup Language (XAML) files, HTML files, and objects.
In this topic, the term "browser" refers only to browsers that can host WPF applications, which currently includes Microsoft Internet Explorer and Firefox. Where specific WPF features are supported only by a particular browser, the browser version is referred to.
Navigation in WPF Applications
This topic provides an overview of the key navigation capabilities in WPF. These capabilities are available to both standalone applications and XBAPs, although this topic presents them within the context of an XBAP.
This section explains and demonstrates the following aspects of navigation:
Implementing a Page
In WPF, you can navigate to several content types that include .NET Framework objects, custom objects, enumeration values, user controls, XAML files, and HTML files. However, you'll find that the most common and convenient way to package content is by using Page. Furthermore, Page implements navigation-specific features to enhance their appearance and simplify development.
Using Page, you can declaratively implement a navigable page of XAML content by using markup like the following.
A Page that is implemented in XAML markup has as its root element and requires the WPFXML namespace declaration. The element contains the content that you want to navigate to and display. You add content by setting the property element, as shown in the following markup.
can only contain one child element; in the preceding example, the content is a single string, "Hello, Page!" In practice, you will usually use a layout control as the child element (see Layout) to contain and compose your content.
The child elements of a element are considered to be the content of a Page and, consequently, you don't need to use the explicit declaration. The following markup is the declarative equivalent to the preceding sample.
In this case, is automatically set with the child elements of the element. For more information, see WPF Content Model.
A markup-only Page is useful for displaying content. However, a Page can also display controls that allow users to interact with the page, and it can respond to user interaction by handling events and calling application logic. An interactive Page is implemented by using a combination of markup and code-behind, as shown in the following example.
To allow a markup file and code-behind file to work together, the following configuration is required:
In markup, the element must include the attribute. When the application is built, the existence of in the markup file causes Microsoft build engine (MSBuild) to create a class that derives from Page and has the name that is specified by the attribute. This requires the addition of an XML namespace declaration for the XAML schema ( ). The generated class implements , which is called to register the events and set the properties that are implemented in markup.
In code-behind, the class must be a class with the same name that is specified by the attribute in markup, and it must derive from Page. This allows the code-behind file to be associated with the class that is generated for the markup file when the application is built (see Building a WPF Application).
In code-behind, the Page class must implement a constructor that calls the method. is implemented by the markup file's generated class to register events and set properties that are defined in markup.
When you add a new Page to your project using Microsoft Visual Studio, the Page is implemented using both markup and code-behind, and it includes the necessary configuration to create the association between the markup and code-behind files as described here.
Once you have a Page, you can navigate to it. To specify the first Page that an application navigates to, you need to configure the start Page.
Configuring a Start Page
XBAPs require a certain amount of application infrastructure to be hosted in a browser. In WPF, the Application class is part of an application definition that establishes the required application infrastructure (see Application Management Overview).
An application definition is usually implemented using both markup and code-behind, with the markup file configured as an MSBuild item. The following is an application definition for an XBAP.
An XBAP can use its application definition to specify a start Page, which is the Page that is automatically loaded when the XBAP is launched. You do this by setting the StartupUri property with the uniform resource identifier (URI) for the desired Page.
In most cases, the Page is either compiled into or deployed with an application. In these cases, the URI that identifies a Page is a pack URI, which is a URI that conforms to the pack scheme. Pack URIs are discussed further in Pack URIs in WPF. You can also navigate to content using the http scheme, which is discussed below.
You can set StartupUri declaratively in markup, as shown in the following example.
In this example, the attribute is set with a relative pack URI that identifies HomePage.xaml. When the XBAP is launched, HomePage.xaml is automatically navigated to and displayed. This is demonstrated by the following figure, which shows an XBAP that was launched from a Web server.
Configuring the Host Window's Title, Width, and Height
One thing you may have noticed from the previous figure is that the title of both the browser and the tab panel is the URI for the XBAP. Besides being long, the title is neither attractive nor informative. For this reason, Page offers a way for you to change the title by setting the WindowTitle property. Furthermore, you can configure the width and height of the browser window by setting WindowWidth and WindowHeight, respectively.
WindowTitle, WindowWidth, and WindowHeight can be set declaratively in markup, as shown in the following example.
The result is shown in the following figure.
A typical XBAP comprises several pages. The simplest way to navigate from one page to another is to use a Hyperlink. You can declaratively add a Hyperlink to a Page by using the element, which is shown in the following markup.
A element requires the following:
The pack URI of the Page to navigate to, as specified by the attribute.
Content that a user can click to initiate the navigation, such as text and images (for the content that the element can contain, see Hyperlink).
The following figure shows an XBAP with a Page that has a Hyperlink.
As you would expect, clicking the Hyperlink causes the XBAP to navigate to the Page that is identified by the attribute. Additionally, the XBAP adds an entry for the previous Page to the Recent Pages list in Internet Explorer. This is shown in the following figure.
As well as supporting navigation from one Page to another, Hyperlink also supports fragment navigation.
Fragment navigation is the navigation to a content fragment in either the current Page or another Page. In WPF, a content fragment is the content that is contained by a named element. A named element is an element that has its attribute set. The following markup shows a named element that contains a content fragment.
For a Hyperlink to navigate to a content fragment, the attribute must include the following:
The URI of the Page with the content fragment to navigate to.
A "#" character.
The name of the element on the Page that contains the content fragment.
A fragment URI has the following format.
The following shows an example of a that is configured to navigate to a content fragment.
This section describes the default fragment navigation implementation in WPF. WPF also allows you to implement your own fragment navigation scheme which, in part, requires handling the NavigationService.FragmentNavigation event.
You can navigate to fragments in loose XAML pages (markup-only XAML files with as the root element) only if the pages can be browsed via HTTP.
However, a loose XAML page can navigate to its own fragments.
While Hyperlink allows a user to initiate navigation to a particular Page, the work of locating and downloading the page is performed by the NavigationService class. Essentially, NavigationService provides the ability to process a navigation request on behalf of client code, such as the Hyperlink. Additionally, NavigationService implements higher-level support for tracking and influencing a navigation request.
When a Hyperlink is clicked, WPF calls NavigationService.Navigate to locate and download the Page at the specified pack URI. The downloaded Page is converted to a tree of objects whose root object is an instance of the downloaded Page. A reference to the root Page object is stored in the NavigationService.Content property. The pack URI for the content that was navigated to is stored in the NavigationService.Source property, while the NavigationService.CurrentSource stores the pack URI for the last page that was navigated to.
Programmatic Navigation with the Navigation Service
You don't need to know about NavigationService if navigation is implemented declaratively in markup using Hyperlink, because Hyperlink uses the NavigationService on your behalf. This means that, as long as either the direct or indirect parent of a Hyperlink is a navigation host (see Navigation Hosts), Hyperlink will be able to find and use the navigation host's navigation service to process a navigation request.
However, there are situations when you need to use NavigationService directly, including the following:
When you need to instantiate a Page using a non-default constructor.
When you need to set properties on the Page before you navigate to it.
When the Page that needs to be navigated to can only be determined at run time.
In these situations, you need to write code to programmatically initiate navigation by calling the Navigate method of the NavigationService object. That requires getting a reference to a NavigationService.
Getting a Reference to the NavigationService
For reasons that are covered in the Navigation Hosts section, a WPF application can have more than one NavigationService. This means that your code needs a way to find a NavigationService, which is usually the NavigationService that navigated to the current Page. You can get a reference to a NavigationService by calling the NavigationService.GetNavigationService method. To get the NavigationService that navigated to a particular Page, you pass a reference to the Page as the argument of the GetNavigationService method. The following code shows how to get the NavigationService for the current Page.
As a shortcut for finding the NavigationService for a Page, Page implements the NavigationService property. This is shown in the following example.
Programmatic Navigation to a Page Object
The following example shows how to use the NavigationService to programmatically navigate to a Page. Programmatic navigation is required because the Page that is being navigated to can only be instantiated using a single, non-default constructor. The Page with the non-default constructor is shown in the following markup and code.
The Page that navigates to the Page with the non-default constructor is shown in the following markup and code.
When the Hyperlink on this Page is clicked, navigation is initiated by instantiating the Page to navigate to using the non-default constructor and calling the NavigationService.Navigate method. Navigate accepts a reference to the object that the NavigationService will navigate to, rather than a pack URI.
Programmatic Navigation with a Pack URI
If you need to construct a pack URI programmatically (when you can only determine the pack URI at run time, for example), you can use the NavigationService.Navigate method. This is shown in the following example.
Refreshing the Current Page
A Page is not downloaded if it has the same pack URI as the pack URI that is stored in the NavigationService.Source property. To force WPF to download the current page again, you can call the NavigationService.Refresh method, as shown in the following example.
There are many ways to initiate navigation, as you've seen. When navigation is initiated, and while navigation is in progress, you can track and influence the navigation using the following events that are implemented by NavigationService:
Navigating. Occurs when a new navigation is requested. Can be used to cancel the navigation.
NavigationProgress. Occurs periodically during a download to provide navigation progress information.
Navigated. Occurs when the page has been located and downloaded.
NavigationStopped. Occurs when the navigation is stopped (by calling StopLoading), or when a new navigation is requested while a current navigation is in progress.
NavigationFailed. Occurs when an error is raised while navigating to the requested content.
LoadCompleted. Occurs when content that was navigated to is loaded and parsed, and has begun rendering.
FragmentNavigation. Occurs when navigation to a content fragment begins, which happens:
Immediately, if the desired fragment is in the current content.
After the source content has been loaded, if the desired fragment is in different content.
The navigation events are raised in the order that is illustrated by the following figure.
In general, a Page isn't concerned about these events. It is more likely that an application is concerned with them and, for that reason, these events are also raised by the Application class:
Every time NavigationService raises an event, the Application class raises the corresponding event. Frame and NavigationWindow offer the same events to detect navigation within their respective scopes.
In some cases, a Page might be interested in these events. For example, a Page might handle the NavigationService.Navigating event to determine whether or not to cancel navigation away from itself. This is shown in the following example.
If you register a handler with a navigation event from a Page, as the preceding example does, you must also unregister the event handler. If you don't, there may be side effects with respect to how WPF navigation remembers Page navigation using the journal.
Remembering Navigation with the Journal
WPF uses two stacks to remember the pages that you have navigated from: a back stack and a forward stack. When you navigate from the current Page to a new Page or forward to an existing Page, the current Page is added to the back stack. When you navigate from the current Page back to the previous Page, the current Page is added to the forward stack. The back stack, the forward stack, and the functionality to manage them, are collectively referred to as the journal. Each item in the back stack and the forward stack is an instance of the JournalEntry class, and is referred to as a journal entry.
Navigating the Journal from Internet Explorer
Conceptually, the journal operates the same way that the Back and Forward buttons in Internet Explorer do. These are shown in the following figure.
For XBAPs that are hosted by Internet Explorer, WPF integrates the journal into the navigation UI of Internet Explorer. This allows users to navigate pages in an XBAP by using the Back, Forward, and Recent Pages buttons in Internet Explorer. The journal is not integrated into Microsoft Internet Explorer 6 in the same way it is for Internet Explorer 7 or Internet Explorer 8. Instead, WPF renders a substitute navigation UI.
In Internet Explorer, when a user navigates away from and back to an XBAP, only the journal entries for pages that were not kept alive are retained in the journal. For discussion on keeping pages alive, see Page Lifetime and the Journal later in this topic.
By default, the text for each Page that appears in the Recent Pages list of Internet Explorer is the URI for the Page. In many cases, this is not particularly meaningful to the user. Fortunately, you can change the text using one the following options:
The attached attribute value.
The attribute value.
The attribute value and the URI for the current Page.
The URI for the current Page. (Default)
The order in which the options are listed matches the order of precedence for finding the text. For example, if is set, the other values are ignored.
The following example uses the attribute to change the text that appears for a journal entry.
Navigating the Journal Using WPF
Although a user can navigate the journal by using the Back, Forward, and Recent Pages in Internet Explorer, you can also navigate the journal using both declarative and programmatic mechanisms provided by WPF. One reason to do this is to provide custom navigation UIs in your pages.
You can declaratively add journal navigation support by using the navigation commands exposed by NavigationCommands. The following example demonstrates how to use the navigation command.
You can programmatically navigate the journal by using one of the following members of the NavigationService class:
The journal can also be manipulated programmatically, as discussed in Retaining Content State with Navigation History later in this topic.
Page Lifetime and the Journal
Consider an XBAP with several pages that contain rich content, including graphics, animations, and media. The memory footprint for pages like these could be quite large, particularly if video and audio media are used. Given that the journal "remembers" pages that have been navigated to, such an XBAP could quickly consume a large and noticeable amount of memory.
For this reason, the default behavior of the journal is to store Page metadata in each journal entry rather than a reference to a Page object. When a journal entry is navigated to, its Page metadata is used to create a new instance of the specified Page. As a consequence, each Page that is navigated has the lifetime that is illustrated by the following figure.
Although using the default journaling behavior can save on memory consumption, per-page rendering performance might be reduced; reinstantiating a Page can be time-intensive, particularly if it has a lot of content. If you need to retain a Page instance in the journal, you can draw on two techniques for doing so. First, you can programmatically navigate to a Page object by calling the NavigationService.Navigate method.
Second, you can specify that WPF retain an instance of a Page in the journal by setting the KeepAlive property to (the default is ). As shown in the following example, you can set KeepAlive declaratively in markup.
The lifetime of a Page that is kept alive is subtly different from one that is not. The first time a Page that is kept alive is navigated to, it is instantiated just like a Page that is not kept alive. However, because an instance of the Page is retained in the journal, it is never instantiated again for as long as it remains in the journal. Consequently, if a Page has initialization logic that needs to be called every time the Page is navigated to, you should move it from the constructor into a handler for the Loaded event. As shown in the following figure, the Loaded and Unloaded events are still raised each time a Page is navigated to and from, respectively.
When a Page is not kept alive, you should not do either of the following:
Store a reference to it, or any part of it.
Register event handlers with events that are not implemented by it.
Doing either of these will create references that force the Page to be retained in memory, even after it has been removed from the journal.
In general, you should prefer the default Page behavior of not keeping a Page alive. However, this has state implications that are discussed in the next section.
Retaining Content State with Navigation History
If a Page is not kept alive, and it has controls that collect data from the user, what happens to the data if a user navigates away from and back to the Page? From a user experience perspective, the user should expect to see the data they entered previously. Unfortunately, because a new instance of the Page is created with each navigation, the controls that collected the data are reinstantiated and the data is lost.
Fortunately, the journal provides support for remembering data across Page navigations, including control data. Specifically, the journal entry for each Page acts as a temporary container for the associated Page state. The following steps outline how this support is used when a Page is navigated from:
An entry for the current Page is added to the journal.
The state of the Page is stored with the journal entry for that page, which is added to the back stack.
The new Page is navigated to.
When the page Page is navigated back to, using the journal, the following steps take place:
The Page (the top journal entry on the back stack) is instantiated.
The Page is refreshed with the state that was stored with the journal entry for the Page.
The Page is navigated back to.
WPF automatically uses this support when the following controls are used on a Page:
If a Page uses these controls, data entered into them is remembered across Page navigations, as demonstrated by the Favorite ColorListBox in the following figure.
When a Page has controls other than those in the preceding list, or when state is stored in custom objects, you need to write code to cause the journal to remember state across Page navigations.
If you need to remember small pieces of state across Page navigations, you can use dependency properties (see DependencyProperty) that are configured with the FrameworkPropertyMetadata.Journal metadata flag.
If the state that your Page needs to remember across navigations comprises multiple pieces of data, you may find it less code intensive to encapsulate your state in a single class and implement the IProvideCustomContentState interface.
If you need to navigate through various states of a single Page, without navigating from the Page itself, you can use IProvideCustomContentState and NavigationService.AddBackEntry.
Another way that WPF applications can store data is with cookies, which are created, updated, and deleted by using the SetCookie and GetCookie methods. The cookies that you can create in WPF are the same cookies that other types of Web applications use; cookies are arbitrary pieces of data that are stored by an application on a client machine either during or across application sessions. Cookie data typically takes the form of a name/value pair in the following format.
When the data is passed to SetCookie, along with the Uri of the location for which the cookie should be set, a cookie is created in-memory, and it is only available for the duration of the current application session. This type of cookie is referred to as a session cookie.
To store a cookie across application sessions, an expiration date must be added to the cookie, using the following format.
A cookie with an expiration date is stored in the current Windows installation's Temporary Internet Files folder until the cookie expires. Such a cookie is known as a persistent cookie because it persists across application sessions.
You retrieve both session and persistent cookies by calling the GetCookie method, passing the Uri of the location where the cookie was set with the SetCookie method.
The following are some of the ways that cookies are supported in WPF:
WPF standalone applications and XBAPs can both create and manage cookies.
Cookies that are created by an XBAP can be accessed from the browser.
XBAPs from the same domain can create and share cookies.
XBAPs and HTML pages from the same domain can create and share cookies.
Cookies are dispatched when XBAPs and loose XAML pages make Web requests.
Both top-level XBAPs and XBAPs hosted in IFRAMES can access cookies.
Cookie support in WPF is the same for all supported browsers.
In Internet Explorer, P3P policy that pertains to cookies is honored by WPF, particularly with respect to first-party and third-party XBAPs.
If you need to pass data from one Page to another, you can pass the data as arguments to a non-default constructor of the Page. Note that if you use this technique, you must keep the Page alive; if not, the next time you navigate to the Page, WPF reinstantiates the Page by using the default constructor.
Alternatively, your Page can implement properties that are set with the data that needs to be passed. Things become tricky, however, when a Page needs to pass data back to the Page that navigated to it. The problem is that navigation doesn't natively support mechanisms for guaranteeing that a Page will be returned to after it is navigated from. Essentially, navigation doesn't support call/return semantics. To solve this problem, WPF provides the PageFunction<T> class that you can use to ensure that a Page is returned to in a predictable and structured fashion. For more information, see Structured Navigation Overview.
The NavigationWindow Class
To this point, you've seen the gamut of navigation services that you are most likely to use to build applications with navigable content. These services were discussed in the context of XBAPs, although they are not limited to XBAPs. Modern operating systems and Windows applications take advantage of the browser experience of modern users to incorporate browser-style navigation into standalone applications. Common examples include:
Word Thesaurus: Navigate word choices.
File Explorer: Navigate files and folders.
Wizards: Breaking down a complex task into multiple pages that can be navigated between. An example is the Windows Components Wizard that handles adding and removing Windows features.
To incorporate browser-style navigation into your standalone applications, you can use the NavigationWindow class. NavigationWindow derives from Window and extends it with the same support for navigation that XBAPs provide. You can use NavigationWindow as either the main window of your standalone application or as a secondary window such as a dialog box.
To implement a NavigationWindow, as with most top-level classes in WPF (Window, Page, and so on), you use a combination of markup and code-behind. This is shown in the following example.
This code creates a NavigationWindow that automatically navigates to a Page (HomePage.xaml) when the NavigationWindow is opened. If the NavigationWindow is the main application window, you can use the attribute to launch it. This is shown in the following markup.
The following figure shows the NavigationWindow as the main window of a standalone application.
From the figure, you can see that the NavigationWindow has a title, even though it wasn't set in the NavigationWindow implementation code from the preceding example. Instead, the title is set using the WindowTitle property, which is shown in the following code.
Setting the WindowWidth and WindowHeight properties also affects the NavigationWindow.
Usually, you implement your own NavigationWindow when you need to customize either its behavior or its appearance. If you do neither, you can use a shortcut. If you specify the pack URI of a Page as the StartupUri in a standalone application, Application automatically creates a NavigationWindow to host the Page. The following markup shows how to enable this.
If you want a secondary application window such as a dialog box to be a NavigationWindow, you can use the code in the following example to open it.
You may also be interested in...
Comments and Discussions