MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

operations—it is possible to create a bunch of temporary files from the single source. If you’re up to a
challenge, I invite to you write such a routine and post it somewhere for the rest of us to see!
But there is an easier path using createUploadFromStreamAsync, through which you can create
separate UploadOperation objects for different segments of the stream. Given a StorageFile for the
source, start by calling its openReadAsync method, the result of which is an
Irandom-AccessStreamWithContentType object. Through its getInputStreamAt method you then
obtain an IInputStream for each starting point in the stream (that is, at each offset depending on your
segment size). You then create an UploadOperation with each input stream by using
create-UploadFromStreamAsync. The last requirement is to tell that operation to consume only some
portion of that stream. You do this by calling its setRequestHeader("content-length", ) where
is the size of the segment plus the size of other data in the request; you’ll also want to add a
header to identify the segment for that particular upload. After all this, call each operation’s startAsync
method to begin its transfer.
Multipart Uploads
In addition to the createUpload and createUploadFromStreamAsync methods, the BackgroundUploader
provides another method called createUploadAsync (with three variants) that handles what are called
multipart uploads.
From the server’s point of view, a multipart upload is a single HTTP request that contains various
pieces of information (the parts), such as app identifiers, authorization tokens, and so forth, along with
file content, where each part is possibly separated by a specific boundary string. Such uploads are used
by online services like Flickr and YouTube, each of which accepts a request with a multipart
Content-Type. (See Content-type: multipart for a reference.) For example, as shown on Uploading
Photos – POST Example, Flickr wants a request with the content type of multipart/form-data, followed
by parts for api_key, auth_token, api_sig, photo, and finally the file contents. With YouTube, as
described on YouTube API v2.0 – Direct Uploading, it wants a content type of multipart/related with
parts containing the XML request data, the video content type, and then the binary file data.
The background uploader supports all this through the BackgroundUploader.create-UploadAsync
method. (Note the Async suffix that separates these from the synchronous createUpload.) There are
three variants of this method. The first takes the server URI to receive the upload and an array of
BackgroundTransferContentPart objects, each of which represents one part of the upload. The
resulting operation will send a request with a content type of multipart/form-data with a random GUID
for a boundary string. The second variation of createUploadAsync allows you to specify the content type
directly (through the sub-type, such as related), and the third variation then adds the boundary string.
That is, assuming parts is the array of parts, the methods look like this:
var uploadOpPromise1 = uploader.createUploadAsync(uri, parts);
var uploadOpPromise2 = uploader.createUploadAsync(uri, parts, "related");
var uploadOpPromise3 = uploader.createUploadAsync(uri, parts, "form-data", "-------123456");
649