Guidelines for app suspend and resume
Design your 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. Follow these guidelines when you design the suspend and resume behavior of your Universal Windows Platform (UWP) app.
For a summary of the lifecycle of a UWP app, see App lifecycle.
- When resuming after a short period of time, return users to the state the app was in when the user left. For example, if a user navigates to another app before finishing an email, the user should be returned to the page with their unfinished email instead of the mail app's main landing page.
- When resuming after a long period of time, return users to your app's default landing page. For example, return a user to the main landing page of your news or weather app instead of returning them to an old, stale article or displaying outdated weather data.
- If appropriate, allow users to choose whether they want to restore their app to its previous state or start fresh. For example, when the user switches back to your game app, you could display a prompt so the user can decide whether to resume the game or start a new one.
- Save app data when the app is being suspended. Suspended apps don't receive notification when the system terminates them, so it is important to explicitly save app data to ensure that app state can be restored.
If your app supports multiple launch points such as secondary tiles, and toast notifications, and File and URI associations, you should consider creating a separate navigation history for each launch point. When suspending, save the state associated with the primary launch point, and only save the state for secondary launch points in scenarios where it would frustrate the user to lose state. Saving too much state can cause the app to be slow to resume.
- Use saved app data to restore your app.
- Release exclusive resources and file handles when the app is being suspended. As stated earlier, suspended apps aren't notified when they're terminated, so make sure to release resources and handles (like webcams, I/O devices, external devices, and network resources) when your app is suspended to ensure that other apps can access them.
- Update the UI if content has changed since it was last visible to the user. Your resumed app should look as if it was running while the user was away.
- Don't terminate the app when the user navigates away from the app or closes the app using the close button. The operating system ensures that there is a consistent way for the user to access and manage apps. Your app is suspended when it is no longer visible to the user. By leaving the application lifecycle to the system, 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 explicitly terminated by the user. The user may have closed the app because it got into an unrecoverable state. If your app was explicitly closed by the user, provide a fresh experience rather than a resume experience. When the app was closed by the user, the PreviousExecutionState property will have the value ClosedByUser.
- 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 app data is possibly corrupt. The app should not try to restore to its previous state using this stored data.
- Don't include Close buttons or offer users other ways to terminate your app in its UI. Users should feel confident that the system is managing their apps for them. The system can terminate apps automatically to ensure the best system performance and reliability, and users can choose to close apps using gestures on Windows or through the Task Switcher on Windows Phone.
- Don't strand users on deep-linked pages. When the user launches your app from a launch point other than the primary tile, landing on a deep-linked page, provide UI to allow the user to navigate to the app's top page. Or, allow the user to get to the top page by tapping the primary tile.
- For some applications it makes sense to always return the user to the top of the app if it is launched from the primary tile but not when the user returns to the app by using the task switcher. If you need to tell the difference between these two scenarios, check LaunchActivatedEventArgs.PreviousExecutionState and if it is Terminated, check LaunchActivatedEventArgs.TileId. If
TileID == “”then your app came back from termination via the task switcher because the user switched to it. In all other cases the user launched your app from a tile.
- For developers (XAML)
- App lifecycle
- Handle app suspend
- Handle app resume
- App activated, resume, and suspend using the WRL sample
- App activate and suspend using WinJS sample
- Getting Started with C# and VB: Hello World samples (Part 2)