MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

hundred kilobytes—if you know from analytics that a user that views one set of data is highly likely to
view another, automatically acquiring and caching those additional data sets could be the right design.
The best place to store cached data is your app data folders, specifically the LocalFolder and
TemporaryFolder. Avoid using the RoamingFolder to cache data acquired from online sources: besides
running the risk of exceeding the roaming quota (see Chapter 8, “State, Settings, Files, and Documents”),
it’s also quite pointless. Because the system would have to roam such data over the network anyway, it’s
better to just have the app re-acquire it when it needs to. The same applies to in-app purchases:
because the user can easily acquire those purchases through the Windows Store on another machine
(where the app on that machine would find that those purchases are already paid for), they need not be
roamed.
Whether you use the LocalFolder or TemporaryFolder depends on how essential the data is to the
operation of the app. If the app cannot run without the cache—such as the cookbook app I mentioned
earlier—use local app data. If the cache is just an optimization such that the user could reclaim that
space with the Disk Cleanup tool, store the cache in the TemporaryFolder and rebuild it again later on.
(Be aware once again that IndexedDB, as described in Chapter 8, has a per-app limit and an overall
system limit. If this is a potential problem, you might want to choose a different storage mechanism.)
In all of this, also consider that what you’re caching really might be user data that you’d want to store
outside of your app data folders. That is, be sure to think through the distinction between app data and
user data!
Finally, you might again have the kind of app that allows offline activity (like processing email) where
you will have been caching the results of that activity for later synchronization with an online resource.
When connectivity is restored, then, check if the network cost is suitable before starting your sync
process.
Sidebar: Connectivity and Remote Images in Live Tiles and Toasts
In Chapter 13 we looked at how an app appears “alive with activity” through features such as live
tiles and notifications. Clearly, periodic updates and push notifications are completely dependent
on connectivity and will not operate without it; a running app, on the other hand, can still issue
updates when the device is offline. Under such a circumstance, the app must avoid referencing
remote images in the update, because these will not be resolved without connectivity and the tile
and toast systems do not presently support the use of local fallback images. An app should thus
check connectivity status before issuing an update and should make sure to use local
(ms-appx:/// or ms-appdata:///) images instead of remote ones or opt for text-only tile and toast
templates.
641