In this chapter we’re going to look at how we can make portions of our code run even when our app is not—a capability known as background tasks.
Background tasks are easy enough to work with, but they are one of the areas of Windows Store apps that is on the “difficult” end of the spectrum in terms of features in the API. This is because, with mobile, preserving battery life is paramount. Applications that can wake up and do whatever they like in the background are a problem, because without any form of control it’d be easy enough for the user to install some innocuous app, only to find that battery life on the device had halved without any real idea as to why.
In Windows 8/Windows RT, there are so many controls and restrictions on what background tasks can do that you could describe them as being openly hostile to apps that need to run in the background. The reason for this is that background tasks are designed to keep the device “fresh,” but to do so within the context of a consumer/retail usage model. With LOB apps there is much more pressure on time, and it’s this part that’s not fantastically well served by the background tasks implementation as it stands at the time of writing. For example, a 10-minute delay in updates on a game is fine. If you have employees doing 20 jobs a day coordinated by your app with a 10-minute delay, however, that’s a 3.3-hour delay per operative inserted into each working day just for idle time.
It’s in ...