Background tasks, though they are essentially extensions of a app, only have limited capabilities where using the WinRT APIs are concerned. They can access the app’s appdata folders and settings, for example, and perform file I/O with Windows.Storage APIs. No problem there. Background tasks cannot, however, generate UI with the exception of issuing toast notifications and tile update.

Background tasks are also able to perform string lookups in resource files using the Windows.ApplicationModel.Resources.ResourceLoader class or Windows.ApplicationModel.Resources.Core.ResourceManager.current, meaning that they do have access to the app’s localized content.

One issue that comes up with background tasks written in JavaScript is that the task itself, which runs as a web worker, cannot employ the WinJS library. As a result, a JavaScript background task cannot access resources through WinJS.Resources.getString, and occasionally this leads developers to think that background tasks cannot access resources at all. But because this particular WinJS API is implemented with the WinRT APIs, you can just use the latter directly.


  1. Posted August 7, 2013 at 10:33 am | Permalink


    Uhm, we’re happily importing the WinJS’s base.js in our bg tasks and thus also that WinJS.Resource.getString() is available. Therefore, bit confused about this post – any comments?

    Importing the WinJS’s ui.js isn’t obviously possible in bg tasks, but the getString() is defined in the base.js.



    • Posted August 7, 2013 at 4:08 pm | Permalink

      Thanks for the correction–I’ve edited the post accordingly. You’re right in that you can import base.js and use non-UI portions.