Discussion on Windows Phone 7 development on the 31st day-14th: tombstone mechanism (multi-task)

This article is about Windows Phone 7 development on the 31st day"14th day of the series.

Yesterday, we discussed the use of location data to provide users with a more familiar feeling. Today, what I wrote may be the most controversial topic on Windows Phone 7: multitasking.

Now there are a lot of articles that will be entangled in writing Windows Phone 7, the first in the list is "lack of multi-task ".

Windows Phone 7There are indeed multiple tasks

Yes, that's what I said. This is true. A Windows Phone is definitely a multitasking device. I can play games while listening to music, or receive emails while surfing the Internet. The error message is sent from our application developers. during development, we found that the program cannot be built to run in the background.

During my months of working for Windows Phone 7, I can only propose two reasons for truly convincing backend applications running on my Phone.

1. The Program for playing music. Such as the Pandora program. I totally agree that it runs in the background. If the music stops, you will find it.
2. Programs that need to get data from device sensors, such as GPS. If the program is not running, I will not be able to tell you that you have finished the 4-mile journey you want.

In addition to these two cases, I do not think that the program must be run in the background. (If your program is in any of the above categories, you can call on the "authority" to access a "super API" that enables the program to run in the background ". But I still want to remind you ...... Provide a very good reason for obtaining access permissions .)

You may ask, "But how can I get updates from my Web Service? Can I get it without running it ?" My answer is NO. You cannot do this. There is a powerful mechanism called push notification service that can solve this problem in an elegant way. I will explain this in 19th.

For the remaining programs, there is a mechanism called "Tombstone" that allows us to make the program always seem to be running, even if the process has ended. Demonstrate how it works:

As you can see in, when a user enters or exits the program, we can use the stop and reactivate events. Through these events, we can make users feel that the program has never stopped. When we join the independent storage (15th days) and push notifications (19th days), this will become a very powerful story.

Multi-task simulation

There are four built-in methods in your App. xaml. cs file (for more information about the project file structure, see the 1st ). Let's take a look at the default status with built-in annotations.

Code // 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)
{
}

// 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)
{
}

// 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)
{
}

// 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)
{
}

The "Launching" and "Closing" methods are generally used to start and exit an application (for example, to exit with the return key or to start from the program list ). Activated and Deactivated methods are used to access and exit in unconventional ways. For example, use the return key to return to our application. Or leave the program by answering the phone. These are unconventional. I recommend that you test these cases in large quantities, but some rules can be followed.

You should use these methods to save status information when a user exits the program and update these statuses when they return. This creates the illusion that they have never exited. The reason for doing so is simple:

1. Most users do not realize that after they leave the program, the program still consumes system resources and battery power in the background (if you are reading this article, you are not a majority of users ).
2. Most applications are not required to run in the background. This is a good way to save system resources.

Save your status when the program is stopped

The first thing users need to do when they exit is to save their information. In my example, I built a timer that seems to be running all the time, even when it is not running. If you want to read all the code, go to the bottom of the article and see the "Download Sample Code" section. I only show some of the Code related to the tombstone here, but the code at the bottom of the article is a complete and available application.

To save data, I use the PhoneApplicationService class. I will explain how to store data independently tomorrow (15th), a more persistent way. In my example, I want to know when you quit the program, so I want to calculate the difference between your exit and the next running of the program.

Private void Application_Deactivated (object sender, DeactivatedEventArgs e)
{
PhoneApplicationService. Current. State ["LeftTime"] = DateTime. Now;
}

In my application, there is an OnNavigatedTo event when loading the page. If the value of "LiftTime" exists, I will use it. Otherwise, I assume that you started the program for the first time.

Restore your status when the program is re-activated

In this example, I restored the value saved at exit.

Code Protected override void OnNavigatedTo (System. Windows. Navigation. NavigationEventArgs e)
{
Base. OnNavigatedTo (e );

If (PhoneApplicationService. Current. State. ContainsKey ("LeftTime "))
{
DateTime deactivated = (DateTime) PhoneApplicationService. Current. State ["LeftTime"];
SecondsSinceStart = (int) (DateTime. Now-deactivated). TotalSeconds + (int) PhoneApplicationService. Current. State ["ElapsedTime"];
WriteTime ();
WriteDate ();
Timer. Start ();
}
Else secondsSinceStart = 0;
}

In this way, I can maintain a continuous timer, even when we leave the program. If you ask any user, they will tell you that the program has been running. The only thing they can see is the "Resuming" screen that appears when the program loads slowly. In fact, I have to force the program to pause before capturing the following:

The above is the basic knowledge behind the tombstone mechanism. Save the status when you exit and restore it when you go back. Your users will never know the difference. At the same time, you can provide them with better endurance, performance and user experience.

Download Sample Code

Compared to a complex example of the Code described above, my timer is always running (even in the background ). Press the start button of the simulator to exit and return to the program with the return key. The program also has a text box for you to enter information, which will be saved when you exit.

Address: http://www.jeffblankenburg.com/post/31-Days-of-Windows-Phone-7c-Day-14-Tombstoning-%28Multi-tasking%29.aspx

If you like my article, click "recommendation". Thank you!