MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Finally, avoid using XHR for large file transfers because such operations will be suspended when the
app is suspended. Use the Background Transfer API instead (see the next section), which uses XHR under
the covers, so your web services won’t know the difference anyway!
And on that note, let’s now look at that Background Transfer API in detail.
Sidebar: Debugging Network Traffic with Fiddler
If you’re interested in watching the HTTP(S) traffic between your computer and the
Internet—something that can be invaluable when working with XmlHttpRequests—check out the
freeware tool known as Fiddler (http://www.fiddler2.com/fiddler2/). In addition to inspecting
traffic, you can also set breakpoints on various events and fiddle with (that is, modify) incoming
and outgoing data. It supports traffic from any app or browser, including Windows Store apps.
Background Transfer
One need with user data, especially, is to transfer potentially large files to and from an online repository.
For even moderately sized files, however, this presents a challenge: very few users typically want to stare
at their display to watch file transfer progress, so it’s highly likely that they’ll switch to another app to do
something far more interesting while the transfer is taking place. In doing so, the app that’s doing the
transfer will be suspended in the background and possibly even terminated. This does not bode well for
trying to complete such operations using a mechanism like WinJS.xhr!
One solution would be to provide a background task for this purpose, which was a common request
with early previews of Windows 8 before this API was ready. However, there’s little need to run app code
for this common purpose. WinRT thus provides a specific background transfer API,
Windows.Networking.BackgroundTransfer, supporting up to 500 scheduled transfers systemwide. It
offers built-in cost awareness and resiliency to changes in connectivity, reliving apps from needing to
worry about such concerns themselves. Transfers continue when an app is suspended and will be
paused if the app is terminated. When the app is resumed or launched again, it can then check the
status of background transfers it previously initiated and take further action as necessary—processing
downloaded information, noting successful uploads in its UI, and enumerating pending transfers, which
will restart any that were paused or otherwise interrupted. On the other hand, if the user directly closes
the app (through a gesture, Alt+F4, or Task Manager), all pending transfers for that app are canceled.
This is also true if you stop debugging an app in Visual Studio.
Generally speaking, then, it’s highly recommended that you use the background transfer API
whenever you expect the operation to exceed your customer’s tolerance for waiting. This clearly
depends on the network’s connection speed, and whether you think the user will switch away from your
app while such a transfer is taking place. For example, if you initiate a transfer operation but the user
can continue to be productive (or entertained) in your app while that’s happening, then using WinJS.xhr
with HTTP GET and POST/PUT might be a possibility, though you’ll still be responsible for cost
643