Is NSData + (id) dataWithContentsOfURL: (NSURL *) aURL options: (NSDataReadingOptions) mask error: (NSError **) errorPtr: is automatically cached?

When I read the section on

NSDataReadingOptions Options for methods used to read NSData objects. enum { NSDataReadingMappedIfSafe = 1UL << 0, NSDataReadingUncached = 1UL << 1, NSDataReadingMappedAlways = 1UL << 3, }; typedef NSUInteger NSDataReadingOptions; 

It says that

NSDataReadingUncached Hint indicating the file should not be stored in the file system caches. To read data once and discard this option can improve performance. Available on OS X version 10.6 and later. Announced in NSData.h.

So, I assume that by default, these URL requests are cached and there is no need to implement NSURLRequest to cache data if I want to use a shared global cache? Is this understanding correct?

+4
source share
2 answers

There is no answer to your specific question regarding caches managed by the URL loading system.

The read parameters in the dataWithContentsOfFile:options:error: method relate exclusively to reading from the file system (see the official NSDataReadingOptions documentation).

Unfortunately, the documentation does not talk about reading behavior from remote resources. Regardless of whether the response is cached in the URL cache, we do not know, and the internal behavior and implementation may change with each new version of the OS.

IMHO, we generally avoid using "convenience methods" to read from remote resources. It seems that these methods only work in case of an β€œaccident” when accessing remote resources. So, I totally agree with @Wayne Hartman;)

+3
source

Let me start by saying that dataWithContentsOfURL:options:error: and its ilk are probably the worst APIs for getting something from the network. They are very attractive to developers because they can get a resource from the network in one line of code, but they have some very detrimental side effects:

First, they block the thread that they are invoking. This means that if you execute this in the main thread (the only thread on which your user interface can be updated), your application will be frozen for the user. This is really a big no from the point of view of users.

Secondly, you cannot cancel these requests, therefore, even if you put this request in the background thread, it will continue to load, even if the data can be more useful. For example, if your user comes to the viewing controller, and you execute this request, and subsequently the user decides to click the "Back" button, this data will continue to be downloaded, although this is no longer relevant.

Bottom line: DON'T USE THESE API API .

Use an asynchronous network, such as NSURLConnection or AFNetworking . These classes were designed to collect data efficiently and in a way that does not interfere with user experience. What's even better is that they handle the specific use case that you originally asked: how do I stop caching on disk? .

+6
source

Source: https://habr.com/ru/post/1493174/


All Articles