Once you develop a media-rich project or two where you end up loading a bunch of smaller resources that may or may not be visible to the user at any given time (experiences like email, image galleries, and video games fit this description), you realize that having a dynamic cache of these resources is necessary to make the user's experience fluid.  This is because available memory is smaller than the amount needed to keep all resources in memory at once, thus available for rendering at any time.  However, you don't want an upper layer view (as in the MVC pattern) to manage or deal with the details of what does & doesn't fit in memory: the abstraction it should deal with is to fetch and display the information.  Additional complexity would be added when multiple views simultaneously manage these resources.

Instead of thinking about keeping resources in memory, maybe we can simply fetch them every time they are needed by a view?  Usually, these resources require some transformation before being displayed (decompression, color palette lookups, etc.) or they are very latent in their retrieval (stored on a DVD or on the internet behind a URL).  Media rich applications typically need to support some form of animation or other dynamism with these resources - updating these resources in response to animation requires keeping them around in their transformed formats.  When animations run every 16ms (at 60 frames per second), and resource retrieval and transformation can take hundreds of milliseconds, fetching every time a resource is needed is not a valid solution.

So, a layer between views and resources is needed.  This cache would be responsible for fetching resources as requested by views and transforming them to a usable state before handing them back to the view.  Since the fetch and transformation is very latent, the cache remains in an indeterminate state between the first request and the completion of the fetch.  Either the cache or view can decide what to do in this case by showing a placeholder resource, or waiting until the fetch is complete.  Since it's a cache, there is also an eviction policy.  This could be size-related, or time-related.  For software programs that could cache their resources across sessions (such as web browsers), having the cache backed by storage is important.  Most any software programmer should be familiar with these concepts.

So why write a blog post about it?  In iOS, Apple has provided a great many libraries to create media-rich applications: CoreAnimation, CoreImage, etc.  But, a resource cache abstraction that is backed by application-owned storage is curiously missing.  Of course, the community has filled the gap, but this is code that only really needs to be solved once as most applications in this style have very similar use cases.  An especially interesting scenario is an application browsing a bunch of images downloaded from the Internet.  This isn't narrowly scoped to photo album viewers, but includes apps that show box art or product photos, for example.

This post details a great solution in code.  A commenter created this github repository with a cohesive implementation that includes a UIImageView protocol category that helps you use this kind of caching transparently.  If your app has anything to do with downloading lots of images, I highly recommend using this library or writing your own based on the details from the linked post.

~s