0

I am doing a lot of GCD and asynchronous rendering and data retrieval work lately and I really need to nail the mental model about how asynchronous is done.

I want to focus on setNeedsDisplay and the NSURLConnectionDelegate suite of methods.

  1. Is it correct to call setNeedsDisplay asynchronous? I often call it via dispatch_async(dispatch_get_main_queue(), ^{}) which confuses me.
  2. The NSURLConnectionDelegate callbacks are described as asynchronous but are they not actually concurrently run on the main thread/runloop. I am a but fuzzy on the distinction here.

More generally in the modern iOS era of GCD what is the best practice for making GCD and these methods play nice together. I'm just looking for general guidelines here since I use them regularly and am just trying not to get myself in trouble.

Cheers,
Doug

dugla
  • 12,774
  • 26
  • 88
  • 136
  • You might want to consider [rephrasing the question](http://stackoverflow.com/faq#dontask) with specific examples of a practical problems that you're wrestling with, if possible, rather than conceptual questions. I think if you make it a little more concrete (e.g. a question about a particular code sample), it is more productive. – Rob Jan 10 '13 at 14:17
  • Well, the issue is/was in fact conceptual. Yes, I know that seems to be a red flag around here but I thought I'd give it a shot. Conceptual needn't be a dirty word especially for complex concepts like GCD, runloops, etc. – dugla Jan 10 '13 at 17:45

1 Answers1

0

  1. No, you generally don't call setNeedsDisplay asynchronously. But if you're invoking this from a queue other than the main queue (which I would guess you are), then you should note that you never should do UI updates from background queues. You always run those from the main queue. So, this looks like the very typical pattern of dispatching a UI update from a background queue to the main queue.

  2. NSURLConnection is described as asynchronous because when you invoke it, unless you used sendSynchronousRequest, your app immediately returns while the connection progresses. The fact that the delegate events are on the main queue is not incompatible with the notion that the connection, itself, is asynchronous. Personally, I would have thought it bad form if I can some delegate methods that were not being called from the same queue from which the process was initiated, unless that was fairly explicit via the interface.

  3. To the question of your question's title, whether NSURLConnection uses GCD internally, versus another concurrency technology (NSOperationQueue, threads, etc.), that's an internal implementation issue that we, as application developers, don't generally worry about.

  4. To your final, follow-up question regarding guidelines, I'd volunteer the general rule I alluded to above. Namely, all time consuming processes that would block your user interface should be dispatched to background queue, but any subsequent UI updates required by the background queue should be dispatched back to the main queue. That's the most general rule of thumb I can think of that encapsulates why we generally do concurrent programming and how to do so properly.

Rob
  • 415,655
  • 72
  • 787
  • 1,044
  • Rob - regarding NSURLConnection. Delegate callbacks run on the thread/queue from which it was launched (typically main queue). In the case where returned data requires subsequent long running processing will that processing hang the UI or does the framework somehow interleave the processing to allow the UI to remain responsive? – dugla Jan 10 '13 at 14:36
  • @dugla If you're doing something extremely time consuming in your delegate methods, then, yes, you'd probably dispatch those to your own background queue if you want to keep the UI responsive. The framework won't do that for you. Generally, though, the processing we do in the delegate methods is negligible in comparison to the time spent interacting with some remote server, especially since we're processing data as received by `didReceiveData` in smallish packets, so often you don't have to worry about it. It depends upon what you're doing as the data is received. – Rob Jan 10 '13 at 14:43