Windows 8 brings a new app lifecycle model, in which Windows Store apps are automatically managed for the user. These apps always feel alive, even though they never run when they’re off the screen. This provides great benefits for power consumption and battery life.
Here are a few related blog posts we recommend for background reading on this topic:
- Building Windows 8 Blog: Building a power-smart general-purpose Windows (see “The Metro style application model” section)
- Building Windows 8 Blog: Improving power efficiency for applications (explains the different app states)
- Windows 8 app developer blog: Managing app lifecycle so your apps feel “always alive” (explains how to program for the different lifecycle states)
In this post, we’ll take a look at what this all means for debugging. Of all the debugging advances we made in Visual Studio 2012 (from JavaScript debugging, to the Windows 8 Simulator, to remote debugging on Windows RT devices), the debugging experience for Windows 8 lifecycle states and background tasks was one of the most challenging to design!
Simulating events
The first challenge we encountered in this process was how to simulate the events your app would encounter with real world usage, so that you could debug those interesting cases. How could we simulate your app being suspended because a text message was sent and caused another app to activate? How could we simulate your app being terminated, without ending your debugging session?
One principle that we used in designing the solution was that we wanted the model to be simple, so that you could use a core set of debugging commands to simulate the variety of lifecycle events that your app might experience. Therefore, we decided to add the following three commands to Visual Studio: Suspend, Resume and “Suspend and Shutdown”.
- Suspend: The Suspend command leaves the app in suspended state after it has handled the event.
- Resume: The Resume command resumes the app, and brings it back into a running state as the active app in the foreground.
- “Suspend and shutdown”: “Suspend and shutdown” first does a “Suspend”. Then (once the app is suspended), this command terminates the app and stops debugging.
You may wonder why we needed to create a “Suspend and shutdown” command. The goal of this command is to simulate the natural sequence of events that occur when your app is suspended and terminated by Windows 8. When an app gets suspended, it receives a suspending event, and the suspending event handler usually saves data the app may need when it is later activated (after going from suspended to terminated state). We observed users try to simulate this in other ways on the pre-release bits. For example, we saw some users just stop debugging, which would shut down the app, but there would be no suspending event triggered. Other users would explicitly close the app by pressing Alt+F4 or by dragging it to the bottom of the screen. In that case, a suspending event would be triggered before the app was terminated; however the next time the user activated the app, its PreviousExecutionState would be ClosedByUser (which is not what we’re trying to simulate). Therefore, the “Suspend and shutdown” command provides a way to simulate your app being suspended and terminated by Windows, as opposed to being explicitly closed by the user.
Exposing the commands
The next question we faced in the design process was how to expose these commands.
In the Visual Studio 2012 Beta release, we created dedicated buttons for these commands in the “Debug Location” toolbar. We chose this toolbar because it provides the unique ability to select a process during run mode. This makes it easy to determine which process to apply the commands to, when debugging multiple processes.
Starting in Visual Studio 2012 RC (and continuing for Visual Studio 2012 RTM), we collapsed these buttons into a dropdown list on the same “Debug Location” toolbar. The dropdown design provided more space for the multiple commands which we wanted to expose, without cluttering the toolbar:
