Integrating with the Browser History
In addition to the view changing, you may notice the following when you navigate between views in your application:
- The URI in the address bar changes.
- The status of the browser history buttons is updated.
- The browser's title bar is changed to display the title of the view.
These changes occur because the navigation framework integrates with the browser's journal, which maintains the browser's history. When each view is navigated to in your application, it will be added to the browser's journal, which enables you to navigate through views you have previously visited, using the browser's Back and Forward buttons as if the views were standard HTML web pages.
How the browser maintains these navigation events in its history depends on which browser the user is using. For example, Internet Explorer's history only displays a single entry for the web page hosting the Silverlight application, while Firefox displays each view within the Silverlight application in its history.
Note In Chapter 16, we'll discuss having the application run outside the browser. In that situation, the browser Back and Forward buttons are not available, nor is the address bar (since it's not running within a browser). However, a navigation journal is still maintained within the application, and if it's important for the users to have the ability to navigate backward and forward through their navigation history, you can detect whether the application is running outside of the browser (checking the value of the App.Current.IsRunningOutOfBrowser property) and display your own Back and Forward buttons to provide this functionality via the GoBack and GoForward methods. You will want to make use of the CanGoBack and CanGoForward properties to check whether each operation is valid before attempting it, because an exception will be raised if the operation cannot be performed.
Generally, you would only have one Frame control in a XAML file, but you can actually host more than one Frame if you wish, and views can also host other “subviews” in a Frame. However, only the top-level Frame can integrate with the browser's journal.
You can use the JournalOwnership property on the Frame control to control whether or not the Frame control integrates with the browser's journal. Valid values for this property include:
Automatic: This will choose the correct option based on whether a higher-level frame is already using the browser's journal. This is the default value.UsesParentJournal: The Frame control will integrate with the browser's journal, as previously described.OwnsJournal: With this option, the Frame can still navigate between pages, but moving backward and forward through the history must be done via code. Frames that don't integrate with the browser's journal will not respond to deep links entered into the browser's address bar, and the URI displayed in it will not change as pages are navigated between in that Frame. If the Frame needs to track the history of loaded views, it will need to track them itself.
Note An example scenario where you might use multiple Frame controls in a view might be where you have a dashboard containing multiple content sections and each content section allows the user to navigate between sub-views when drilling down on data.