Windows Phone 8 introduces the concept of
Fast App Resume.
Unfortunately this is a much confused and misunderstood feature.
Fas App Resume (FAR) is a purely technical setting that controls what the OS should do with existing instances of the application when the user does something which would, traditionally, try and launch a new instance.
Enabling FAR tells the OS that it should load any exiting application instance before starting a new one.
FAR does not define what should happen with the existing instance is NOT universally defined. Each app should do what is best/most appropriate for that app if begin launched via FAR.
When implementing Fast Resume, you must decide what is the best user experience for you app when launched from the different launch points that are available on the phone.
Enabling FAR does not mean that every app should always maintain an existing back stack when an existing instance is resumed due to FAR.
Windows 8 has a recommendation that apps should hide whether they are being launched afresh or an existing instance is reloaded. Apps, when launched, should always display themselves as they were when last viewed, regardless of how long ago that was or if the devices has been turned off (or rebooted) in the meantime.
This recommendation does not exist historically in Windows Phone and has not been made now.
In Windows Phone (7.x) there was a recommendation that apps should be predictable and always do the same thing when launched.
I see no reason why that recommendation does not still stand. Windows Phone apps should provide a consistent, predictable experience when launched.
But what about the built in apps?
Looking at the built in applications is always a great guide for what your apps should do. There's a problem here though. The built in applications can have multiple instances in the back stack.
The built in apps will launch a new instance in the same predictable way. The back stack maintains multiple instances in their different states.
There are also built in apps which remember where you were previously whenever the app is launched, regardless of other instances in the back stack.
It would be great if Microsoft had provided some information about why this feature (FAR) was added. I'd hope it's driven from research about how users are trying to use apps on the phone. To see the data behind such research would be awesome.
I suspect this may have been added to try and drive Win8 parity...
So what about some guidelines*:
- Enable Fast App Resume so that load time will be faster if an instance of the app already exists in the back stack.
- Launching from the main tile or app list always opens the app on the main page.
- Launching from a deep link (secondary tile) or otherwise) should launch direct to the
- Adding a home button should always be very carefully considered and you need a very strong case for adding one.
- Regardless of whether an existing instance of an app was loaded or not, any back stack should be cleared when starting the app again.
- If your app will show the last page shown when previously opened, this behaviour should be implemented regardless of how the app was started.
An exception:
- If the user was performing a complicated or long process when they left the app and it would be frustrating to lose that context, data or state then it may be appropriate resume where the user left off. It may also be useful to provide a way to allow the user to return to the main page though.
*entirely my opinion and I reserve the right to change this opinion either wholesale or on a case by case basis ;)
If you do implement FAR and you have page navigation animations that animates the PhoenApplicationFrame you may need to consider how you avoid spurious animations when FAR occurs. I've handled this by hiding the frame while navigation and back stack manipulation is performed as part of the resume process.
If you want an easy way to enable support in your project without having to manually edit the WMAppManifest.xml file,
there's a nuget package to help.
