I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.
In my first post in this series I discussed the Windows Phone application lifecycle. In this post I’ll take a look at the Windows Phone navigation model.
Key Classes
Let’s start by taking a look at some of the key classes involved with the Windows Phone navigation model.
When it comes to working with the Windows Phone navigation model, there are six classes you need to be familiar with.
The first two classes reside in the System.Windows.Navigation namespace, and if you’ve worked with Silverlight navigation applications in the past, they should be familiar to you. The first class is the NavigationService class. As with the Silverlight implementation, this class provides the various methods, properties, and events required to support navigation within your Windows Phone applications. The next class is the NavigationContext class. This class represents the state of navigation operations. Of particular importance is the QueryString property as this enables you to pass data between pages in your Windows Phone applications.
The next two classes you’ll need to familiarize yourself with are in the Microsoft.Phone.Controls namespace. In Silverlight navigation applications you may have used the Frame class. Similar to the Silverlight Frame implementation, the PhoneApplicationFrame class is nothing more than a control that supports navigating to and from pages. Whereas the Frame class in Silverlight supports navigation to Page objects, the PhoneApplicationFrame class in Windows Phone supports navigation to PhoneApplicationPage objects. The PhoneAppliationPage class simply encapsulates navigable content.
The last two classes reside in the Microsoft.Phone.Shell namespace, and, while they are not directly involved with navigation, they are important to be aware of as they are available for use by pages in your application. First is the SystemTray. The SystemTray or “Status Bar” (as sometimes referred to in the documentation) provides the user with system-level status information, such as how much battery power is left, whether or not the device is connected to a Wi-Fi network, etc. Last is the ApplicationBar. The ApplicationBar provides a common place where the user can access the most common tasks in your application, such as save, edit, etc., via buttons or a single level menu.
Let’s get a better understanding of how some of these key classes come together in the Windows Phone user interface. First we have the PhoneApplicationFrame, which you can think of as the container of your application. For Windows Phone applications, one one frame is available to the application. If you drill into the code that gets generated by Visual Studio in the App.xaml.cs file that is added to your application, you’ll see a property called RootFrame…
…which gets set to a new instance of the PhoneApplicationFrame class when the application is launched or reactivated. The RootVisual for the application, which is a UIElement, is then set to the RootFrame.
When looking at the PhoneApplicationFrame for an application, you can be break it up into three regions:
The first reserved region is for the SystemTray. This is where the user will see the strength of their cell connection, whether or not the device is connected to a Bluetooth device, etc. You can toggle the visibility of the SystemTray on a page-by-page basis.
The second reserved region is the ApplicationBar. This is where users can access the most common features in your application. You can have up to four buttons on the menu bar as well as menu items that can be displayed when the ApplicationBar is expanded for some less common features of your application. Your are not required to use the ApplicationBar in your applications, and you can have page specific implementations of the ApplicationBar within your application.
The last region, and the one you will be primarily concerned is the content region. This is where your pages are rendered.
Performing Navigation
So, how do we actually perform navigation in a Windows Phone application. Well, there are a couple of different ways you can do it. If you want to perform navigation directly from your UI, you can add a HyperlinkButton control and set its NavigateUri property to the page you want to navigate to like this:
If you want to perform navigation in the code-behind file for your PhoneApplicationPage, you can use the NavigationService property of the PhoneApplicationPage, and call the Navigate method, using the appropriate Uri like this:
Pages vs. Screens
OK, now that we have an understanding of the core classes involved with navigation in Windows Phone applications, lets examine the concepts of pages and screens. Understanding the differences of pages and screens is important when designing the logical flow of your applications. Lets use a simple application to help understand the difference. Lets say we have an application that enables us to view a list of recipes, view the details of a specific recipe, as well as search for recipes. Here’s what the structure, when implemented, may look like:
I’ll first want to display something to distract the user while my application loads book data as the data may be coming from isolated storage or a web service. This is the splash screen. Once the data is loaded I’ll want to display the list of recipes. From there, the user can do one of two things:
- The user can view the details of a specific recipe
- The user can search for a recipe
After a search is performed, the user can either:
- View the details for a recipe displayed in the search results or
- Go back to the list of recipes
Simple enough, right?
At this point, you’re probably asking yourself, “OK, so what’s the difference between pages and screens?” Well to answer that question, we need to talk about what happens when the user presses the hardware back button that is standard on every Windows Phone device. When the user clicks the hardware back button within your application, the application will navigate to the last PhoneApplicationPage entry in the navigation history for the application. If there is no entry, the application will exit.
Lets look at a scenario from our app where the user performs multiple searches, looks at the details for several recipes, and goes back to the main recipe list. If each of these functions corresponded to a page we would end up with a navigation history that looks like this:
What is of importance to us is the number of entries we have in our navigation history for the recipe search. However, if we really think about it, we need to ask ourselves if the Recipe Search functionality should be a part of our navigation history. After all, recipe search doesn’t contain any persistent state (unless we were implementing a mechanism to save searches, but that’s outside of our current scope). This gets us to the fundamental difference between pages and screens.
Pages contain persistent state, whereas screens do not
Our navigation history should only contain pages, not screens.
So, if we take another look at the structure of our application, we can now identify which items should be pages, items we want in our navigation history, and which items should be screens and not part of our navigation history or “back stack”:
Since our recipe list and recipe details items contains persistent state, we can label them as pages. These will be implementations of the PhoneApplicationPage class. Because our splash and recipe search items don’t contain persistent state, we can label them as screens. These will have different implementations:
- The splash screen will be nothing more than static jpeg
- The recipe search screen will be implemented as a pop up
By clearly defining which items in our application are pages and which items are pages, we also create a more manageable and user friendly navigation history.
A history which only contains items with persistent state, which, more often than not is what the user is really concerned with.
That’s it for the Windows Phone navigation model. Next up we’ll take a deeper look at the ApplicationBar.
Previous posts in this series
Hey there! My name is Adam, and I'm a Technical Evangelist at Microsoft where I spend time focusing on Windows, Windows Phone, and Windows Azure.
Pingback: Windows Phone Essentials #3 – Application Bar « Think first. Code later.