MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

it simpler and one that we’ve already seen in the template code:
• If the activation kind is launch and the previous state is notrunning or closedByUser, the app
should start up with its default UI and apply any persistent state or settings. With closedByUser,
there might be scenarios where the app should perform additional actions (such as updating
cached data) after the user explicitly closed the app and left it closed for a while.
• If the activation kind is launch and the previous state is terminated, the app should start up in
the same state as when it was last suspended.
• For launch and other activation kinds that include additional arguments or parameters (as with
secondary tiles, toast notifications, and contracts), it should initialize itself to serve that purpose
by using the additional parameters. The app might already be running, so it won’t necessarily
initialize its default state again.
The second requirement above is exactly why the templates provide a code structure for this case
along with a checkpoint handler. We’ll see the full details of saving and reloading state in Chapter 8.
The basic idea is that an app should, when being suspended if not sooner, save whatever transient
session state it would need to rehydrate itself after being terminated. This includes unsubmitted form
data, scroll positions, the navigation stack, and other variables. This is because although Windows might
have suspended the app and dumped it from memory, it’s still running in the user’s mind. Thus, when
users activate the app again for normal use (activation kind is launch, rather than through a contract),
they expect that app to be right where it was before. By the time an app gets suspended, then, it needs
to have saved whatever state is necessary to make this possible. It then restores that state when
previousExecutionState is terminated.
For more on app design where this is concerned, see Guidelines for app suspend and resume. Be
clear that if the user directly closes the app with Alt+F4 or the swipe-down gesture, the suspending and
checkpoint events will also be raised, so the app still saves session state. However, the app will be
automatically terminated after being suspended, and it won’t be asked to reload session state when it’s
restarted because previousExecutionState will be notRunning or closedByUser.
It works out best, actually, to save session state as it changes during the app’s lifetime, thereby
minimizing the work needed within the suspending event (where you have only five seconds). Mind
you, this session state does not include data that is persistent across sessions like user files, high scores,
and app settings, because an app would always reload or reapply such persistent data in each activation
path. The only concern here is maintaining the illusion that the app was always running.
You always save session state to your appdata folders or settings containers, which are provided by
the Windows.Storage.ApplicationData API. Again, we’ll see all the details in Chapter 8. What I want to
point out here are a few helpers that WinJS provides for all this.
First is the WinJS.Application.checkpoint event, which provides a single convenient place to save
both session state and any other persistent data you might have, if you haven’t already done so.
Second is the WinJS.Application.sessionState object. On normal startup, this is just an empty
112