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.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" />
A Page that is implemented in XAML markup has Page as its root element and requires the WPF XML namespace declaration. The Page element contains the content that you want to navigate to and display. You add content by setting the Page.Content property element, as shown in the following markup.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<Page.Content>
<!-- Page Content -->
Hello, Page!
</Page.Content>
</Page>
Page.Content 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 The Layout System) to contain and compose your content.
The child elements of a Page element are considered to be the content of a Page and, consequently, you don't need to use the explicit Page.Content declaration. The following markup is the declarative equivalent to the preceding sample.
<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation">
<!-- Page Content -->
Hello, Page!
</Page>
In this case, Page.Content is automatically set with the child elements of the Page 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.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.HomePage">
Hello, from the XBAP HomePage!
</Page>
using System.Windows.Controls; // Page
namespace SDKSample
{
public partial class HomePage : Page
{
public HomePage()
{
InitializeComponent();
}
}
}
To allow a markup file and code-behind file to work together, the following configuration is required:
In markup, the Page element must include the x:Class attribute. When the application is built, the existence of x:Class in the markup file causes Microsoft build engine (MSBuild) to create a partial class that derives from Page and has the name that is specified by the x:Class attribute. This requires the addition of an XML namespace declaration for the XAML schema (xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"). The generated partial class implements InitializeComponent, which is called to register the events and set the properties that are implemented in markup.
In code-behind, the class must be a partial class with the same name that is specified by the x:Class attribute in markup, and it must derive from Page. This allows the code-behind file to be associated with the partial class that is generated for the markup file when the application is built (see Building a WPF Application (WPF)).
In code-behind, the Page class must implement a constructor that calls the InitializeComponent method. InitializeComponent is implemented by the markup file's generated partial class to register events and set properties that are defined in markup.
.gif) Note: |
|---|
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 ApplicationDefinition item. The following is an application definition for an XBAP.
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.App" />
using System.Windows; // Application
namespace SDKSample
{
public partial class App : Application { }
}
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.
| Note: |
|---|
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 Windows Presentation Foundation. 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.
<Application
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.App"
StartupUri="PageWithHyperlink.xaml" />
In this example, the StartupUri 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.
.png)
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.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.HomePage"
WindowTitle="Page Title"
WindowWidth="500"
WindowHeight="200">
Hello, from the XBAP HomePage!
</Page>
The result is shown in the following figure.
.png)
Hyperlink Navigation
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 Hyperlink element, which is shown in the following markup.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
WindowTitle="Page With Hyperlink"
WindowWidth="250"
WindowHeight="250">
...
<Hyperlink NavigateUri="UriOfPageToNavigateTo.xaml">
Navigate to Another Page
</Hyperlink>
...
</Page>
A Hyperlink element requires the following:
The pack URI of the Page to navigate to, as specified by the NavigateUri attribute.
Content that a user can click to initiate the navigation, such as text and images (for the content that the Hyperlink element can contain, see Hyperlink).
The following figure shows an XBAP with a Page that has a Hyperlink.
.png)
As you would expect, clicking the Hyperlink causes the XBAP to navigate to the Page that is identified by the NavigateUri attribute. Additionally, the XBAP adds an entry for the previous Page to the Recent Pages list in Internet Explorer 7. This is shown in the following figure.
.png)
As well as supporting navigation from one Page to another, Hyperlink also supports fragment navigation.
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 Name attribute set. The following markup shows a named TextBlock element that contains a content fragment.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
WindowTitle="Page With Fragments" >
...
<!-- Content Fragment called "Fragment1" -->
<TextBlock Name="Fragment1">
Ea vel dignissim te aliquam facilisis ...
</TextBlock>
...
</Page>
For a Hyperlink to navigate to a content fragment, the NavigateUri attribute must include the following:
A fragment URI has the following format.
PageURI#ElementName
The following shows an example of a Hyperlink that is configured to navigate to a content fragment.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
WindowTitle="Page That Navigates To Fragment" >
...
<Hyperlink NavigateUri="PageWithFragments.xaml#Fragment1">
Navigate To pack Fragment
</Hyperlink>
...
</Page>
For a complete example of fragment navigation, see Fragment Navigation Sample.
| Note: |
|---|
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. |
.gif) Important Note: |
|---|
You can navigate to fragments in loose XAML pages (markup-only XAML files with Page as the root element) only if the pages can be browsed via HTTP. However, a loose XAML page can navigate to its own fragments. |
Navigation Service
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
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.
<Page
x:Class="SDKSample.PageWithNonDefaultConstructor"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="PageWithNonDefaultConstructor">
<!-- Content goes here -->
</Page>
using System.Windows.Controls; // Page
namespace SDKSample
{
public partial class PageWithNonDefaultConstructor : Page
{
public PageWithNonDefaultConstructor(string message)
{
InitializeComponent();
this.Content = message;
}
}
}
The Page that navigates to the Page with the non-default constructor is shown in the following markup and code.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.NSNavigationPage">
<Hyperlink Click="hyperlink_Click">
Navigate to Page with Non-Default Constructor
</Hyperlink>
</Page>
using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService
namespace SDKSample
{
public partial class NSNavigationPage : Page
{
public NSNavigationPage()
{
InitializeComponent();
}
void hyperlink_Click(object sender, RoutedEventArgs e)
{
// Instantiate the page to navigate to
PageWithNonDefaultConstructor page = new PageWithNonDefaultConstructor("Hello!");
// Navigate to the page, using the NavigationService
this.NavigationService.Navigate(page);
}
}
}
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.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.NSUriNavigationPage">
<Hyperlink Click="hyperlink_Click">Navigate to Page by Pack URI</Hyperlink>
</Page>
using System; // Uri, UriKind
using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService
namespace SDKSample
{
public partial class NSUriNavigationPage : Page
{
public NSUriNavigationPage()
{
InitializeComponent();
}
void hyperlink_Click(object sender, RoutedEventArgs e)
{
// Create a pack URI
Uri uri = new Uri("AnotherPage.xaml", UriKind.Relative);
// Get the navigation service that was used to
// navigate to this page, and navigate to
// AnotherPage.xaml
this.NavigationService.Navigate(uri);
}
}
}
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.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.NSRefreshNavigationPage">
<Hyperlink Click="hyperlink_Click">Refresh this page</Hyperlink>
</Page>
using System.Windows; // RoutedEventArgs
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService
namespace SDKSample
{
public partial class NSRefreshNavigationPage : Page
{
...
void hyperlink_Click(object sender, RoutedEventArgs e)
{
// Force WPF to download this page again
this.NavigationService.Refresh();
}
}
}
Navigation Lifetime
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.
.png)
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.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.CancelNavigationPage">
<Button Click="button_Click">Navigate to Another Page</Button>
</Page>
using System; // Uri, UriKind
using System.Windows; // RoutedEventArgs, MessageBox, MessageBoxResult
using System.Windows.Controls; // Page
using System.Windows.Navigation; // NavigationService, NavigatingCancelEventArgs
namespace SDKSample
{
public partial class CancelNavigationPage : Page
{
public CancelNavigationPage()
{
InitializeComponent();
// Can only access the NavigationService when the page has been loaded
this.Loaded += new RoutedEventHandler(CancelNavigationPage_Loaded);
this.Unloaded += new RoutedEventHandler(CancelNavigationPage_Unloaded);
}
void button_Click(object sender, RoutedEventArgs e)
{
// Force WPF to download this page again
this.NavigationService.Navigate(new Uri("AnotherPage.xaml", UriKind.Relative));
}
void CancelNavigationPage_Loaded(object sender, RoutedEventArgs e)
{
this.NavigationService.Navigating += new NavigatingCancelEventHandler(NavigationService_Navigating);
}
void CancelNavigationPage_Unloaded(object sender, RoutedEventArgs e)
{
this.NavigationService.Navigating -= new NavigatingCancelEventHandler(NavigationService_Navigating);
}
void NavigationService_Navigating(object sender, NavigatingCancelEventArgs e)
{
// Does the user really want to navigate to another page?
MessageBoxResult result;
result = MessageBox.Show("Do you want to leave this page?", "Navigation Request", MessageBoxButton.YesNo);
// If the user doesn't want to navigate away, cancel the navigation
if (result == MessageBoxResult.No) e.Cancel = true;
}
}
}
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 7
Conceptually, the journal operates the same way that the Back and Forward buttons in Internet Explorer 7 do. These are shown in the following figure.
For XBAPs that are hosted by Internet Explorer 7, WPF integrates the journal into the navigation UI of Internet Explorer 7. This allows users to navigate pages in an XBAP by using the Back, Forward, and Recent Pages buttons in Internet Explorer 7. The journal is not integrated into Microsoft Internet Explorer 6 in the same way it is for Internet Explorer 7. Instead, WPF renders a substitute navigation UI.
| Important Note: |
|---|
In Internet Explorer 7, 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 7 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 JournalEntry.Name attribute value.
The Page.Title attribute value.
The Page.WindowTitle 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 JournalEntry.Name is set, the other values are ignored.
The following example uses the Page.Title attribute to change the text that appears for a journal entry.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.PageWithTitle"
Title="This is the title of the journal entry for this page.">
...
</Page>
using System.Windows.Controls; // Page
namespace SDKSample
{
public partial class PageWithTitle : Page
{
...
}
}
Navigating the Journal Using WPF
Although a user can navigate the journal by using the Back, Forward, and Recent Pages in Internet Explorer 7, 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 BrowseBack navigation command.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.NavigationCommandsPage">
...
<Hyperlink Command="NavigationCommands.BrowseBack">Back</Hyperlink>
...
<Hyperlink Command="NavigationCommands.BrowseForward">Forward</Hyperlink>
...
</Page>
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.
.png)
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 true (the default is false). As shown in the following example, you can set KeepAlive declaratively in markup.
<Page
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="SDKSample.KeepAlivePage"
KeepAlive="True">
An instance of this page is stored in the journal.
</Page>
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.
.png)
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 Color ListBox in the following figure.
.png)
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. For an example, see Remember a Single Item of State Across Page Instances.
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. See Remember a Single Set of State Across Page Instances).
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. See Remember Multiple Sets of State per Page Instance).
Cookies
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.
Name=Value
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.
NAME=VALUE; expires=DAY, DD-MMM-YYYY HH:MM:SS GMT
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 (Internet Explorer 7, Microsoft Internet Explorer 6, and Firefox 2.0+).
In Microsoft Internet Explorer 6and Internet Explorer 7, P3P policy that pertains to cookies is honored by WPF, particularly with respect to first-party and third-party XBAPs.
Structured Navigation
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<(Of <(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.