What is the difference between executing NSURLRequest and delegate responses, as opposed to using dispatch_async?

Question

I try to bow my head to asynchrony; sending, multiple threads, starting loops, etc. etc.

What's the difference between:

1) by creating NSURLRequest and NSURLConnection in this method and executing it, we respond to the delegate methods (didReceiveResponse, didReceiveData, connectionDidFinishLoading, etc.) and

2) creating a block and sending it async?

With the first method, it seems wonderful that I have access to delegate methods (do I still have access to those who use the dispatcher?), And the delegate methods are executed at startup (or next to it?)

Using the block / dispatch method, I assume that the block is being processed synchronously inside it? And then returns to the main thread to process the results? Example code that I was looking at:

dispatch_async(kBgQueue, ^{ NSData* data = [NSData dataWithContentsOfURL: kLatestKivaLoansURL]; [self performSelectorOnMainThread:@selector(fetchedData:) withObject:data waitUntilDone:YES]; }); 

So, does "self performSelector ...." AFTER receiving the data? (which I meant earlier synchronously - perhaps the wrong term). And the next line of the block returns us to the main thread.

What is the purpose or why does "waitUntilDone: YES" exist? Is it because if it is not, other things can happen NOT in the main thread?

Is the first method above that is still only running in the main thread?

and finally, what are the pros and cons of each in the case of a JSON request to a web page? Is there any big advantage of one method over another?

Answer 1

1) When you use NSURLConnection, either in your main thread or in NSOperation, you have full control over stopping it at any time and monitoring its progress. What you get back is the delegate methods when different things happen, but you are not sitting and waiting for the completion of something. If you want to stop it at any time, you send it to cancel, then you can release (or nil) it and forget about it.

2) So, look at that. If you made this call in the main thread, it will wait until it succeeds or works. After starting it should work until success or failure. This blocks your user interface if in the main thread. Put it in a block and run it on another thread, and the same thing will happen - the selected thread will be blocked until the method finishes. The use of "I" to send the result will be saved. So if I say UIViewController, then even if you hit (thinking that it will be deleted), it stays around until this method completes, doing something the sky knows. This use is very dangerous and can work often, but catastrophically catastrophically when the device has a crappy inet connection (for example).

Wait until the threads synchronize. If you want to know that the method was run in the main thread, and only then continue, use YES. If you just want the method to be queued and you are finished (as in this case), you simply use NO.

This method will probably be on the main thread - this is Apple promises with this method.

3) JSON

Most of the users I know use NSURLConnections from NSOperations or blocks. Operations can be canceled (which will cancel the connection), so you can handle the back button, no matter how much it happens. If the request failed, you can see the html status (did you get a 400 or 500 error? Timeout? Etc.)

There is an open source project on github, just over 200 lines of code that provide an elegant and easy-to-use helper class to run operations (with demo code): / NSOperation-WebFetches-MadeEasy . I personally used this code in more than 8 applications that are still stored in the store, with great success - one OperationsRunner often has hundreds of statements at a time, and the application has several classes that OperationsRunners runs at the same time.

If you handle JSON in NSOperation, you will get real accelerations on devices with multiple cores.