MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Background Tasks and Lock Screen Apps
At the end of the introduction to this chapter, I described how everything we’ve talked about so far
helps to “create an environment that is alive with activity while those apps are often not actually
running or are allowed to run just a little bit.” It’s that last phrase—being allowed to run just a little bit
through background tasks—that is our last topic for this chapter. And as described earlier as well,
background tasks are related to the lock screen because the apps that are allowed to work on the lock
screen must also employ certain background tasks.
Let me reiterate here that we’ve already seen a number of scenarios in which the user can experience
app-related activity without the app having to run. Periodic tile updates, push notifications, scheduled
toasts, and even sharing data through the Share contract all provide for activity when an app is
suspended or not running. Apps can also configure background data transfers to occur while the app
isn’t running, as we’ll see in Chapter 14, “Networking.” And background audio provides for that specific
class of apps that need to continue running to maintain VoIP sessions, audio playback, online meetings,
and so forth.
What’s left in the story are those little pieces of app code that Windows can run in response to
specific triggers. Triggers in some cases can be further refined with optional conditions so that the
background task runs only when it really needs to. This is all to minimize the amount of background
activity that can drain a device’s battery. Some types of triggers, in fact, require that the user has placed
the app on the lock screen to specifically limit the number of apps that can respond to those triggers.
Furthermore, Windows also limits the amount of CPU time that background tasks can consume:
• Lock screen background tasks Two seconds of cumulative CPU time per 15 minutes.
• Other background tasks One second of cumulative CPU time every two hours.
Consumption of network bandwidth is also limited on battery power. What that limit is, exactly, I
cannot say, because the system analyzes energy usage more so than bytes transferred. A means of
estimating the limit can be found on Supporting your app with background tasks. (While we’re at it, you
might also be interested in Guidelines and checklists for background tasks, the Introduction to
background tasks whitepaper, and Being productive in the background – background tasks on the
Windows Blog.)
“Whoa!” you’re probably saying, “Is Windows 8 really that restrictive?”
The short answer is yes, because Windows not only wants to save battery power for the foreground
app with which a user is engaged, but also wants to make sure the foreground app delivers the best
user experience. This means it isn’t having to complete with background apps that would, if allowed,
take up as many resources as they possibly can. (Developers of background services will always find a
justification for hogging up resources!)
It’s likely that you’ve experienced situations like this directly, where you’ve started an app but it takes
for-EV-er to start up because some other dark and mysterious services is chewing on the hard drive,
615