When Windows Phone first launched I spoke about Windows Phone and multitasking and how at the core of it, Windows Phone was a full blown multitasking and real-time operating system.
Unfortunately for developers, this was not full exposed to us and the reason for this was to maintain a good user experience which included performance and battery power.
Looking back, the concept of ‘Tombstoning’ was added to allow developers to write their applications to give the user of ‘true multitasking’. Not the best scenario as is does take some time to get your head wrapped around the Tombstoning concept. I’m not going to go through Tombstoning here as it has been extensively covered. Here are a few links from MSDN to help you out in case youa re not familiar with it
- Execution Model Overview for Windows Phone
- How to: Preserve and Restore Page State for Windows Phone
- How to: Preserve and Restore Application State for Windows Phone
In Pre-Mango devices, you again have the concept of Tombstoning to give the user the illusion of multitasking. Another option made to developers is UserIdleDetectionMode and ApplicationIdleDetectionMode. What exactly are they?
UserIdleDetectionMode mode allows you to force the screen to stay on. So if you are create an application that will track a user as they drive and show their location on a Bing Map control, this is the property you will want to use. But be cautious when using it as it could drain the battery life extremely fast depending on your scenario. To use it is fairly simple and can be achieved with the following code.
Microsoft.Phone.Shell.<span style="color: #2b91af;">PhoneApplicationService</span>.Current.UserIdleDetectionMode =
Microsoft.Phone.Shell.<span style="color: #2b91af;">IdleDetectionMode</span>.Disabled;
The other option is ApplicationIdleDectionMode. This API allows you to run your application under the lock screen. So essentially, if your application is running and the device locks or the user locks the screen, your code will still be executing. So if you are running a background thread, when the device locks the code will still be running. To achieve this is again relatively simple and can be achieved with one line of code
Microsoft.Phone.Shell.<span style="color: #2b91af;">PhoneApplicationService</span>.Current.ApplicationIdleDetectionMode
= Microsoft.Phone.Shell.<span style="color: #2b91af;">IdleDetectionMode</span>.Disabled;
Now, a couple of caveats to ApplicationIdleDetectionMode and UserIdleDetectionMode.
- If the user navigates away from your application, your application will be tombstoned and ApplicationIdleDetectionMode and UserIdleDetectionMode will not work.
- Part of the Marketplace Certification requirements are to notify the user that you will be running code in the background. This way the user is aware of what is happening and has the option to turn these features on or off. If you do not do this you will fail certification.
NOTE: UserIdleDetectionMode I would not say is “multitasking” but something a lot of developers are not aware of so figure I would cover it.
With the announcement of Windows Phone 7.1 Mango , there were a few announcements about multitasking on Windows Phone that will address some of the challenges with the platform.
Now, as a developer you have to keep in mind that the core goal of the product team is to maintain a great end user experience. Although developers are not first in line, the product team is paying attention to developer pains and fixing it, as long as it doesn’t deteriorate the end user experiences on Windows Phone. With Windows Phone 7.1 as developers we get a bit more power in terms of running our code when our application is not running and there are a few options to accomplish this.
- Background Audio – essentially, this will allow you to play any audio while another application is running. Essentially, your application will be running, then you can continue playing the audio while the user goes off and uses another application. The key class to use here is AudioPlayerAgent
- Background File Transfers – here you essentially can queue up HTTP file transfer requests for uploading or downloading and which will be run even if your application is not running. In some scenarios this can be useful for example when uploading a large image. The main class you want to look at here is BackgroundTransferRequest
- Fast Application Switching – here the short story is users will not see as long of a delay when switching apps as they did in pre mango. Reason is because your application will be dormant but still in memory and not tombstoned. I’ll follow up with more details on FAS in an upcoming article.
- Scheduled Notifications – this allows you to create reminders or alarms that will be handled by the system. You essentially create your items, pass it to the OS, and the OS will handle showing them to the user.
- Scheduled Tasks – this is essentially a task that will run in the background and probably the one that will be used in most scenarios. Scheduled tasks will run in the background even when your application is not running. There are two types you can create and these are PeriodicTasks and ResourceIntensiveTasks.
As you can see, as developers we now have a little more of the platform exposed to us in ways that will not entirely affect the user experience. From playing around with the beta tools future for Windows Phone 7 from a developer’s perspective looks great! And best of all, the end user experience is not degraded and they continue to use the phone and our apps.
I’ll do some follow up posts on the items above and give more details on the different ways developers can implement multitasking on Windows Phone 7.1.