investigate NSURLCache about mbxmapkit

@incanus That sounds good to me. I've been thinking about digging through the WWDC videos and otherwise seeing what sort of best practices there might be around all this stuff since it's not an area I'm particularly familiar with. I did notice some of the built in caching features while digging through the NSURLConnection documentation, and it seems like there's a lot of pretty well developed stuff there we could potentially take advantage of. On my list.

Some interesting references:

• WWDC 2013 session 705
• http://nshipster.com/nsurlcache/ (including notes about implementation not matching documentation)
• http://stackoverflow.com/questions/21540399/afnetworking-image-cache-does-not-empty-on-memory-warning (system wide memory pressure vs. memory warning for an individual app)
• AFNetworking/AFNetworking#1136 (an extended discussion of disk caching issues related to the unreliability of NSURLCache)

And Apple's URL Loading System Programming Guide looks worthy of some serious study too.

From my reading today, it seems like people who attempt to use NSURLCache to meet their needs for persistent offline storage tend to run into problems. However, I get the impression that it does work well for its intended purpose (i.e. act like a cache by improving performance and reducing bandwidth usage).

The core issue seems to be that the semantics of a "cache" and "persistent data store" are very different, but it's tempting to try and lump them together into a single hybrid implementation. NSURLCache can appear to behave like a really handy offline data store, right up until the point that it's called upon to free up space in response to memory pressure.

I'm wondering about possible ways of making a clear distinction between caching for performance and saving map data for offline use. Currently I'm thinking along the lines of:

1. Use NSURLCache for performance caching, configuring it with relatively modest default RAM and disk space limits.
2. Make an offline map manager class which can use an NSURLSession to download all the tiles and associated JSON for in a particular region and save them to a persistent location on disk (i.e. not in the cache directory). These requests would make use of NSURLCache to implement standard HTTP caching behavior along the lines of #46.
3. Configure things so that when loadTileAtPath:result: uses NSURLCache to fetch a tile or JSON file, the following sequence is used by NSURLCache to fulfill the request:
   1. First attempt to get the resource from the normal memory cache,
   2. Next attempt to get the resource from the normal disk cache,
   3. Next attempt to get the resource from the offline map manager <- this is the critical part ,
   4. And if all that fails, finally attempt to download the resource by HTTP

An arrangement like what I described sets up the likelihood that, at times, map data will be present in the persistent store and in the cache, but I argue that is totally acceptable. As long as the NSURLCache disk space limit is set to something reasonable, and we refrain from interfering with its normal mechanisms for responding to memory pressure, there shouldn't be any problem.

NSURLCache is cool, and it works well. I think we should definitely use it for performance caching, and that we should implement a separate tile storage mechanism for persistent offline raster tile layers. See #73 (scroll down a bit)