Fast App Resume logic detailed

Published by at

At AAWP, we've mused on the mysteries of Windows Phone's app switching/launching behaviour for ages. What should happen when you switch back to an application, what should happen when you tap on its tile or icon? It turns out that there are no concrete rules here, just guidelines and some probing questions for the developer to consider when matching up the application's user interface. See the article below for a techy read if this subject fascinates you as well.

From the tutorial article (which also includes sample code for developers):

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.

You can read the full article here.

It's a fascinating topic because it encompasses the fact that a platform has to satisfy both geeks and normal phone users. The former fully expect applications to carry on exactly as they were left - the geek knows full well what he or she started and doesn't want the OS to get in the way.

The latter (and much larger) group, normal users, have no concept of multitasking or RAM or system resources and they blindly stab at whatever data and applications they want, in any order and utterly relying on the OS keeping them out of trouble. Thus give a Windows Phone stocked with games to a child and they'll happily play away, kicking off games one after the other, returning to the Start screen between (sometimes even changing their mind mid-load if the game doesn't start fast enough) and they'll be fine because Windows Phone isn't really running all those previous titles anymore - they've been tombstoned and so don't get in the way at all.

This is, after all, the same approach taken by Apple for the iPhone and for exactly the same reason. Whereas the typical Windows Mobile or Symbian user from the early 2000s was expected to be tech-savvy and know roughly how to micro-manage their device, with the advance of smartphones to 'the great unwashed'(!) there needed to be rock solid performance even in the face of blatant disregard for (or ignorance of) application managament from the user.

Interesting stuff, anyway.

As a bonus read, see David's feature on Windows Phone 'multitasking' - an essential read for anyone wanting to understand the sort of things that go on under the hood in a Windows Phone!

Source / Credit: Windows Phone Developer Blog