I'm trying to implement caching in my app, I'm using NSURLSession with background configuration for most of my networking needs and it works great but then I'm adding a cache object the session disregards it and always goes to the server
I tried to use default session instance with cache and the system uses the cache
I've read the documentation several times before but there's no mention of disregarding the cache object for background tasks
Does anyone knows if it's a bug or something
Background sessions support only upload and download tasks, not data tasks. And only data tasks use the cache. So there's no reason for a background session to check the cache.
If you want to do caching for downloads, you'll have to explicitly add the response into the shared URL cache yourself, and check to see if it contains a cached response before starting the background task.
For details, see the documentation for NSURLCache.
Wow i asked this question a long time ago, and still no answers.
Tell you the truth, i ended up using a DTS token for this one.
Turns out that NSURLSession background configuration don't support cashing at all, no matter what task you use.
Its a design decision by apple that's badly documented.
Heres part of the DTS replay that i received:
I’m responding to your question about the relationship between NSURLSession background sessions and NSURLCache. You wrote:
Then i add a NSURLCache object to my configuration the NSURLSession mechanism disregards it completely.
Indeed. That is expected behavior, as things currently stand NSURLSession background sessions /never/ cache. There’s a bunch of reasons for this:
It’s infeasible to fully support the
URLCacheproperty. Specifically, we can’t allow you to use a custom subclass of NSURLCache because that would require us to load your code into a system daemon (remember that the actual work here is done by the NSURLSession daemon while your app is suspended, or perhaps even terminated).Even if we limited you to just instances of the standard NSURLCache class, things still get tricky because we would want the disk space used by that cache to be charged to your app. That’s hard to orchestrate given that security barriers between your app and the NSURLSession daemon.
There’s a philosophical disconnect here. NSURLSession background sessions were intended to be used for a small number of large transfers, while NSURLCache is only really useful when you’re doing a large number of small transfers.
Note: Running lots of small transfers through an NSURLSession background session is likely to cause problems for other reasons. For more info on this, read the following DevForums posts:
- NSURLSession’s Resume Rate Limiter
https://forums.developer.apple.com/message/42352#42352
- Moving to Fewer, Larger Transfers
https://forums.developer.apple.com/thread/14853
If you’d like the NSURLSession engineers to reconsider this caching design decision, you should feel free to file a bug requested that this be supported. Make sure you explain your use case in detail.
https://developer.apple.com/bug-reporting/
Your bug may be returned as ‘behaves correctly’, but it doesn’t hurt to ask.
On the subject of bugs, I presume you looked through the NSURLSession documentation and didn’t find this gotcha documented. If so, I’d appreciate you filing a bug against the documentation that you looked at requesting that it include information about this issue.
