Graphics Programs Reference
In-Depth Information
For the More Curious: Automatic Caching and Cache.db
While in
Nerdfeed
's sandbox, you may have noticed a file named
Cache.db
. This file
contains data that resembles the XML and JSON returned from the RSS web services. iOS
applications keep the data from web service requests here. When an HTTP request is made,
the response from the server may tell the application, “This data will be good for a day, so
don't bother me again in the meantime.” An iOS application has built-in behavior to under-
stand this response and to cache the data returned in the
Cache.db
file until it “expires.”
Earlier in the chapter, when asking repeatedly for Apple's top songs feed, you may have
noticed that the repeated requests returned very quickly - even before we implemented
caching of our own. This was automatic caching at work. Automatic caching is especially
useful for loading web pages, and it is what makes
Safari
run reasonably fast even on an
iOS device.
So why, then, did we write our own caching mechanism for the RSS feeds? For applica-
tions that interact with web services and present data in their own views, automatic caching
is not useful for two reasons. The first is that you have no control over the
Cache.db
file
and its caching process, like what data gets saved and for how long.
The other reason is that automatic caching stores all of the data from a web service request
in the format in which it was delivered. Using this cached data, then, would be a step back-
ward for us in
Nerdfeed
. For example, in retrieving the BNR form feed from the web serv-
er, we already parse a subset of XML into
RSSItem
instances from the response. So we're
better off caching data in
RSSItem
s for later retrieval than using the data in
Cache.db
,
which we'd have to figure out how to read, load, and parse again from scratch.
It doesn't usually harm anything to let an iOS application keep a cache even if you are
keeping one of your own. Sometimes, though, it is a problem. This is the case when your
application downloads large files, like images and PDFs. The application will not only save
these big files to the filesystem, but it might also keep them in memory for a long time.
For example, if you created an application that downloads and renders PDFs, it might store
those PDFs in its own cache and then render them. Rendering a PDF is really memory-in-
tensive, and if the built-in cache is keeping another copy of the PDF file for itself, your ap-
plication may run out of memory and be shut down.
