MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

It’s perfectly understood that some apps just can’t run without connectivity, in which case it’s
appropriate to inform the user of that situation when the app is launched or when connectivity is lost
while the app is running. In other situations, an app might be partially usable, in which case you should
inform the user more on a case-by-case basis, allowing them to use unaffected parts of the app. Better
still is to cache data that might make the app even more useful when connectivity is lost. Such data
might even be built into the app package so that it’s always available on first launch.
Consider the case of an ebook reader app that would generally acquire new titles from an online
catalog. For offline use it would do well to cache copies of the user’s titles locally, rather than rely solely
on having a good Internet connection. The app’s publisher might also include a number of popular free
titles directly in the app package such that a user could install the app while waiting to board a plane
and have at least those books ready to go when the app is first launched at 30,000 feet. Other apps
might include some set of preinstalled data at first and then add to that data over time (perhaps
through in-app purchases) when unrestricted networks are available. By following network costs closely,
such an app might defer downloading a large data set until either the user confirms the action or a
different connection is available.
How and when to cache data from online resources is probably one of the fine arts of software
development. When do you download it? How much do you acquire? Where do you store it? Should
you place an upper limit on the cache? Do you allow changes to cached data that would need to be
synchronized with a service when connectivity is restored? These are all good questions ask, and
certainly there are others to ask as well. Let me at least offer a few thoughts and suggestions.
First, you can use any network transport to acquire data to cache such as WinJS.xhr, the background
transfer API, as well as the HTML5 AppCache mechanism, which works well for web content you load up
in iframe elements. Note that using the AppCache requires that the URIs in question are declared in the
manifest as ApplicationContentUris (see Chapter 3, “App Anatomy and Page Navigation”). Separately,
other content acquired from remote resources, such as images, are also cached automatically like
typical temporary Internet files. Even remote script downloaded within a web context iframe is cached
this way. Both caching mechanisms are subject to the storage limits defined by Internet Explorer.
How much data you cache depends, certainly, on the type of connection you have and the relative
importance of the data. On an unrestricted network, feel free to acquire everything you feel the user
might want offline, but it would be a good idea to provide settings to control that behavior, such as
overall cache size or the amount of data to acquire per day. I mention the latter because even though
my own Internet connection appears to the system as unrestricted, I’m charged more as my usage
reaches certain tiers (on the order of gigabytes). As a user, I would appreciate having a say in matters
that involve significant network traffic.
Even so, if caching specific data will greatly enhance the user experience, separate that option to give
the user control over the decision. For example, an ebook reader might automatically download a whole
title while the reader is perhaps just browsing the first few pages. Of course, this would also mean
consuming more storage space. Letting users control this behavior as a setting, or even on a per-book
basis, lets them decide what’s best. For smaller data, on the other hand—say, in the range of several
640