58 msdn magazine WinJS on Windows 8.1
control with images. If you run this test case through the HTML
UI responsiveness tool, you’ll see output similar to what’s shown
in Figure 19.
Notice the app dropped very few frames aft er I navigated to the
worker.html page (aft er the fi rst user mark in the timeline). Th e UI
remained incredibly responsive because the fetching of data was
off -loaded to the Worker thread.
When to Choose between
the Scheduler and Worker APIs
Because both the Scheduler and the Worker APIs let you manage
background tasks in your code, you might be wondering when to
use one over the other. (Please note that the two code samples I’ve
provided in this article aren’t a fair “apples to apples” comparison
of the two APIs.)
Th e Worker API, because it runs on a diff erent thread, provides
better performance than Scheduler in a head-to-head comparison.
However, because the Scheduler uses timeslices of the UI thread,
it has the context of the current page. You can use the Scheduler
to update UI elements on a page or dynamically create new
elements on the page.
If your background code needs to interact with the UI in any
kind of meaningful way, you should use Scheduler. However, if
your code doesn’t rely on the context of the app and only pass-
es simple data back and forth, consider using a Worker. Th e ben-
efi t of using a Worker thread is that UI responsiveness won’t be
aff ected by the background work.
Th e Scheduler and Web Worker APIs aren’t your only choices for
spawning multiple threads in a Windows Store app. You can also build
a Windows Runtime Component in C++, C# or Visual Basic .NET that
can create new threads. WinRT Components can expose APIs that
the JavaScript code can call. For more information, see bit.ly/19DfFaO.
I doubt many developers set out to write buggy, glitchy or unre-
sponsive apps (unless they’re writing an article about buggy, glitchy
and unresponsive apps). Th e trick is to fi nd those bugs in your
app code and fi x them, preferably before the app goes in front of
users. In this series of articles, I’ve demonstrated several tools for
catching problems in your code and techniques for writing more
effi cient app code.
Of course, none of these techniques or tools is a silver bullet that
will automatically fi x a problem.
Th ey can help improve the expe-
rience, but they don’t eliminate the
need for good coding practices. Th e
fundamentals of programming, in
general, remain as true for Window
Store apps built with JavaScript as
for any other platform. Q
ERIC SCHMIDT is a content developer in the
Microsoft Windows Developer Content
team, writing about the Windows Library
for JavaScript (WinJS). When previously
in the Microsoft Offi ce Division, he built
code samples for the apps for Office
platform. Otherwise, he spends time
with his family, plays string bass, builds
HTML5 video games, or blogs about plastic
building toys (historybricks.com).
THANKS to the following Microsoft
technical experts for reviewing thisarticle: Kraig Brockschmidt, Greg
Bulmash and Josh Williams
(function () {
"use strict";
WinJS.UI.Pages.define("/pages/worker/worker.html", {
ready: function (element, options) {performance.mark("navigated to Worker");var getBaseballCards = new Worker('/js/LOC-worker.js'),
baseballCards = new LOCPictures.Collection({
title: "Baseball cards",
thumbFeatured: null,
code: "bbc"
});getBaseballCards.onmessage = function (message) {
createCollection(message.data);
getBaseballCards.terminate();
}
getBaseballCards.postMessage(baseballCards);
}// Other PageControl members ...
});function createCollection(info) {
var collection = new WinJS.Binding.List(info.pictures),
collectionElement = $("# searchResultsTemplate")[0],
collectionList = new WinJS.UI.ListView(collectionElement, {
itemDataSource: collection.dataSource,
itemTemplate: $('#collectionTemplate')[0],
layout: {type: WinJS.UI.GridLayout}
});}
})();Figure 18 Creating a Worker Thread and Then Populating the UI
Figure 19 HTML UI Responsiveness When Using a Worker Thread