Build WINRT-based WP8.1 App 01: Page navigation and page cache mode

This post focuses on the Windows runtime-based Windows Phone app page navigation-related knowledge, mainly divided into the following aspects:

• Window, frame, and Page overview
• Jump between pages
• Working with physical back keys
• Caching of pages

Window, frame, and Page overview

WINRT-based Windows Phone 8.1, each app has only one window.

Each window has its own frame and navigation stack, as well as its own page.

There is a frame in the window, and 100% is full of visible areas, and the frame is usually a visible area of 100% full window.

All pages are included in the frame, and the frame is responsible for navigating between them. The page contains its own content, including the XAML file and the associated Code-behind code.

Although the app's window typically contains only one frame, we can embed the frame in the page, but this is not common in mobile apps.

The frame is usually created when the app starts, and you can refer to the following code:

To simply analyze the above code, the Onlaunched function exists in the App.xaml.cs file and contains some logic code to start. The onlaunched function places the frame object in the current window, then calls the Frame.navigate (type,object) function, creates an instance of the page, and puts the page into the frame. When you jump forward or backward through the page, frame records the history of the jump, and you can view the history of the jump navigation through the Frame.backstack property (return type:ilist<pagestackentry>).

Jump between pages

When you need to jump to another page, call the Navigate function of the frame. This function places the current page in the back stack and can pass any parameters to the new page.

In addition, we can put buttons, hyperlinks, AppBar buttons or other controls in the page, remove the current page from the code, and let the user jump back to the previous page. We can make use of the Frame.goback () function.

The following is an analysis of how the implementation works: usually the Windows Phone app maintains a jump history stack, just like a Web browser. The application usually launches to MainPage.xaml, so it is the first item in the stack, and when it jumps to Secondpage.xaml, Secondpage.xaml is put into the stack, and when Frame.goback is called, Secondpage is popped from the stack and then back to MAINP Age

Working with physical back keys

A typical feature of the Silverlight-based Windows Phone user experience is that when the user presses the back key, the user knows that it cancels the current view and returns to the previous view. In Windows Phone Silverlight, the physical back key causes a forward jump inside the app. If the user is currently on the startup page, the Silverlight framework-based Windows Phone app will be turned off.

In the Windows runtime-based Windows Phone app, the behavior is slightly different, by default pressing the physical back key causes a backward jump to the previous app, which is not related to the page on which the user is currently in the app. So the developer needs to rewrite the default behavior so that it jumps inside the app. Also, if the user presses the physical back button on the app's launch page, it will cause a jump to the previous app, but unlike the Silverlight framework, the current app is suspended instead of being closed .

What about the above, then how do we handle the back key?

If you use an empty project template, the new project file does not have any processing code for the back key, and if you want to implement a simple fallback jump, you can take advantage of the following code.

In the code above, the Backpressed event is overridden in the App.xaml.cs file, and the Backpressed event is used to determine if a jump forward can be made, and if so, return to the previous page.

If you create a project using a non-empty project template (for example: Hub app or pivot app), the new project and the correct back key processing, we can find the corresponding handler function in the Navigationhelper class in the common folder of the project.

Alternatively, you can handle the back key separately on a single page, which is similar to the code above, and is no longer cumbersome to restate.

Caching of pages

First, let's describe a common scenario: when a user first accesses a page, the page is new and no data is brought in. The user interacts with the page and populates some data. When you navigate forward to another page and then navigate back. Usually the user expects the page to be in the same state as when it leaves. So how do we make sure that the page is the same state as when we left?

We can take advantage of the page's Navigationcachemode property.

When you use navigationcachemode.disabled , a new instance is created when you jump forward, and the state of the original page is lost.

When using navigationcachemode.enabled or Required , cached pages can be reused and the state of the original page is retained.

Here is a detailed description of the function of the Navigationcachemode attribute three values:

• Navigationcachemode.disabled: The new instance of the page will be generated regardless of whether the pensive is forwarded forward;
• Navigationcachemode.enabled: The page is cached, but when the cache limit is reached, the cached instance is discarded (the upper limit is determined by the Frame.cachesize property, which is 10 by default);
• Navigationcachemode.required: The page is cached and the cached instance is not limited in quantity;

You can also use the Navigationhelper class to save/Restore page state. Usually we call Navigationhelper's loadstate function in the page's Onnavigatedto function event to restore the state of the pages, In the Onnavigatedfrom function event of page, call Navigationhelper's savestate function to save the page state.

Reference articles

1. navigating between pages (XAML)
2. QuickStart: Navigating between Pages (XAML)
3. building Apps for Windows Phone 8.1: (in) page Nav Igation and Data Binding in Windows Runtime Apps