Application lifecycle (Windows Runtime apps)
This topic describes the lifecycle of an app, from the time it is deployed through its removal. By suspending and resuming your app appropriately, you ensure that your customer has the best possible experience with your app.
This illustration represents the transitions between app execution states. The next several sections of this topic describe these states and events. For more detail about when each state transition occurs and what your app should do in response, see the docs for the ApplicationExecutionState enumeration.
An app is launched whenever it is activated by the user while the process is in the NotRunning state. An app may be in the not running state because it was just has not yet been launched, it was previously running and crashed, or it was suspended but could not be kept in memory and was therefore terminated.
When an app is launched, the OS displays a splash screen for the app. To configure this splash screen, see Adding a splash screen.
While its splash screen is displayed, an app should ensure that it's ready for its user interface to be displayed to the user. The primary tasks for the app are to register event handlers and set up any custom UI it needs for loading. These tasks should only take a few seconds. If an app needs to request data from the network or needs to retrieve large amounts of data from disk, these activities should be completed outside of activation. An app can use its own custom loading UI or an extended splash screen while it waits for these long running operations to finish. See the Extended Splash Screen documentation and Splash screen sample for more details. After the app completes activation, it enters the Running state and the splash screen is torn down. Showing a window, returning from the activation handler, and completing a deferral are specific ways that an app completes activation. For more info, see:
An app can be activated by the user through a variety of contracts and extensions. To participate in activation, your app must register to receive the Activated | activated event. Your app's activation event handler can test to see why it was activated and whether it was already in the Running state. Apps can be activated as follows.
|cached file||The user wants to save a file that your app provides content management for.|
|camera||The user wants to capture photos or video from an attached camera.|
|contact picker||The user wants to pick contacts.|
|device||The user wants your app to handle AutoPlay.|
|file||A user's app launched a file whose file type your app is registered to handle.|
|file open picker||The user wants to pick files or folders that are provided by your app.|
|file save picker||The user wants to save a file and has selected your app.|
|launch||The user launched your app or tapped a content tile.|
|print task||The user wants your app to handle print tasks.|
|protocol||A user's app launched a URL whose protocol your app is registered to handle.|
|search||The user wants to search with your app.|
|share target||The user wants your app to be target for a share operation.|
Apps that are built for Windows 8.1 and later can also be activated with these types.
|add appointment||The user wants to add an appointment to their calendar. Also supported on Windows Phone.|
|remove appointment||The user wants to remove an appointment from their calendar. Also supported on Windows Phone.|
|replace appointment||The user wants to replace an appointment from their calendar. Also supported on Windows Phone.|
|show time frame||The user wants to show a specific time frame on their calendar. Also supported on Windows Phone.|
|contact call||The user wants to call a contact.|
|contact map||The user wants to map (get the location of) a contact.|
|contact message||The user wants to send a message to a contact.|
|contact post||The user wants to post a contact.|
|contact video call||The user wants to video-call a contact.|
|lock-screen call||The user wants to accept a call from the lock screen.|
|restricted launch||The user launched your restricted app.|
Windows Phone apps can be activated with these types.
|VoiceCommand||The application was activated as the result of a voice command.|
|PickerReturned||The application was activated after the completion of a picker.|
|WalletAction||The application was activated to perform a Wallet operation.|
|PickFileContinuation||The application was activated after the app was suspended for a file picker operation.|
|PickSaveFileContinuation||The application was activated after the app was suspended for a file save picker operation.|
|PickFolderContinuation||The application was activated after the app was suspended for a folder picker operation.|
|WebAuthenticationBrokerContinuation||The application was activated after the app was suspended for a web authentication broker operation.|
Your app can use activation to restore previously saved data in the event that the operating system terminates your app, and subsequently the user re-launches it. The OS may terminate your app after it has been suspended for a number of reasons. The user may manually close your app, or sign out, or the system may be running low on resources. If the user launches your app after the OS has terminated it, it receives an activated event and the user sees the splash screen of your app until the app is activated. You can use this event to determine whether your app needs to restore the data which it had saved when it was last suspended, or whether you must load your app’s default data. The activated event arguments include a PreviousExecutionState property that tells you which state your app was in before it was activated. This property is one of the values from the ApplicationExecutionState enumeration. The table below summarizes the possibilities:
|Reason for termination||Value of PreviousExecutionState property||Action to take|
|Terminated by the system (for example, because of resource constraints)||Terminated||Restore session data|
|Closed by the user||ClosedByUser||Start with default data|
|Unexpectedly terminated, or app has not run since the user’s session started||NotRunning||Start with default data|
PreviousExecutionState could also have a value of Running or Suspended, but in these cases your app was not previously terminated and therefore you don’t have to worry about restoring data.
Note that if you log on using the computer's Administrator account, you can't activate any Windows Store apps.
For more info, see App extensions.
An app can be suspended when the user switches away from it or when the device enters a low power state. Most apps stop running when the user switches away from them.
When the user moves an app to the background, the OS waits a few seconds to see whether the user immediately switches back to the app. If the user does not switch back, the OS suspends the app.
If an app has registered an event handler for the Suspending | suspending event, this event handler is called right before the app is suspended. You can use the event handler to save relevant app and user data to persistent storage. We recommended that you use the application data APIs for this purpose because they are guaranteed to complete before the app enters the Suspended state. For more info, see Application data. You should also release exclusive resources and file handles so that other apps can access them while your app isn't using them.
Generally, your app should save its state and release its exclusive resources and file handles immediately in the event handler when the suspending event is received, and generally take about a second to do so. If an app does not return from the suspending event within 5 seconds on Windows and between 1 and 10 seconds on Windows Phone, the OS assumes that the app has stopped responding and terminates it.
The operating system attempts to keep as many suspended apps in memory as possible. Keeping these apps in memory ensures that users can quickly and reliably switch between suspended apps. However, if there aren't enough resources to keep your app in memory, the OS can terminate your app. Note that apps don't receive notification that they are being terminated, so the only opportunity you have to save your app's data is during suspension. When an app determines that it is activated after being terminated, it should load the application data that it saved during suspend so that the app appears as it did when it was suspended.
There are some apps that need to continue to run to complete background tasks. Your app can continue to play audio in the background; for more info, see Quickstart: Adding audio in a Windows Runtime app. Background transfer operations continue even if your app is suspended or even terminated; for more info, see Quickstart: Downloading a file.
For guidelines, see Guidelines for app suspend and resume.
For example code, see:
When the user switches from your app to another app, your app is no longer visible but remains in the running state until the OS can suspend it (for about 10 seconds). If the user switches away from your app but activates or switches back to it before it can suspended, the app remains in the running state.
Your app doesn't receive an activation event when app visibility changes, because the app is still running. The OS simply switches to and from the app as necessary. If your app needs to do something when the user switches away and back, it can handle the VisibilityChanged | msvisibilitychange event.
The visibility event is not serialized with the resume or activation events. Don't assume that these events come in a particular order.
A suspended app is resumed when the user switches to it or when the device comes out of a low power state.
For an enumeration of the states that your app can be in when your app is resumed, see ApplicationExecutionState. When an app is resumed from the Suspended state, it enters the Running state and continues from where it was when it was suspended. No application data is lost, as it was stored in memory. Therefore, most apps don't need to do anything when they are resumed. However, the app could have been suspended for hours or even days. So if your app has content or network connections that may have gone stale, these should be refreshed when the app resumes. If an app registered an event handler for the Resuming | resuming event, it is called when the app is resumed from the Suspended state. You can refresh your content using this event handler.
If a suspended app is activated to participate in an app contract or extension, it receives the Resuming | resuming event first, then the Activated | activated event.
When an app is suspended, it does not receive network events that it registered to receive. These events are not queued, they are simply missed. Therefore, your app should test the network status when it is resumed.
For guidelines, see Guidelines for app suspend and resume.
For example code, see:
Note On Windows Phone, OnLaunched is called each time the user launches the app from Start tile or app list, even when the app is currently suspended in memory. On Windows, launching a suspended app from Start tile or app list doesn’t call this method.
Generally, users don't need to close apps, they can let the OS manage them. However, users can choose to close an app using the close gesture or by pressing Alt+F4 on Windows or by using the task switcher on Windows Phone. You can't include any UI in your app to enable the user to close your app, or it won't pass the Store certification process.
There's no special event to indicate that the user has closed an app.
After an app has been closed by the user, it's suspended and terminated, and then enters the NotRunning state within about 10 seconds.
In Windows 8.1 and later, after an app has been closed by the user, the app is only removed from the screen and switch list without being terminated.
Note If your app depends on the closed-by-user behavior of Windows 8, you can enable this behavior in your app when you upgrade it to Windows 8.1. To enable the closed-by-user behavior of Windows 8, set your Windows 8.1 app to terminate when the last window is closed with the Windows.UI.ViewManagement.ApplicationView.TerminateAppOnFinalViewClose property.
If an app has registered an event handler for the Suspending | suspending event, it is called when the app is suspended. You can use this event handler to save relevant application and user data to persistent storage.
Closed-by-user behavior: We recommend that you decide how your app behaves when it's activated after being closed by the user. It may make no difference to you whether the app was terminated by the OS or by the user. If your app needs to do something different when it is closed by the user than when it is closed by the OS, you can use the activation event handler to determine whether the app was terminated by the user or by the OS. See the descriptions of ClosedByUser and Terminated states in the docs for the ApplicationExecutionState enumeration.
We recommend that apps not close themselves programmatically unless absolutely necessary. For example, if an app detects a memory leak, it can close itself to ensure the security of the user's personal data. When you close an app programmatically, the OS treats this as an app crash.
Apps are required to follow the system crash experience, which is to simply return to the Start screen. The system crash experience is designed to get users back to what they were doing as quickly as possible, so you shouldn't provide a warning dialog or other notification because that'll cause a delay for the user. The disappearance of the app should make it clear to the user that something went wrong.
If your app crashes, stops responding, or generates an exception, Windows asks the user for consent to send a problem report to Microsoft. Microsoft provides a subset of the error data in the problem report to you so that you can use it to improve your app. You'll be able to see this data in your app's Quality page in your Dashboard in the Dev Center.
When the user activates an app after it crashes, its activation event handler receives an ApplicationExecutionState value of NotRunning, and should simply display its initial UI and data.
When a user deletes your app, the app is removed, along with all its local data. Removing an app doesn't affect the user's data, such as files in the Documents or Pictures libraries.
- Windows.ApplicationModel namespace
- Windows.ApplicationModel.Activation namespace
- Windows.ApplicationModel.Core namespace
- Windows.UI.WebUI namespace
- Windows.UI.Xaml.Application class
- Windows.UI.Xaml.Window class
- WinJS.Application namespace
- Guidelines for app suspend and resume
- App activated, resume, and suspend using the WRL sample