MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Composites are, in many ways, like their own kind of settings container, just that they cannot contain
additional containers. It’s important to not confuse the two. Child containers within settings are used
only to create a hierarchy (refer to Scenario 3 in the sample). Composites, on the other hand, specifically
exist to create more complex groups of settings that act like a single unit, a behavior that is not
guaranteed for settings containers themselves.
As noted earlier, these settings are all written to the settings.dat file in your app data Settings folder.
It’s also good to know that changes you make to settings containers are automatically saved, though
there is some built-in batching to prevent excessive disk activity when you change a number of values
all in a row. In any case, you really don’t need to worry about when you save settings; the system will
manage those details.
Versioning App State
From Windows’ point of view, local, temp, and roaming state are all parts of the same whole and all
share the same version. That version number is set with
Windows.Storage.ApplicationData.-setVersionAsync, the value of which you can retrieve through
Windows.Storage.Application-Data.version (a read-only property). If you like, you can maintain your
own versioning system within particular files or settings. I would recommend, however, that you avoid
doing this with roaming data because it’s hard to predict how Windows will manage synchronizing
slightly different structures. Even with local state, trying to play complex versioning games is, well, rather
complex, and probably best avoided altogether.
The version of your app data is also a different matter than the version of your app; in fact, there is
really no inherent relationship between the two. While the app data version is set with
setVersion-Async, the app version is managed through the Packaging section of the app manifest. You
can have versions 1.0.0.0 through 4.3.9.3 of the app use version 1.0.0.0 of app data, or maybe version
1.2.1.9 of the app shifts to version 1.0.1.0 of the app data, and version 2.1.1.3 moves to 1.2.0.0 of the app
data. It doesn’t really matter, so long as you keep it all straight and can migrate old versions of the app
data to new versions!
Migration happens as part of the setVersionAsync call, whose second parameter is a function to
handle the conversion. That function receives a SetVersionRequest object that contains
currentVersion and desiredVersion properties, thereby instructing your function as to what kind of
conversion is actually needed. In response, you should go through all your app data and migrate the
individual settings and files accordingly. Once you return from the conversion handler, Windows will
assume the migration is complete. Of course, because the process will often involve asynchronous file
I/O operations, you can use a deferral mechanism like that we’ve seen with activation. Call the
SetVersionRequest.getDeferral method to obtain the deferral object (a SetVersionDeferral), and call
its complete method when all your async operations are done. Examples of this can be found in Scenario
9 of the Application data sample.
320