Fast Application Switching and Acquired OS Resources

Fast Application Switching (FAS) is a new feature of Windows Phone 7.5 and provides an improved experience when the user is switching between applications. The application is no longer terminated when the user navigates away from the application. Instead the application remains in memory and is not running at all, but its state and data are preserved. This is called the “dormant” state.

When an application enters the dormant state, the OS will take away certain system resources from the application. For instance, the camera resource is exclusive and it will be made available for other applications. But what happens when your application is reactivated? The OS will try to return the resources to your application wherever possible. The tricky bit is that some resource types will be returned to your application seamlessly and some resources will have to be reclaimed by the application itself. See list below.

Resource	Work done by OS	Work to be done by reactivated application
XNA Audio	Resumed	None. SoundEffect is resumed automatically.
Sensors	Notifications resumed	None. Sensor notifications are resumed automatically.
Networking	Completed with Cancellation	Re-issue the network request.
Sockets	-	Socket has to connect again.
MediaElement	-	Media will not resume. Set Source property and start Play() .
Camera	-	PhotoCamera/VideoCamera objects must be created again. Calling any method on the old object will throw ObjectDisposedException. For CameraCaptureTask no action is required , its object is preserved. If desired, call Show() method to show camera application.

I want to specifically call out networking, because almost all applications are connected nowadays and that’s where the first bugs can often be found when implementing fast application switching.

 

Networking

For example, let's explore what happens to a WebClient during a fast application switch. We already know that after FAS, the application’s state is retained and objects remain instantiated. Similarly, the WebClient object and its event handlers remain wired up. The only trouble is that during FAS, our network calls will get cancelled. The good news is, this is easy to detect. After the application is reactivated, the WebClient will be notified about the network request cancellation. In particular, the WebClient’s “Completed” handler will be triggered with “Cancelled” flag set. To get your application going again, re-issue the WebClient request and that’s it, your application now supports fast application switching.

Note that the application has to re-issue only network requests made explicitly. Silverlight controls that use network behind the scenes will download the content correctly. For instance <Image> control pointing to an http source will seamlessly complete image download after fast application switching.

 

Detecting cancelled WebClient request

1. WebClient client = new WebClient();
2.  
3. client.OpenReadCompleted += new OpenReadCompletedEventHandler(ClientOpenReadCompleted);
4. Uri requestUri = new Uri("https://www.contoso.com/somedata.dat");
5. client.OpenReadAsync(requestUri, requestUri);
6. ...
7.     
8.  
9. void ClientOpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
10. {
11.     if (e.Cancelled)
12.     {
13.         // Web request has been cancelled
14.         // e.UserState contains cancelled request Uri, which we have passed as userToken in OpenReadAsync method
15.     }
16. }

Detecting cancelled HttpWebRequest

1. HttpWebRequest request = WebRequest.CreateHttp("https://www.contoso.com/somedata.dat");
2. request.BeginGetResponse(new AsyncCallback(this.httpWebRequestCompleted), request);
3. ...
4.  
5. private void httpWebRequestCompleted(IAsyncResult asyncResult)
6. {
7.     HttpWebRequest request = (HttpWebRequest)asyncResult.AsyncState;
8.     HttpWebResponse response;
9.  
10.     try
11.     {
12.         response = (HttpWebResponse)request.EndGetResponse(asyncResult);
13.     }
14.     catch (WebException ex)
15.     {
16.         if (ex.Status == WebExceptionStatus.RequestCanceled)
17.         {
18.             // HttpWebRequest has been cancelled
19.         }
20.     }
21. }

 

Tips for implementing and testing fast app switching with networking:

• Distinguish between no network availability and a cancelled network request due to fast app switch. Quite often applications incorrectly show error messages that the network is not available; instead the applications should re-issue the network request.
• Do not show any popups or MessageBoxes, fast application switching is not an error state.
• In cases where an action is triggered by a user and the application is unable to complete the user’s request, inform the user with an error message. For instance, the user is sending a message and the device moves to an area without network coverage. Please do inform the user that the transaction couldn’t be completed. (The reason for failure is no network coverage, not fast app switching)
• On the contrary, upon successful message delivery, no confirmation would be shown to user. It is expected that all actions will complete successfully.

 

Example step-by-step FAS testcase

Imagine phone application accessing an online store. User can browse products using his Windows Phone 7 application. A FAS testcase can go like this: 

1. Tap on Electronics section of the online store
2. As soon as “Loading…” starts, press the Start button on Windows Phone
3. Wait a second and press hardware back button to return to the application

Commonly observed bug:
No results found or the application throws an exception

Expected result:
List of products in electronics section is loaded when user returns to the application

 

Resources

Get Ready for Fast Application Switching in Windows Phone

 

Written by  Petr Sedlacek