Background Tasks – Myths and Realities

A few weeks ago I was searching the forums looking for “hot spots” and noticed that there were a lot of misconceptions around Background Tasks. After about an hour of searching I was able to put together a list of what I feel are common misconceptions about Background Tasks. In the spirit of my favorite edu-tainment television show, here is a list of Background Task myths and the realities behind them.

Myth: Background tasks are not useful because Microsoft has placed so many restrictions on them.

Most Windows developers new to Window Store apps believe this myth. This is likely due to the fact that in traditional desktop development you can create a service that will always run in the background with few and in some cases no restrictions. While this is a perfectly acceptable model for a device that will always be plugged into the wall, this may not be the best architecture for mobile and portable devices. Windows 8 and 8.1 are designed to run on a variety of portable and mobile devices. The architects of the Windows Store app background task APIs needed to find an architecture that would balance functionality while preserving battery life and user choice. These compromises did not come lightly. An innumerable number of conference room and hallway discussions were required before settling on this design. The intent is not to hamstring functionality but to give developers the basic functionality they need in the mobile environment. Keep in mind that as device and mobile app needs change we will continue to evolve the background task APIs to fit these new scenarios. So stay tuned.

Myth: I have lengthy process that needs to take place. If my app is suspended I want the process continue. I can just stuff it in a background task so that it will complete.

This depends on how long your long running process will be. Keep in mind that for the sake of battery life we limit the number of background tasks that can run, how often they run, and how long they can run for. If you are trying to download the 3 hour extended version of Peter Jackson’s “Lord of the Rings” in full HD in a background task you are likely going to be out of luck. Luckily we have a different way to go about this called the BackgroundDownloader class. Keep in mind that background tasks are really designed to grab a tiny bit of data to update a tile, badge or lock screen sigil. They are not designed to encode video, download the library of congress, bubble sort the last name of every person in the US, etc. You want your background task to wake up, grab what you need, show it in a meaningful way and go back to sleep.

Myth: You need to use a standard background task to play audio when your app is not active.

Background audio can be played using the “background audio” capability of the MediaElement or the “audio / video” tag. Keep in mind that in order for your app to properly be able to play audio in the background you must implement the SystemMediaTransportControls class. This class replaces the MediaControl class. I guess they thought the old name was too confusing and renamed it. They both do exactly the same thing. They allow the user to control music playback using the hardware buttons or the soft buttons on the lock screen.

Myth: My timer background task will still run as long as I have permission to run on the lock screen.

Well, “yes” and “no”. If the user has given you permission to run on the lock screen and you are given a space on the lock screen your background task will run when expected. If they have removed you from the lock screen because there is not enough space then your timer background task will not run if the device is locked. If you’re not on the lock screen when locked then you don’t really need to update any information in your sigil and really have no reason to run. Again this is to help maximize battery life.

Myth: I don’t need to register a cancelation handler if my background task runs for less than one second.

You should always allow for background task cancelation even if it only runs for a very short period of time. Your background task can be canceled for any number of different reasons. If you have a long running task and ignore the cancel message you may end up loosing data or not completing the task correctly. Because of this you should check for the canceled state as often as it makes sense in your task. At a bear minimum you should check for the canceled state before the task starts. However it is advised that you check for the canceled state within each section of your background task code. For example: Your background task downloads data, processes the data and then saves that data. You should check for cancel at each section. For example: At the beginning before you process the data and just before you go to save the data. While this might not strictly be necessary it is good practice.

Myth: Background tasks and async calls don’t mix.

This can be true if you’re not careful... Luckily the architects of the background task subsystem have a workaround for us. We can ask for a deferral. When we request a deferral, even if Run returns our async operation and the remainder of our code is allowed to complete before we can be suspended or shutdown. The only gotcha is to make sure that if you request a deferral you must call Complete on the deferral before exiting your function. If you fail to call Complete you could risk a memory leak. Most of the time when you have trouble with async calls in a Background Task you will notice that the line where you await your async method will execute and then nothing after that will be called. While this is counter intuitive it is possible for the run method to return before the background task has completed. As soon as the Run method returns the background task can be suspended or terminated by the host process. This can cause the remainder of the code in your background task to keep from running.

Myth: I have to use WNS for all push notifications. I can’t host my own.

This is not true. We have added the network trigger API to allow for scenarios just like this. The network trigger api is available for apps that must maintain a persistent transport connection in the background. Windows Push Notification Services (WNS) has many benefits like reduced operating costs, less code to write, and language independence. The biggest drawback of WNS is that it is considered “best effort”. There is no guarantee of delivery. While we encourage developers to use WNS; if you need guaranteed delivery then you should consider the network trigger apis. Keep in mind that your network trigger based app must also be registered on the lock screen. Because of this you can’t guarantee that your network trigger background task will run if your sigil has been bumped from the lock screen.

 

Background Task Reference Guide

Supporting your app with background tasks (Windows Store apps using JavaScript and HTML

Being productive in the background – background tasks

Guidelines for background tasks (Windows Store apps)

Quickstart: Create and register a background task (Windows Store apps using C#/VB/C++ and XAML)

How to debug a background task (Windows Store apps)

 

-Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.