Navigation, orientation, and gestures for Windows Phone
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Windows Phone apps are based on a model where users can navigate forward through different views of content using links, and move backward using the hardware Back button. The goal of this model is to make it easier to create view-based apps that fit naturally into the Windows Phone page navigation model.
This topic contains the following sections.
- Pages and frames
- Navigating through pages
- Touch gestures
- Related Topics
Pages and frames
The page navigation model is a hub and spoke system. This means that unless you explicitly add links to other pages within your app, users must use the Back button to navigate back to a page that they viewed. This is similar to how a web browser displays and navigates webpage history.
The system tracks each page that a user has visited and places it in what is called the back stack so that when a user pushes the Back button, the last saved page in the back stack is served. There’s no limit to the number of pages that can be placed in the back stack.
For example, this means that a user navigating from page 1 (p1) to page 2 (p2) to p1 to p2 to page 3 (p3) to p1 creates a back stack of p1, p2, p1, p2, p3, p1. If the user modified content in the second instance of p2 in the back stack, but navigates back using the Back button to the first instance of p2 in the back stack, previous changes don’t appear on that page unless the page refreshes the data; the view is a snapshot of how the user saw that page at that point in navigation.
.gif "Important note") Important Note: |
|---|
Think carefully about implementing page-to-page links or buttons that could affect app navigation for the user and consider whether a page should be refreshed on entry. |
The following are definitions 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 doesn’t contain memorable content. It isn’t a user-recognizable collection of persistent state.
The following figure illustrates a hypothetical app structure with an assortment of pages and screens.
.png)
Sample app structure
About pages
An app may consist of the following pages:
Home page
Widgets page
Widgets details page (containing pivots)
Gadgets details page
Search page
Settings page
The splash screen and login screen aren’t pages, because the definition requires a page to have a user-recognizable collection of persistent state; splash screens are simply used as a placeholder before your app is started. For more info about splash screens, see Essential graphics, visual indicators, and notifications for Windows Phone.
The login screen also contains no state data because it asks only for credentials to be entered.
| Important Note: |
|---|
Not every view in Windows Phone requires a page. |
To help decide whether your UI should be a page, consider the following questions:
Would the user explicitly want to visit the page?
Would the user remember being on this page and want to return to it?
Pages hold discrete sections of content in apps and appear as separate screens to the user. You can create as many different pages as needed and construct their UIs to present content within an app and then provide navigation to those pages from the frame or page if you like. Simple apps may require only one page, while more complex apps may require many pages.
Full-screen view
You can also implement a full-screen view where the Status bar or App bar can optionally be displayed, but this must be explicitly defined using the visibility property, because the default is to not display them. The best practice for a full-screen view is to not display either so that users can focus on the content experience. Notifications and incoming calls are still displayed in full-screen mode, even if the Status bar or the App bar (or both) is hidden. For more info about the Status bar and App bar, see Essential graphics, visual indicators, and notifications for Windows Phone.
Note
Using the full-screen view setting will result in the user not having access to the clock. We recommend that you avoid using the full-screen view unless the content requires it.
Navigating through pages
Navigation in Windows Phone can be defined as a transition between pages.
However, not every transition step is considered to be true navigation—for example, when you move from the splash screen to the home page. Movements from non-pages can be referred to as transitions.
The following 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 rebinding the controls on your page to a new DataContext. Also, you can rebind by loading multiple instances of a UserControl inside the page, or using any other mechanism to display new content. You can choose how the user transitions forward and backward through the items. For instance, 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, users 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 you need to traverse the dataset 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 should put a reasonable limit on the items that you store. A key point is for the user to use the hardware Back button and return to the previous page instead of the previously viewed item.
The following table provides info about the common parts of an app that are considered to be pages.
Type of screen |
Page |
Description |
|---|---|---|
Splash screen |
No |
This is a transient part of the startup experience and the user can’t navigate to it. |
Panorama experience |
Yes |
A common home screen approach for Windows Phone apps. |
Details page |
Yes |
This page is common for data-centric apps parameterized through the query string. |
Pivot item |
No |
A pivot item is a smaller component of the Pivot control that is the place of interest for content. |
Login or error dialog |
No |
This is transient UI triggered by the app state, and the user doesn’t navigate to it directly. |
Item enumeration |
No |
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.
UI type |
Implementation |
Back button behavior |
Tombstone behavior |
|---|---|---|---|
Page |
PhoneApplicationPage control |
The Back button automatically goes back or exits the app. You shouldn’t override except in the case of data loss. |
Automatically remains on the back stack. |
Screen-transient UI |
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. |
Item enumeration |
UserControl |
N/A: hosted inside a parent page. |
The app should save the active item as appropriate. |
Thinking across orientations and axes
Users on the Windows Phone platform will expect some apps, especially those that feature video, maps, or game elements, to function in both portrait and landscape orientation.
They also expect navigation to operate across both the X and Y axes, and enjoy the sensation of being able to find new content by swiping across the phone’s screen, as well as from top to bottom. Plan ways in which your app can use both orientation and axes.
When designing an app that can run in landscape orientation:
Determine if your app will also run in portrait mode, and whether your app will be have one static orientation.
Landscape orientation is useful when users want to maximize screen space. You can rearrange controls or layout when the user turns the phone, to enhance the impression that the screen can now fit more content.
Landscape orientation is often used to present video content. If content consumption is the primary purpose of your app’s landscape mode, fade out controls and navigation to enrich the viewing experience.
Screen orientation
Windows Phone supports three views of screen orientation: portrait, landscape left, and landscape right.
In Portrait View: The page is vertically oriented with the steering buttons appearing at the bottom of the phone, and the height of the page is greater than the width. Portrait view is the default view for apps. Start is always presented in portrait view.
.png)
Screen orientations
In Landscape Views: The Status bar and App bar remain on the sides of the screen in landscape view. If the screen is in portrait view and the user a user slides out a horizontal hardware keyboard, the screen orientation will change to landscape if the app supports it.
The Status bar grows from 32 pixels in portrait view to 72 pixels in both landscape views, as measured from the side of the phone that has the power button toward the center of the screen.
Note
Apps cannot specify only left or only right landscape views if they support orientation changes.
The screen orientation will change based on the actions described in the following table.
Beginning screen orientation |
Rotating |
Ending screen orientation |
|---|---|---|
Portrait |
60 degrees left |
Landscape left |
Portrait |
60 degrees right |
Landscape right |
Landscape left |
60 degrees right |
Portrait |
Landscape right |
60 degrees left |
Portrait |
Landscape left or right, flat on a table |
30 degrees up |
Portrait |
There is no programmatic way to switch orientations because the orientation property is set to read-only, but it’s possible to set a fixed orientation. Screen transition animation effects are played when screen rotation occurs.
Apps can define a static orientation view using the SupportedOrientations property. Apps that support text input should assume a horizontal hardware keyboard is present and support landscape views.
Note
We recommend that you avoid creating text input–heavy landscape experiences.
In-app landscape view-aware system components are the Status bar, App bar, App bar menu, Volume/Ring/Vibrate display, Push notifications, and Dialogs.
Touch gestures
Touch gestures are the primary method for a user to interact with the Windows Phone UI. In Windows Phone OS, a touch gesture involves tapping or swiping one or more fingers on a touch screen.
The controls provided in the Windows Phone SDK are used as touch interaction elements. All touch interaction elements should always be properly sized for touch interaction. For more about touch targets, see Interactions and usability with Windows Phone.
The following single-touch and multi-touch gestures are supported in Windows Phone:
Single-touch
Tap
Double tap
Pan
Flick
Touch and hold
Multi-touch
- Pinch and stretch
Tap
A tap is a single, brief touch on the screen within a bounded area and back up off the screen again.
.png)
Tap
There are two behaviors associated with a tap gesture:
Finger down provides touch indication
Finger up executes the action
A tap also stops any type of content from moving on the screen.
Double tap
A double tap is two quick taps within a bounded area.
.png)
Double Tap
A double tap toggles between in and out zoom states of a control or an app. The app determines its current zoomed state and zooms in or zooms out accordingly. The app defines the zoomed-in and zoomed-out states.
Pan
A pan is a single finger placed down and moved across the screen in any direction. The pan gesture ends when the finger is lifted from the screen.
.png)
Pan
There are two behaviors associated with a pan gesture:
Content can be moved through direct manipulation. It will stick to and follow the movement of the finger. Controls or the app can decide what panning direction to support. This movement can be horizontal, vertical, or any other direction specified. If content is moved to an in-between state, the content should snap back to the closest state.
A pan can move or reorder a specific item. An item follows the finger and drops in the new location when the finger is lifted from the screen.
Flick
A flick is a single finger down moved rapidly in any direction and ends with the finger lifted up off the screen. A flick can follow a pan gesture.
.png)
A flick gesture moves content from one area to another area. The controls or the app can be configured to support specific flicking directional behavior. This can be horizontal, vertical, or another specified direction. If horizontal or vertical paths are specified, movements in other directions will be converted into vertical or horizontal movement.
Flick moves the whole canvas, but you can specify individual objects to be moved instead.
Pinch and stretch
A pinch and stretch is two fingers down within separate bounded areas followed by the fingers moving closer together (pinch) or further apart (stretch).
.png)
Pinch and Stretch
Pinch and stretch provides continuous zoom on content with the center of the zoom located at the center of the two fingers.
Touch and hold
Touch and hold is a single finger down within a bounded area for a defined period of time. The touch and hold gesture should generally be used to display a context menu or options page for an item.
.png)
Touch and Hold
Four touch points
Windows Phone supports four simultaneous user touch input points to enable unique app interactions. Simple examples would be games or musical instrument apps.
Screen touches 7 mm or larger in diameter are treated as unique touches when the edges of the touch are separated by 3.5 mm or more, and all gestures are supported.
Every touch point also adds additional processor load, so if you’re implementing more than two simultaneous touch input points, be aware of potential performance impacts. While Windows Phone supports up to 10 touch points, not all hardware screens will support more than four touch points.
See Also
Other Resources
In-app navigation for Windows Phone 8
How to perform page navigation on Windows Phone 8