Guidelines for app suspend and resume (Windows Store apps)
Follow these guidelines when you design the suspend and resume behavior of your app.
Design your Windows Store app to suspend when the user switches away from it and resume when the user switches back to it. Carefully consider the purpose and usage patterns of your app to ensure that your user has the best experience possible when your app is suspended and resumed. Most Windows Store apps should stop what they are doing when the user switches away from them. Very few apps should continue to run after the user switches away. For example, a music player should continue to play music even after the user switches to another app.
Use these guidelines to help you design the suspend and resume behavior of your app.
|Do||Generally, resume your app as the user left it rather than starting it fresh|
It's a poor experience for users to have to start fresh every time they switch away to another app and back to your app. Examples of situations where you should resume the app as the user left it:
|Start the app fresh if a long period of time has elapsed since the user last accessed it|
If there's a good chance that users won't remember or care about what was happening when they last saw your app, launch the app from its default launch state. You must determine an appropriate period after which your app should start fresh. If there is any doubt about whether to resume or start fresh, you should resume the app right where the user left off.
Examples of situations where it's better to start fresh:
|Save application data when the app is being suspended|
Explicitly saving your application data helps ensure that the user can resume your app even if Windows terminates or suspends it. Suspended apps don't receive notification that they are being terminated, so it's a best practice to have your app save its state when it's suspended and restore its state when it's launched after termination.
|Release exclusive resources and file handles when the app is being suspended|
Explicitly releasing exclusive resources and file handles helps ensure that other apps can access them while your app isn't using them. Suspended apps don't receive notification that they are being terminated, so it's a best practice to have your app release its handles when it's suspended and open its handles when it's launched after termination.
Examples of exclusive resources are webcams, I/O devices, external devices, and network resources.
|When resuming your app after it was suspended, update the UI if the content has changed since it was last visible to the user|
To the user, it should appear as though the app was running in the background.
|When resuming your app after it was terminated, use the saved application data to restore your app|
Users expect to find the app as they left it, whether it was suspended or terminated by Windows or closed by the user.
|Provide users with options if you can't predict whether they want to resume or start fresh|
It might not always make sense to bring the app back to where it left off. Instead, provide the user with a set of options for what to do next. For example, when the user switches back to your game, you could display a prompt so the user can decide whether to resume the game or start a new one.
Use these guidelines to avoid creating a poor user experience.
|Don't||Don't terminate the app when it's moved off screen |
Windows ensures that there is a consistent way for the user to access and manage Windows Store apps. Your app is suspended when it's moved off screen. By leaving the application lifecycle to Windows, you ensure that your user can return to your app as efficiently as possible. Doing so also provides the best system performance and battery life from the device.
|Don't restore state for an app that was terminated as the result of a crash|
If your app was terminated unexpectedly, assume that stored application data is possibly corrupt. The app should not try to resume but rather start fresh. Otherwise, restoring corrupt application data could lead to an endless cycle of activation, crash, and termination.
|Don't offer users ways to close or terminate your app
in its UI|
Users should feel confident that Windows is managing their apps for them. Windows Store apps should not display Close buttons or other ways to exit the app. Windows can terminate your app to ensure the best system performance and reliability. Also, users can choose to close apps through a gesture.
The following articles provide guidance for writing secure C++ code.
- How to suspend an app (C#/VB/C++)
- How to resume an app (C#/VB/C++)
- Application lifecycle
- UX guidelines for Windows Store apps
- App activated, resume, and suspend using the WRL sample
Build date: 10/26/2012