App page model for Windows Phone
February 03, 2014
Applies to: Windows Phone 8 | Windows Phone OS 7.1
Windows Phone apps comprise pages that exist on a navigation stack, and these pages can be accessed by the user using the hardware Back button. Excessive page use in your app can lead to a cumbersome navigation stack, causing a number of issues including decreased performance and unreliability. Developers must abide by a navigation model that makes effective use of the pages in their app, and limit page usage when alternatives can be implemented. This topic provides best practices and guidance for creating an effective page model for your app.
This topic contains the following sections.
A Windows Phone app can be seen as a collection of pages, screens, or a combination of both elements. The following are definitions of “page” and “screen” in the context of the app page model for Windows Phone:
Page - A user-recognizable collection of persistent state. It can be viewed as a page that contains info, memorable content, or links to other pages.
Screen - A general UI screen such as a pop-up window, dialog box, or splash screen that does not contain memorable content. It is not a user-recognizable collection of persistent state.
The following figure illustrates a hypothetical app structure with an assortment of pages and screens:
From the figure, you can see that an app consists of the following pages:
Widgets Details Page (containing pivots)
Gadgets Details Page
The splash screen and login screen are not pages, because the definition of a page requires that it have a user-recognizable collection of persistent state. For example, the splash screen does not contain state. It is simply used as a placeholder before your app is launched. The login screen also contains no state data because it asks only for credentials to be entered. When determining whether your UI should be a page, you can ask the following questions:
Would the user explicitly want to visit the page?
Would the user remember that they were on this page and want to return to it?
The splash screen and the login screen do not fit the above criteria and therefore are not considered pages.
You will notice the circular arrows on both the Widget Details Page and the Gadgets Details Page. For the preceding scenario, this shows that you can transition from one “widget” to another or one “gadget” to another, respectively, without going to a new page. This behavior is similar to the behavior in the Microsoft Outlook app, in which users can switch between previous and next mail inside the same window by clicking the arrows.
Navigation in Windows Phone can be defined as a transition between pages. As illustrated in the figure with arrows, there are multiple transition steps present including transitioning from the home page to the widgets list page or from the search page to the gadget details page. However, not every transition step is considered to be true navigation: for example, when you move from the splash screen to the home page, or you make multiple moves from the login screen to any other screen. The reason once again is that neither of these screens are pages. Movements from non-pages can be referred to as transitions.
With the concepts of pages, screens, and navigation defined in Windows Phone, you must architect your app to handle various scenarios without additional page usage if possible. This section provides the best practices for using an effective page model:
Screens and Non-Navigational Transitions - For transient UI, such as the login screen, you can use the Popup control to display content that partially covers the screen without implementing separate screens that would require full navigation. You can add the BackKeyPress event to your code and set e.Cancel to true while the pop-up window is visible to enable users to use the Back button to close the dialog box.
Multiple Content Views - For pages that display multiple sections of content, you can transition between different pieces of content without using navigation by simply re-binding the controls on your page to a new DataContext. Also, you can re-bind by loading multiple instances of a UserControl inside the page, or using any other mechanism to display new content. You can choose the method through which the user transitions forward and backward through the items. For example, you can consider using the previous and next app bar buttons. However, we recommend that you avoid overusing the Back button for local transitions.
Saving State and Tombstoning - You can save a local history of transitions that occur in a given page, so if an app is tombstoned, the user can retrace their steps. For simple scenarios like previous or next browsing, all you need to do is save the page State in the current index. Doing this, along with the use of the NavigationContext API, should provide all the info that you need to traverse the data set when returning from a tombstoned state. For apps that have a more complex local transition history, such as free-form browsing of linked items, you may choose to store some of that history in page state, but you will want to put a reasonable limit on the items that you store. A key point is for the user to use the hardware Back button and have them return to the previous page. They should not return to the previously viewed item. For more info, see Launching, resuming, and multitasking for Windows Phone.
Navigation Back Stack - Pages in the back stack are kept in memory. Apps should minimize the memory used on pages in the back stack by, for example, releasing large images, releasing cached data, and so on. For more info, see Frame, page, and navigation features in Windows Phone.
The following table provides info about the common parts of an app that are considered as pages.
Type of screen
This is a transient part of the startup experience and the user cannot navigate to it.
A common home screen approach for Windows Phone apps.
This page is common for data-centric apps parameterized through the query string.
A pivot item is a smaller component of the pivot control that is the place of interest for content.
Login or Error Dialog
This is transient UI triggered by the app state and the user does not navigate to it directly.
This is used for browsing similar content as an “in-place” activity and not as a means of navigation.
The following table summarizes approaches that you can use to deal with various types of UI implementation.
Back button behavior
The Back button automatically goes back or exits the app. You should not override except in the case of data loss.
Automatically remains on the back stack.
Pop-up or a child window
The app should override to cancel the pop-up window. The on-screen keyboard and MessageBox control automatically cancel themselves when the Back button is pressed.
The app should dismiss or cancel the pop-up window during navigation.
N/A: hosted inside of a parent page.
The app should save the active item as appropriate.