[Translation] WP7 Quickstart-Article 11th-running programs in the background (tombstone effect)

Source: Internet
Author: User

Note: This articleArticleIt is translated from Microsoft's official WP7 Quickstart Article 11th, which describesProgram. Some of the content is added to your understanding and expression habits. The main purpose of this series is to practice English, and to give yourself an understanding of WP7 development as a bi developer. For some improper translations, I hope you will point out criticism and correction]

Note: tombstoning was used in the circuit industry earlier.Tombstone Effect, That isSmall slice(Such as resistors or capacitors)Surface mount devices may differ in solderability or Solder strength between metal heads and plate pad. After infrared or hot-air welding, occasionally, one end is welded and the other end is pulled up. It is called the tombstone effect or the suspension effect (drawbridging effect)Manhattan Effect)And so on.

In order to avoid the taboo translation in our language, follow this translation method .]

Windows Phone allows only one application to run at a time. When you navigate from one program to another, the operating system terminates the program. To provide a better user experience, the operating system provides a way to help you restore the program to its previous display status when the program is re-activated. This article describes the process of the tombstone effect, the application lifecycle, and how to restore the status.

It mainly includes the following parts:

Tombstone effect Overview

Application Lifecycle

Application Status

Page Status

Best practices

Tombstone effect Overview

The Windows Phone operating system does not allow any third-party program to run in the background. That is to say, only one program can be run at a time. The reason for this is to keep the battery time and ensure a consistent and fast response to the user interface. [Translator's note: you can understand this point, but I believe that the next Microsoft version will solve this problem.] When you navigate from the program to another program, the Windows Phone anti-activating Program, this is the tombstone utility. It is a process in which the program is reversed when the user is navigating to another program in the operating system. In the following cases, the program is deactivated:

1. incoming calls.

2. The phone enters the sleep state.

3. the user clicks the start or search button, or receives a notification.

4. The program calls an external task.

When the program in the tombstone effect is re-activated, it must look exactly the same as before, which will give the user a better experience. Ideally, users should not feel that this is a completely new process to be activated from the tombstone effect. For example, suppose you open a long page and have read a lot of content in a scroll down. Then you navigate to another page. When you return from this page, the previous scrolling position disappears and returns to the top of the page. On the other hand, when you fill in a form with a lot of content, you obviously do not want to see that you have encountered a small error and all the entered content is lost.

To solve this problem, the operating system maintains some state information about the program in the memory after the program is deactivated, this information can be used to restore the rendering status when the program is re-activated.

Windows Phone provides methods and events to restore program and page status information. This article mainly describes these methods and events.

Application Lifecycle

Because the Windows Phone program can be converted into a tombstone, you need to understand the life cycle of the program. The operating system provides four events to represent the state of the program in its lifecycle. You can take appropriate actions in the program. These events are launching, closing, deactivated, and activated, showing the occurrence of these four events.

Launching-Start running

After the program is started from the Start Screen, it can be said that it has been executed. No matter when the user runs the program, a new instance will be created. After the program is started, the launching event is triggered. The followingCodeIs the launching event part of the app. XAML. CS file.

// Code to execute when the application is launching (eg, from start)

// This code will not execute when the application is reactivated

Private void application_launching (Object sender, launchingeventargs E)

{

}

You can add some settings and other persistent data in this event to reduce the amount of data to be saved when the program state changes. This is optional. It is unnecessary if the program has less persistent information.

Closing-Close

After you click the back button of the device, the navigation model allows the user to return, or navigate to the previous page of the program, or even cross-program rollback. However, once the user enters the first page of the program, pressing the back button will trigger the closing event and terminate the program. Persistent data can be stored in the event to the independent village crude. The following is the closing event code section in APP. XAML. CS.

// Code to execute when the application is closing (eg, user hit back)

// This code will not execute when the application is deactivated

Private void application_closing (Object sender, closingeventargs E)

{

}

Anti-activation

When another program runs on the front end, the current program can be reversed (not closed), for example, incoming calls, or the user clicks the start button. In this case, the deactivated event is triggered. The following code is the deactivated event section in the app. XAML. CS file.

// Code to execute when the application is deactivated (sent to background)

// This code will not execute when the application is closing

Private void application_deactivated (Object sender, deactivatedeventargs E)

{

}

Unlike program shutdown, anti-activation will bring the program into the tombstone effect stage. That is to say, although it is not running, the operating system retains a program record to promote a series of State information of the program. The user is likely to return the program to the tombstone effect stage, that is, reactivate the program. Therefore, you need to use the phoneapplicationservice. state attribute in the deactivated event processing code to store the current information of the program. The stored data is short-term state data, that is, it will help the program to re-establish the State before it is reactivated. Because the tombstone-oriented program may not be re-activated, you should also save the persistent information of the program to the independent storage. All the operations in the deactivated event must be completed within 10 seconds. Otherwise, the operating system terminates the program. Therefore, when your program has a large amount of persistent data, it is best to save some increments when the program is running.

It is also possible that the program is not affected by the tombstone effect, for example, the user presses the start button and then quickly and continuously presses the back button. For this reason, it is best not to perform any destruction operations in the deactivated event processing code. After the deactivated event is processed, the program continues running without calling activated.

Activated

After the program is deactivated and the tombstone effect is applied, you can click the back button to return to the program. When the user returns to the tombstone-oriented program, the program will be re-activated and the activated event will be triggered. You can use this event to read the value of the user interface during anti-activation from the phoneapplicationservice. state attribute. The following code is the activated event section in APP. XAML. CS.

// Code to execute when the application is activated (brought to foreground)

// This code will not execute when the application is first launched

Private void application_activated (Object sender, activatedeventargs E)

{

}

Application Status

The Application State is the State of the program rather than the state of a specific page. If you use global data, such as logon information or program setting information, it is used in many pages of the program. This state information is considered part of the application. After the program is re-activated from the tombstone effect, if you do not save it, the data will be lost. The launching, closing, deactivated, and activated events are usually used to initialize and maintain the application status. After the program is converted into a tombstone, the operating system saves the content through the phoneapplicationservice. state attribute. You can store application-level status information in the phoneapplicationservice. state attribute of the deactivated event, and then process data through phoneapplicationservice. State in the activated event.

If the program has persistent data, you can consider storing the data into an independent storage. The independent storage is an independent sandbox located in the file storage location on the device, similar to the desktop file system. When data is stored in an independent storage, it takes some time to read the data, so you should only store the data that needs to be stored on the device for a long time and the object that cannot be serialized. In addition, you need to carefully consider where to use the independently stored code to minimize the latency of compression. For example, a program needs to store a lot of data. When the program exits, it should avoid storing a large amount of data at a time, instead of incremental storage. Generally, they should be stored in the independent storage area as soon as possible or as soon as possible before they are available.

Page Status

The page status is the visual status of the page in the program. When you press the back button to return to a program that has been affected by the tombstone effect, the Windows Phone operating system will automatically display the page that the user browsed last time in the program. However, you need to ensure that the page status is saved or restored to the user's way before navigation to other programs. The page status includes text in the text box and the position of the scroll bar. This section describes how to save and restore the page status to provide a better user experience.

The page constructor, onvavigatedto, and onvavigatedfrom methods are used to save and restore page information. The page constructor is called when the page is first navigated. Onnavigatedto is called every time a program or page is loaded and available. Onnavigatedfrom is called when the program and page are not backloaded and navigate from the current page to another page. You can initialize page-level information in the page constructor, restore the Page Status in the onnavigated method, and store the page status information in onnavigatedfrom.

To save and restore page information, follow these steps:

1. Add a Boolean variable to the page (such as newpageinstance) and set it to false. This variable is used to determine whether the UI status needs to be restored.

2. In the page constructor, set the page-level variable to true. The page constructor is called when the page is first created in the program instance or the page is re-activated from the tombstone effect of the program. The page constructor will not be called when you click back in the same program, because the page already exists in the memory.

3. Rewrite and implement the onnavigatedto method. In this method, the page-level status data is restored from the phoneapplicationpage. state attribute.

4. Rewrite and implement the onnavigatedfrom method. In this method, the page-level State data is stored in the phoneapplicationpage. state attribute.

The following example contains two pages: Home and second. When you click go to the second page on the home page, navigate to the second page. The second page contains a text box, two single-choice buttons, and a check box. If you enter some data in these fields on the second page and press the start button to exit the program, the program enters the tombstone effect state. Click the back button to navigate back to the second page. You can see that the previously entered data has been restored to the interface.

The page data recovery code is not displayed.

Add the following code to the seond page to save and restore the page status.

C #

Public partial class secondpage: phoneapplicationpage

{

Bool newpageinstance = false;

Public secondpage ()

{

Initializecomponent ();

Newpageinstance = true;

}

Protected override void onnavigatedto (system. Windows. Navigation. navigationeventargs E)

{

If (State. containskey ("textbox") & newpageinstance = true)

{

Mytb. Text = (string) State ["textbox"];

Myrb1.ischecked = (bool ?) State ["radiobutton1"];

Myrb2.ischecked = (bool ?) State ["radiobutton2"];

Mycb. ischecked = (bool ?) State ["checkbox"];

}

Base. onnavigatedto (E );

}

Protected override void onnavigatedfrom (system. Windows. Navigation. navigationeventargs E)

{

Newpageinstance = false;

State ["textbox"] = mytb. text;

State ["radiobutton1"] = myrb1.ischecked;

State ["radiobutton2"] = myrb2.ischecked;

State ["checkbox"] = mycb. ischecked;

Base. onnavigatedfrom (E );

}

}

Best practices

The following are some best practices that can be followed when developing a Windows Phone program:

1. When a program runs from the tile or Application List, the page should be positioned as the root experience node ?]. It should be clear to users that they are experiencing a new instance of a program.

2. when a user activates a tombstone, the interface displayed by the user should be the same as the interface displayed when the screen is reversed, instead of making the user feel that the program is terminated and restarted.

3. When the program is Tombstone, the user may not directly return to the program. In this way, the persistent State needs to be stored in the independent storage in deactivated event processing and closing event processing. To avoid code duplication, you can create a separate method to save the information to the independent storage and then call the two event processing codes.

4. All operations in the deactivated event processing code should be completed within 10 seconds. If the return time exceeds 10 seconds, it will be forcibly terminated by the operating system and cannot be returned if the return time is used. Therefore, we recommend that you pay attention to simple forms when developing programs. If it takes more than a few seconds for the program to store the complete information, it is best to incrementally store them into the independent storage area when the program is running.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.