Launching, resuming, and multitasking for Windows Phone
December 04, 2013
Applies to: Windows Phone 8 | Windows Phone OS 7.1
Learn about the Windows Phone execution model and what happens when your user switches away from your app. You can also learn about launching an app, transferring data in the background, and running your own code in the background using background agents.
This topic contains the following sections.
Your app can be launched in a variety of ways besides opening it directly from the App list. Some apps launch from a Search quick card to help the user complete a task. Other apps launch to open email attachments. The following figure shows some of the ways that your app can launch.
Much like how URLs are used to navigate from one web page to another in a web browser, URIs are used to navigate from one Windows Phone app to another. In addition to identifying which app to launch, sometimes a URI contains information that your app can use to provide a rich user experience. For example, when an app launches from the picture viewer, the URI includes a token that identifies the picture that the user was just viewing. Because of this token, the user’s photo-editing app can automatically open the picture when the app launches from the picture viewer. This extension of the user experience from one app to another is referred to as extensibility.
Your app can extend the Windows Phone experience from the following locations.
For more info
Search quick cards
Launch with context from product cards, place cards, movie cards, and event cards.
Incorporate wallet functionality in your app.
Music + Videos Hub
Launch to play your app’s media from the Music + Videos Now playing, History, and New lists.
Launch from a secondary Tile to an experience in your app that the Tile represents.
Launch from the picture viewer to share, edit, or open the photo.
Appear in the Photos Hub, a convenient place for photo apps.
Launch to handle a file when the user wants to open a file from another app.
Launch to display the viewfinder of your lens app.
Launch from a URI that another app sends to invoke your app.
You can use APIs from the Windows.Phone.Management.Deployment namespace to see if other apps from your publisher ID are installed on a phone. If they’re installed, you can also use this API to launch them. To demonstrate, the following example enumerates all apps for the current publisher ID and launches the first app in the enumeration (unless that app happens to be the current app).
You can use the Launcher.LaunchUriAsync(Uri) method to launch built-in apps via URI. From the user’s standpoint, this works like Launchers for Windows Phone. But this method allows you to launch some built-in apps that you can’t launch with a Launcher. Unlike a Launcher, this feature can be used by native code. The following figure shows some of the apps that you can launch via URI.
As with a user-initiated launch, the user can still tap the back button to return to your app. The following example shows how to launch the Wi-Fi screen of the Settings app using the ms-settings-wifi URI scheme.
For a list of other built-in URI schemes, see URI schemes for launching built-in apps for Windows Phone 8.
On Windows Phone 8 only one app runs in the foreground at a time. If your app is in the foreground and the user launches another app or presses the Start button to return to the home screen your app is suspended in memory. When the user returns to your app by pressing the back button or by selecting it from the task switcher, your app is resumed. If the device needs to free up memory to make sure that the foreground app is responsive, suspended apps are terminated and info about the state of the terminated apps are saved. This process is called tombstoning. If the user returns to a tombstoned app, the app can use the saved state data to restore the previous session. There are a set of APIs that your app can use to handle the activation and deactivation of your app to provide a consistent user experience. For more info see, App activation and deactivation for Windows Phone.
Windows Phone 8 introduces a new feature, Fast App Resume, that allows you to change the user experience that is presented if the user relaunches your app when an instance is already running. For more info, see Fast app resume for Windows Phone 8.
Only one app runs at a time on Windows Phone, but background agents provide a way for your app to perform tasks, even while it’s not running in the foreground. There are several different types of agents that are provided to enable specific phone features, but the two general purpose agents are the periodic agent and the resource-intensive agent. A periodic agent runs for a brief time on a regularly scheduled interval. This agent is useful for doing a quick query to a web service to refresh local app data. A resource-intensive agent runs for a longer period of time, but only when the phone is idle and connected to external power. This agent is useful for updating large amounts of local data, for example, while the phone is charging at night. To help make sure that the foreground app has the necessary resources to be fast and responsive, there are strict limits on the amount of memory that a background agent can use. For more info, see Background agents for Windows Phone.
If you would like your app to be able to download files in the background but the app doesn’t need to execute any code as you would with a background agent, consider using the background transfer feature. This allows your app to queue up files to be downloaded asynchronously whenever phone resources are available to do so. For more info, see Background file transfers for Windows Phone.