Navigation Topologies Overview
In WPF, content that can be navigated is typically constructed using pages (Page) and hyperlinks (Hyperlink), and is navigated using uniform resource identifiers (URIs) (Pack URIs in Windows Presentation Foundation). A navigation topology is an arrangement of pages whose structure is determined by how the pages are navigated between. The following example, although simplistic, illustrates a navigation topology:
<Page xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" WindowTitle="Page1">
<Hyperlink NavigateUri="Page2.xaml">Navigate to Page 2</Hyperlink>
</Page>
<Page xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" WindowTitle="Page2">
<Hyperlink NavigateUri="Page1.xaml">Navigate to Page 1</Hyperlink>
</Page>
Here, each page can be navigated to from a hyperlink on the other. Furthermore, the navigation topology is defined in Extensible Application Markup Language (XAML), at compile-time, which produces a rigid topology.
Although perfectly suitable in some scenarios, this simplistic type of navigation topology has two key issues. First, the navigation topologies of some applications may not be known until run time. Second, this topology doesn't scale well in the face of more complex browsing scenarios, particularly those that involve multiple physical pages to perform a single logical function.
This topic provides in introduction into the use of page functions and structured navigation to create both fixed and adaptive types of navigation topologies that are composed of multiple pages.
.gif) Note: |
|---|
Before reading this topic, you should be familiar with the concept of structured navigation in WPF using page functions. For more information on both of these topics, see Structured Navigation Overview. This topic contains the following sections.
|
Structured Navigation Topologies
Structured navigation provides a framework against which you can construct specific types of navigation topologies that are either hard to recreate using unstructured navigation, or can't be created at all. A navigation topology is the structure that reflects the organization of pages within an application and how they are navigated between. There are two basic types of navigation topologies:
Fixed Topology: the structure is defined at compile time, and does not change at run time. Fixed topologies are useful for structures that require navigation through a fixed sequence of pages in either a linear or hierarchical structure.
Dynamic Topology: the structure is defined at run time in response to data that is collected by the application from the user, the application, or the system. Dynamic topologies are useful for applications that have tasks whose pages are navigated in different orders based on user input or external data.
A navigation topology for an application might be either completely fixed, completely adaptive, or some combination of both. Irrespective of the resulting topology that you use, the user experience should be presented as a seamless sequence of page navigations like the one shown in the following figure:
.png)
The following sections give simple examples of three of the most common topologies, including fixed linear, fixed hierarchical, and adaptive. You can extend or combine them to create more complex navigation topologies as required.
Navigation over a Fixed Linear Topology
A fixed linear topology is a structure that is analogous to the structure of a wizard that has one or more pages that are navigated to and from in a fixed sequence.
The standard behaviors of a fixed linear topology application consist of the following:
Navigating from the calling page to a launcher page that initializes the task and navigates to the first task page. Note that a launcher page (a UI-less PageFunction) is not required; a calling page can call the first task page directly. Using a launcher page can, however, simplify the task initialization process, particularly if the initialization process is non-trivial.
Users can navigate between pages by using both Back and Forward buttons, which implement navigation programmatically.
Users can navigate using hyperlinks, which implement navigation declaratively.
Users can navigate between pages using navigation history.
Users can cancel the task from any task page using a Cancel button.
Users can accept the task on the last task page using a Finish button.
If a user cancels the task, the task returns an appropriate task result and does not return any data.
If a user accepts a task, the task returns an appropriate task result and returns the data collected by the task.
When the task is completed, whether accepted or canceled, the pages that comprise the task are removed from navigation history, to make the task atomic and isolated.
A fixed linear topology can be constructed from pages and hyperlinks, if those pages do not need to pass data between them. However, wizards gather data from users over one or more pages and, in this case, a fixed linear topology should be constructed with page functions, for structured navigation and data passing. The following figure shows the high-level structure and flow of a fixed linear topology application:
.bmp)
Dynamic Navigation over a Fixed Hierarchical Topology
In some applications, the order in which pages can be navigated is hierarchical, such that one page may allow navigation to two or more other pages. In some cases, the decision as to which page to navigate to is determined at run time, whether by the application or by the user. To support this style of application, the application's navigation topology is organized into a fixed hierarchy. At run time, at each junction in the hierarchy, where one page may be able to navigate to two or more other pages, the page will dynamically gather the appropriate data it needs to make the decision about which page to navigate to.
Because the order in which the pages in a fixed hierarchical structure are navigated is determined dynamically at run time, the user experience should have the same behaviors as those exhibited by an application with a fixed linear topology:
Navigating from the calling page to a launcher page that initializes the task and navigates to the first task page. Note that a launcher page is not required; a calling page can call the first task page directly. Using a launcher page can, however, simplify the task initialization process, particularly if the initialization process is non-trivial.
Users can navigate between pages by using both Back and Forward buttons, which implement navigation programmatically.
Users can navigate using hyperlinks, which implement navigation declaratively.
Users can navigate between pages using navigation history.
Navigation back through navigation history allows users to dynamically change the navigation path.
Users can cancel the task from any task page using a Cancel button.
Users can accept the task on the last task page using a Finish button.
If a user cancels the task, the task returns an appropriate task result and does not return any data.
If a user accepts a task, the task returns an appropriate task result and returns the data collected by the task.
When the task is completed, whether accepted or canceled, the pages that comprise the task are removed from navigation history, to make the task atomic and isolated.
While a hierarchical topology can be constructed from both pages and page functions, the latter should be used when the traversal of a set of pages is a task that passes data between the pages, and whose pages need to be removed from navigation history upon completion.
The following figure shows a set of pages from which a user will determine the order of navigation at run time:
.png)
The next figure illustrates the actual path taken:
.png)
Navigation over a Dynamically-Generated Topology
When the order in which two or more task pages are navigated can only be determined at run time, whether by the user, the application, or external data, the navigation topology cannot be hard-coded. Instead, the application dynamically generates the order of page navigation at run time. For the user, as with the other navigation topologies, the user experience is the same as it is for the previous topologies:
Users can navigate between pages by using both Back and Forward buttons, which implement navigation programmatically.
Users can navigate using hyperlinks, which implement navigation declaratively.
Users can navigate between pages using navigation history.
Users can cancel the task from any task page using a Cancel button.
Users can accept the button on the last task page using a Finish button.
If a user cancels the task, the task returns an appropriate task result and does not return any data.
If a user accepts a task, the task returns an appropriate task result and returns the data collected by the task.
When the task is completed, whether accepted or canceled, the pages that comprise the task are removed from navigation history, to make the task atomic and isolated.
The pages of a dynamically generated topology don't have to be either pages or page functions. However, page functions should be used when the traversal of a set of pages is a task that passes data between the pages, and whose pages need to be removed from navigation history upon completion.
The following figure shows a set of pages from which a user will determine both the pages that are navigated and the order in which they are navigated at run time:
.bmp)
The next figure illustrates the actual path taken:
.bmp)
See Also
Reference
Page
PageFunction
NavigationService