MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

Roaming State
The automatic roaming of app state between a user’s devices is one of the most interesting and
enabling features of Windows 8. There are few areas where a small piece of technology like this has so
greatly reduced the burden on app developers!
It works very simply. First, your app data roamingFolder and your roamingSettings container behave
exactly like their local counterparts. So long as their combined size is less than Windows.Storage.-
ApplicationData.current.roamingStorageQuota, Windows will copy that data to other devices where
the same user is logged in has the same app installed; in fact, when an app is installed, Windows
attempts to copy roaming data so that it’s there when the app is first launched.
If the app is running simultaneously on multiple devices, the last writer of any particular file or setting
always wins. When data has been roamed the other apps will receive the
Windows.Storage.-ApplicationData.ondatachanged event. So your app will always read the
appropriate roaming state on startup and refresh that state as needed within datachanged. You should
always employ this strategy too in case Windows cannot bring down roaming state for a newly installed
app right away (such as when the user installed the app and lost connectivity). As soon as the roaming
state appears, you’ll receive the datachanged event. Scenario 5 of the Application data sample provides
a basic demonstration of this.
Deciding what your roaming experience really looks like is really a design question more than a
development question. It’s a matter of taking all app settings that are not specific to the device
hardware (such as settings that are related to screen size, video capabilities, or the presence of particular
peripherals or sensors), and thinking through whether it makes sense for each setting to be roamed. A
user’s favorites, for example, are appropriate to roam if they refer to data that isn’t local to the device.
That is, favorite URIs or locations on a cloud storage service like SkyDrive, FaceBook, or Flickr are
appropriate to roam; favorites and recently used files in a user’s local libraries are not. The viewing
position within a cloud-based video, like a streaming movie, would be appropriate to roam, as would be
the last reading position in a magazine or book. But again, if that content is local, then maybe not.
Account configurations like email settings are often good candidates, so the user doesn’t have to
configure the app again on other devices.
At the same time, you might not be able to predict whether the user will really want to roam certain
settings. In this case, the right choice is to give the user a choice! That is, include options in your Settings
UI to allow the user to customize the roaming experience to their liking, especially as a user might have
devices for both home and work where they want the same app to behave differently. For instance, with
an RSS Reader the user might not want notifications on their work machine whenever new articles
arrive, but would want real-time updates at home. The set of feeds itself, on the other hand, would
probably always be roamed, but then again the user might want to keep separate lists.
To minimize the size of your roaming state and stay below the quota, you might employ the
Windows.Storage.Compression API for file-based data. For this same reason, never use roaming state for
user data. Instead, use an online service like SkyDrive to store user data in the cloud, and then roam URIs
to those files as part of the roaming experience. More details on using SkyDrive through its REST API can
331