Windows Phone Fast App Resume

This blog post was authored by Matt Hidinger, a Program Manager on the Windows Phone team.

- Adam

Windows Phone offers developers an important choice in how their app resumes from Start. By default, each time a user launches an app from Start or from the App list, a completely new instance of the app is created. This is true even if the user was just using the app and viewing a different page. This default experience works great for apps that follow the "hub and spoke" navigation pattern; that is, apps that have a centralized hub and a shallow navigation hierarchy. All the first-party apps follow this model; the app's home page is never more than 2-3 presses of the Back button away.

Not every app fits perfectly with this "fresh start" experience, so in Windows Phone 8 we added support for Fast App Resume.

What is Fast App Resume?

Fast App Resume offers two benefits:

1. By reusing the same app instance that currently is suspended, your app starts faster. This in itself is a win.
2. In addition, you also could enhance the user's experience by having your app resume on the screen she was viewing before navigating away from your app.

That sounds amazing, how can I get in on this?

I'm glad you asked. Act now, and you too can have Fast App Resume for the low, low cost of one XML attribute!

WMAppManifest.xml

The Fine Print

Naturally, if someone says “just change this one XML file and all your problems will go away” your developer senses may suspect a hint of snake oil!

So read on, and you’ll get all the information you need to create a great app resume experience for your user.

Thoroughly consider the user experience that makes sense

The most challenging part of enabling Fast App Resume is determining the best user experience for various scenarios. Here are a few questions you should run through to help you decide which option to use.

First and foremost, when the user launches my app, should I resume where they left off, or always take them to the app's home page?

I want the Resume experience

Many apps today use this model to implement Fast App Resume. To see it in action, check out the latest versions of Twitter, Yelp, or ESPN ScoreCenter.

Some important things to consider are:

1. What should happen when a user launches a deep link, by tapping a secondary tile or toast?
   Because your app may already be running, it will be resumed and navigated forward to the deep link URI. This poses an interesting problem for your back stack: what should happen when the user presses the Back buttonnow? Most apps clear the back stack after a deep-link launch, so that pressing the Back button will return them to whatever they were doing last. Unfortunately, by clearing their back stack they have no way to get to your app’s home page without re-launching the app from the primary tile. To get around this, a number of apps provide a Home button in the app bar.
   See the sample project attached to this post for deep link and Home button guidance.
2. Should I provide a Home button?
   If your app has a deep navigation hierarchy or supports deep linking, it's important to provide users a way to get back to your app’s home page without pressing the Back button a bunch of times. Some apps, like Twitter, provide a Home button in a consistent place in the app bar. This offers users a neat, learnable way to get back home no matter where they are. In most cases, it's a good idea to clear the back stack after pressing the Home button.
   See the sample project attached to this post for Home button guidance.
3. Should I consider a fresh start experience after a certain time period?
   In some cases you may want your app to resume if the user had recently been using it, but after some time has passed, just to start fresh. To achieve this you simply store a timestamp when the app deactivates. Then, when it’s launched again, you determine whether the current time is more than X minutes from the previous deactivate; if so, take them to your app’s home page.
   See the sample project attached to this post to see how to implement a fresh start time window.

No thanks, I'd like to stick to the Fresh Start experience

That works too! If you do use Fast App Resume, you'll get a performance win on app start. To the app user, nothing has changed: they always launch the app to the home page, but by reusing the same app instance your app will launch faster.

To provide this experience, you simply remove all pages on the back stack when the app resumes, before the user is presented with the app home page.

To try this out, open the sample project attached to this post and set the _mustClearPagestack field to true, as follows:

Learn more from the sample project

Fast App Resume can be a little tricky at first. The best way to get a handle is to download the sample project and see how it works on a device. Adjust a few settings, watch the navigation flow, observe when to reset the back stack, etc.

When you've got the project loaded in Visual Studio, all the Fast App Resume logic is centralized in App.xaml.cs, line 168, in the Phone And FAR Initialization region. As I said, it's a little tricky to follow, because the code in this region requires changing or cancelling navigation events, checking a few state enums, and occasionally manipulating the back stack. But dropping this region of code into your App.xaml.cs should get you well on your way to offering a great Fast App Resume experience!

More resources

For a more detailed explanation of the App.xaml.cs code modifications required, be sure to check out another Fast App Resume sample that my sample project is based on.

To download and learn about additional Fast App Resume scenarios, see How to take full advantage of Fast App Resume in your Windows Phone 8 app. For more insight on Fast App Resume, see the MSDN page on Fast App Resume.