Handling the Back Button in a Windows Phone app (XAML)

Unlike PCs, all Windows Phone devices have a Back button that allows the user to navigate backwards through the pages of your app. When the user has reached the first page of your app and presses the back button again, the OS will suspend your app and navigate the user to the experience before your app was launched. That experience may be another app or it may be the Start screen. This topic discusses how apps should handle the BackPressed event to provide a consistent user experience.

Handling the BackPressed event

The most important thing to know about the BackPressed event that is raised when the user presses the back button is that if your app does not handle the event, by setting BackPressedEventArgs.Handled property to true, the operating system will suspend your app and return the user to the previous experience. So, in the event handler, if your app can navigate backwards, you should do so and then set the BackPressedEventArgs.Handled property to true. If your app is at its first page and can't navigate backwards, you should not handle the event and the operating system will suspend your app. Fortunately, the logic for this is provided by default in the project templates for Windows Phone apps. The following code is provided in the App.xaml.cs file.

private void HardwareButtons_BackPressed(object sender, BackPressedEventArgs e)
{
    Frame frame = Window.Current.Content as Frame;
    if (frame == null)
    {
        return;
    }

    if (frame.CanGoBack)
    {
        frame.GoBack();
        e.Handled = true;
    }
}

Handling back navigation for multiple launch points

An app can be launched in several ways in addition to it's primary tile; secondary tiles, toast notifications, file and URI associations. It is important to consider the user's navigation experience when you use multiple launch points. The Back button should always take them back through the pages they have just viewed. Consider the following scenario:

• The user launches your app from the primary tile, views your default start page and navigates forward through a few pages in your app.
• The user hits the Start button and launches another app and then hits the Start button again, returning to the Start screen.
• Now the user launches your app from a secondary tile that launches your app to a specific page using a deep link.
• The user presses the Back button.

In this case, the user should be returned to the Start screen where they launched your app from the secondary tile because this was the previous experience for the user. You should not allow the user to navigate backwards through the page history from the session launched from the primary tile. This is a disjointed, inconsistent experience that can cause the user to be confused about the function of the Back button.

Use these guidelines to help you design the suspend and resume behavior of your app.

Do

Handle the Back button if you want to navigate inside your app

Do handle the Back button to dismiss transient UI such as message boxes, menus, etc. Do handle the Back button to navigate to the previous page on the navigation history for the current launch point.

Ensure proper Back button behavior when your app supports multiple launch points

Consider creating new instances of navigation journals for launch points such as primary and secondary tiles, file and URI Associations. Save the activation parameters each time the app is launched and compare when the app is being re-launched. If the app is being re-launched with different parameters, consider creating a new navigation history. Do this by creating a new Frame. This will allow the user to quickly navigate back to the launch point when the hardware Back key button is pressed. To maintain a small memory footprint, the Navigation history for launch points other than the Primary tile doesn’t need to be saved when the app is suspended.

Use these guidelines to avoid creating a poor user experience.

Don't

Don’t handle the BackPressed event on your app’s top page

Allow the operating system to remove the app from foreground and suspend it by not handling the BackPressed event when the app is presenting the top page for the current navigation journal.

Don’t allow your app to go over memory limits because of too many navigation history instances.

Monitor your app’s memory and keep only the navigation history instances that the user would be frustrated to lose when the app is relaunched.