The app lifecycle model in Windows 8 means that users no longer need to manage which apps are running. It also makes it easy for developers to craft a great user experience that doesn’t affect the device’s battery or performance when the app is in the background. Using the new lifecycle events, your app will always feel alive, even though it never runs when it is off-screen.
Today, batteries often run low on laptops, tablets, and phones, because all of us tend to leave apps running even when we’re not using them. We do this for convenience and to switch quickly between apps.
We had this in mind as we developed the lifecycle model for Windows 8 apps – keeping apps responsive, preserving battery life, and providing excellent, consistent performance. Windows 8 apps are all about full-screen, immersive experiences. As such, the new lifecycle model in Windows 8 focuses on the apps in the foreground, ensuring that the experience the user is actively engaged and gets the full power of the device. In this post, I’ll walk you through the new states of the lifecycle model and what you need to do to make your app great.
Windows 8 app lifecycle
Your Windows 8 app is in one of 4 lifecycle states at any given time: not running, running , suspended or terminated. As your app transitions between states, it receives lifecycle events that help you provide a consistent and high performance experience to your users.
This diagram shows how a Windows 8 app transitions between states:
All Windows 8 apps move through these states as users launch apps, switch among them, and close them. Your app will likely move between the running and suspended states quite often as users switch between apps. So, your app must handle the lifecycle events.
As your app transitions among lifecycle states, it receives these lifecycle events:
|suspending or checkpoint (WinJS)||running||suspended|
In general, Windows 8 apps stop running when the user switches to another app. Windows suspends your app when it is not in the foreground. When your app is suspended, it is frozen in memory. It can’t run in this state, but Windows can instantly resume it when the user returns to it. In this way, Windows gives the foreground app better use of system resources and ensures apps in the background can’t drain the user’s battery.
If your app doesn’t return from its suspending event handler within 5 seconds of receiving the suspending event, Windows will terminate it. It’s important not to do any heavy operations in your suspending event handler. Save your app data and return quickly.
In this post, we use a stocks app as an example. This app may use the suspending event to save the last stock that the user was viewing, and the time range for a stock chart. Then, if the app is terminated, it can restart to the exact same view that the user was looking at the last time they saw the app. For example, the recommendation for a stocks app is to use this as another opportunity to send a local tile notification so that the app’s tile is updated with the latest info before Windows suspends it.
Handling suspend in XAML
If you write a Windows 8 app using XAML and C#, you can use the Suspending event on the application object to handle app suspension.
Again, this is an overview. For more info on how to handle suspend in XAML and C# see How to suspend an app (VB/C#/C++ and XAML) on the Dev Center.
When your app is resumed, it continues from the state that it was in when Windows suspended it. To be specific: app data and state are kept in memory while the app is suspended, so when it’s resumed, everything is as it was when the app was suspended. You don’t need to restore any saved data explicitly when receiving the resuming event.
But you want your app to appear to be always alive. For this, it has to be connected and display the latest data. It is possible that your app stays in a suspended state for quite a long time before it is resumed. Data or network connections could become stale and may need to be refreshed when your app resumes. When a user brings your app back to the foreground, your app receives a resumingevent. You can refresh the app content and reconnect network resources when your app receives this event.
In our example stocks app, resume is the right place to refresh all the cached stock data that the app had before it was suspended. The previous data could be hours or even days old. The user perception that their app is always alive is broken if the user sees this old data. On resume, our stocks app must update all of its data. This way the user sees the latest stock prices, charts, and news articles each time the app is brought to the foreground.
Handling Resume in XAML
If you write a Windows 8 app using XAML and C#, you can use the Resuming event on the application object to handle app resume.
For more info on how to handle resume in VB/C#/C++ and XAML, see How to resume an app (VB/C#/C++ and XAML) on the Dev Center.
Activation is all about how your app gets launched. It serves many purposes in a Windows 8. For more details on how you can use Windows 8 app activation to handle contracts, see our earlier post, Activating Windows 8 contracts in your app. Here we focus on how you can use activation to restore previously saved data in the case that Windows terminated your app and then the user relaunched it.
Windows can terminate your app after it has been suspended for a number of reasons. For example: the user manually closes your app, or signs out, or the system is running low on resources (some apps, such as games, can be pretty resource intensive!). If the user launches your app after Windows terminated it, it receives an activated event and the user sees your app’s splash screen until the app is activated. You can use this event to determine whether your app needs to restore the data it saved when it was last suspended, or if you must load your app’s default data. The activated event arguments include a PreviousExecutionState property that tells you the state your app was in before it was activated. This property is one of the values of theWindows.ApplicationModel.Activation.ApplicationExecutionState enumeration.
|Reason for termination||PreviousExecutionState value||Action to take|
|Terminated by the system (because of resource constraints, shut down, reboot, etc.)||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.
When your app is activated and its PreviousExecutionState was Terminated, you must restore your saved session data to make the app appear just as it was when the user last looked at it. If the user closed the app manually, the app unexpectedly terminated or has not yet been run in the current session, you must ignore the previous session data and start the app up with its default view.
Our example stocks app uses the activated event to bring back the stock and chart info that it saved when it was suspended. The app also refreshes its cached network data. This way, the user sees the same stock that they saw when they switched away from the app, but the stock’s prices, charts, and news articles are all up to date.
In the activated event handler code, your app can check the sessionState object to determine if it should load saved data or if it should display the default home view. SessionState determines the last state of your app automatically by examiningeventArgs.detail.previousExecutionState. If sessionState is populated, use it to restore your session data, otherwise use your app’s default data.
Handling activation in XAML
In a Windows 8 app using XAML and C#, you can override the OnLaunched event to handle activation a basic activation from a tile.
In the OnLaunched event handler code, your app can check the PreviousExecutionState on the event arguments. If it equalsTerminated, restore the data you saved in the Suspending event. If it is a different value, use your app’s default data.
For more info on how to handle activation in XAML, see How to activate an app (VB/C#/C++ and XAML) on the Dev Center.
Tips for creating a great app lifetime experience
Now that you’ve got all the basics, here are some tips to help you build a great lifetime experience for your app that will keep it feeling always alive and fresh for your users.
Sometimes it’s best to start fresh
If it’s been a while since the user last looked at your app, sometimes it’s best to reset the app to its default view. It’s up to you to figure out how long is too long, but if the content of your app would look old or stale, we recommend you navigate your app back to its home view. This makes your app appear more intelligent to your users.
For example, if you are building a news reader app, it is likely your app will be suspended after the user switches away from it. Sometime later, when the user returns to your news reader app, the app is resumed. In your resume handler, check how old the current article is to determine if it is now stale. If the article is too old, display your default home view instead of the old article.
Save the right data at the right time
Always save important data incrementally throughout the life of your app. Because your app has only up to five seconds to run suspending event handler code, you need to ensure that your important app data has been saved to persistent storage by the time it is suspended.
There are two types of data for you to manage as you write your app: session data and user data. Session data is temporary data that is relevant to the user’s current experience in your app. For example, the current stock the user is viewing, the current page the user is reading in an eBook or the scroll position in a long list of items. User data is persistent and must always be accessible to the user, no matter what. For example, an in-progress document that the user is typing, a photo that was taken in the app or the user’s progress in your game.
Make sure that by the time your app is suspended, it saved both data types to persistent storage.
Restoring session data
Users will expect that a Windows 8 app will generally stay as they left it when they last used it. From the developer perspective, when your app is resumed from a suspended state or activated from a not running state, it is often appropriate to restore your previously saved session data.
For example, if your app includes shopping cart functionality and the user added items to the cart and then switched away from your app, it would make sense to maintain those items in the cart when the user resumes or reactivates the app.
In another example, consider an app that shows news articles. If the user was viewing a specific article, then switched to another app, the user will expect to see the article they were viewing when they come back to your app.
Release exclusive resources in your suspending event handler
If your app has acquired any exclusive resources during execution (such as file handles or references to external devices), it must release those resources when it receives the suspending event. Additionally, your app must reclaim those exclusive resources when it receives the resuming event if it needs them to continue.
Don’t close your app!
Windows 8 apps must never close themselves or present app UI to allow a user to close your app. Suspending and terminating apps is handled by Windows on the user’s behalf to maintain system performance and battery life. If users want to close your app, they can do so by swiping from the top to the bottom of the screen or by pressing ALT+F4.
By using 3 events—suspending, resuming and activated—your app will always appear to be alive to your users. But at the same time, it will never drain their battery unnecessarily or reduce their system’s performance when they are not using it. In the world of slimmer, more mobile devices, the new Windows 8 app lifecycle lets your app shine on any device.
–Adam Barrus, Program Manager, Windows
This post was a group effort. Thanks to Jake Sabulsky, Ben Srour, Ben Betz, Marco Matos, Ryan Haveson, Ian LeGrow, and John Montgomery for contributions.