According to page 20 of Introduction to Background Tasks, under Network resource constraints, the background task can download 4.69 MB every 15 minutes.
Does it mean, in Windows RT, if we are downloading 20MB file via IE10 metro in background, it would take 40+ minutes? (otherwise we have to keep the download progress in front)
Also, as a background application, you are not allowed to use more than 0.002% CPU.
On the same page, they argued it like:
Network usage can represent a significant drain on a device battery, and so it is also constrained during background task execution. However, if a device is running on AC power, then background tasks are not network constrained. They are free to use as much network bandwidth as they need (gated, of course, by any carrier-specific bandwidth or usage constraints). Note that CPU usage for a background task is always resource constrained even if the device is running on AC power.
For these very reasons, we cannot implement a download manager for Windows RT? How about with user consent?
There are APIs for offloading downloads for background management by the system:
see Mike Taulty’s blog entry on this. There are other serious restrictions on WinRT apps in background mode not usually discussed in blog posts and forums, such as the fact that your background task runs in a separate process or thread apartment than your app: in the whitepaper linked to above, see the section on Background task host executable. It says that unless your background task is PushNotificationTrigger or ControlChannelTrigger, your task is an inproc server run by BackgroundTaskHost.exe or WWAHost.exe. Even in the first two cases where it runs “in the same app”, it is in a separate apartment. These all can only share data with the main app by marshaling it into files or ApplicationData storage.
I have experimented with ControlChannelTrigger and found the following limitations (also listed in the docs if you dig them out):