MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

• settings Fired in response to Windows.UI.ApplicationSettings.SettingsPane.-
oncommandsrequested. (See Chapter 8.)
With most of these events (except error and settings), the args you receive contains a method
called setPromise. If you need to perform an async operation (like an XmlHttpRequest) within an event
handler, you can obtain the promise for that work and hand it off to setPromise instead of calling its
then or done yourself. WinJS will then not process the next event in the queue until that promise is
fulfilled. Now to be honest, there’s no actual difference between this and just calling done on the
promise yourself within the loaded, ready, and unload events. It does make a difference with activated
and checkpoint (specifically the suspending case) because Windows will otherwise assume that you’ve
done everything you need as soon as you return from the handler; more on this in the “Activation
Deferrals” section. So, in general, if you have async work within these events handlers, it’s a good habit
to use setPromise. Because WinJS.UI.processAll is itself an async operation, the templates wrap it with
setPromise so that the splash screen isn’t removed until WinJS controls have been fully instantiated.
I think you’ll generally find WinJS.Application to be a useful tool in your apps, and it also provides a
few more features as documented on the WinJS.Application page. For example, it provides local, temp,
roaming, and sessionState properties, which are helpful for managing state as we’ll see later on in this
chapter and in Chapter 8.
The other bits are the queueEvent and stop methods. The queueEvent method drops an event into
the queue that will get dispatched, after any existing queue is clear, to whatever listeners you’ve set up
on the WinJS.Application object. Events are simply identified with a string, so you can queue an event
with any name you like, and call WinJS.Application.addEventListener with that same name anywhere
else in the app. This can be useful for centralizing custom events that you might invoke both during
startup and at other points during execution without creating a separate global function for that
purpose. It’s also a powerful means through which separately defined, independent components can
raise events that get aggregated into a single handler. (For an example of using queueEvent, see
Scenario 2 of the App model sample.)
As for stop, this is provided to help with unit testing so that you can simulate different activation
sequences without having to relaunch the app and somehow simulate the right conditions when it
restarts. When you call stop, WinJS removes its listeners, clears any existing event queue, and clears the
sessionState object, but the app continues to run. You can then call queueEvent to populate the queue
with whatever events you like and then call start again to process that queue. This process can be
repeated as many times as needed.
Extended Splash Screens
Now, though the default splash screen helps keep the user engaged, they won’t stay engaged if that
same splash screen stays up for a really long time. In fact, “a really long time” for the typical consumer
amounts to all of 15 seconds, at which point they’ll pretty much start to assume that the app has hung
and return to the Start screen to launch some other app that won’t waste their afternoon.
106