In Windows 8, Windows Store (formally known as metro style) apps have the ability to define background tasks that can perform tasks that run even when the app isn’t in the background. Though to make sure the user’s battery doesn’t cry uncle prematurely these background tasks are resource constrained. In this post we’ll take a look at how Windows 8 does resource management for background tasks.
Windows 8 performs resource management for background tasks through the use of resource constraints. There are two main types of constraints a background task needs to worry about: CPU time and network usage. The amount of CPU time and network usage an app’s background task is allocated depends on if the app is on the lock screen or not.
A Windows Store app is considered a lock screen app if it occupies one of the seven available lock screen slots on the lock screen.
When your app is a lock screen app Windows will give your background tasks a higher quality of service over resources then a non-lock screen app. The CPU time constraint is enforced regardless of the current power state of the device but the network usage constraints only come into play when PC off of AC power.
Note: Windows will dynamically adjust the network usage constraint based on the power usage of the active network link. Typically, Wi-Fi connections use less power than the cellular connections and will be allowed to send more over the link over a given period of time than cellular connections.
Among all the possible triggers available to an app to trigger their background tasks the following triggers are considered “critical” as far a Windows is concerned.
- Push notification trigger
- Control channel trigger
These triggers are meant to be used during real time scenarios like receiving a VOIP call. These background tasks are given guaranteed app resource quotas according to the resource quotas listed previously. Meaning Windows will not try and terminate these tasks early even if the system becomes resource constrained. These triggers require an app to be a lock screen app in order to be used.
If your app doesn’t require the increased resources or trigger capabilities of a lock screen app you’re better off sticking with triggers that don’t require lock screen capabilities. It’ll simplify things but from a programming and certification standpoint and from a user standpoint in terms of battery life.
If you do require lock screen capabilities for your background tasks here’s what you need to know. To be on the lock screen you’ll need to provide an additional image asset, a 24 by 24 pixel png image, for the badge that gets displayed on the lock screen. As there are only 7 slots available on the lock screen for apps you’ll be competing with other apps for those slots so you’ll have to make a compelling case to the user to add your app. Which brings us to our next point, the app will needs to be added to the lock screen explicitly by the user.
That last point is key, there is no programmatic way to add an app the lock screen. Windows does toss the app a bone by giving a way for the app to programmatically ASK the user to add the app to the lock screen though the BackgroundExecutionManager.RequestAccessAsync() method but it comes with a big caveat. It’s a one shot deal. No matter the outcome: yes, no or dismissed it will only work once.