0

My app includes a back-end server, with many transactions which must be carried out in the background. Many of these transactions require many synchronous bits of code to run.

For example, do a query, use the result to do another query, create a new back-end object, then return a reference to the new object to a view controller object in the foreground so that the UI can be updated.

A more specific scenario would be to carry out a sequence of AJAX calls in order, similar to this question, but in iOS.

This sequence of tasks is really one unified piece of work. I did not find existing facilities in iOS that allowed me to cleanly code this sequence as a "unit of work". Likewise I did not see a way to provide a consistent context for the "unit of work" that would be available across the sequence of async tasks.

Community
  • 1
  • 1
LostInTheTrees
  • 1,135
  • 9
  • 19
  • It might help you to read the section of my book where I perform the same task using NSOperation and then rewrite to use GCD instead. This might give you some idea of how they weigh off against each other. http://www.apeth.com/iOSBook/ch38.html#_three_ways_of_threading – matt Apr 26 '13 at 00:48
  • Thank you Robert Harvey and Josh. I did not know you could edit my question, but I have no objection to what you did. I am glad future "me"s will be able to find this. I realize I should have paid more attention to the title. I did not think it had that much importance. – LostInTheTrees Apr 30 '13 at 22:45
  • 3
    There's absolutely nothing wrong in general with self-answered questions. There's even a section of the "Ask Question" page that allows you to provide your answer immediately. Posting a question on SO to which you've already found the answer is completely acceptable and encouraged. See [Can I answer my own questions, even those where I knew the answer before asking?](http://meta.stackexchange.com/q/17463) – jscs May 01 '13 at 03:23

2 Answers2

2

I recently had to do some JavaScript and had to learn to use the Promise concept that is common in JS. I realized that I could adapt this idea to iOS and objective-C. The results are here on Github. There is documentation, code and unit tests.

A Promise should be thought of as a promise to return a result object (id) or an error object (NSError) to a block at a future time. A Promise object is created to represent the asynchronous result. The asynchronous code delivers the result to the Promise and then the Promise schedules and runs a block to handle the result or error.

If you are familiar with Promises on JS, you will recognize the iOS version immediately. If not, check out the Readme and the Reference.

LostInTheTrees
  • 1,135
  • 9
  • 19
2

I've used most of the usual suspects, and I have to say that for me, Grand Central Dispatch is the way to go.

Apple obviously care enough about it to re-write a lot of their library code to use completion blocks.

IIRC, Apple have also said that GCD is the preferred implementation for multitasking.

I also remember that some of the previous options have been re-implemented using GCD under the hood, so you're not already attached to something else, Go GCD!

BTW, I used to find writing the block signatures a real pain, but if you just hit return when the placeholder is selected, it does all that for you. What could be sweeter than that.

Gordon Dove
  • 2,537
  • 1
  • 22
  • 23
  • Under the hood, Promises use GCD and blocks. What it provides for you is an easier way to write code that flows naturally on the page, but still uses asynchrony extensively. The ability to propagate errors though a an async sequence is also more valuable than it might seem at first. – LostInTheTrees Apr 26 '13 at 00:59
  • I believe using GCD by itself, a sequence of 3 consecutive async tasks requires nesting blocks 3 deep or some other contortions. If I'm wrong about that I'm happy to be educated. WIth Promises no nesting is required. – LostInTheTrees Apr 26 '13 at 01:07
  • @GordonDove - I wouldn't go so far as to suggest that GCD is preferred over operation queues. (For example, WWDC 2012 discussion of concurrent UI used operation queues, not GCD; `sendAsynchronousRequest` of `NSURLConnection` uses operation queues, not dispatch queues. etc.) Both GCD and operation queues have their own relative strength and weaknesses and both are prevalent (and if you're only familiar with one, you should look at the other). The nice thing is, that in their simplest forms, both are absurdly easy (`dispatch_async` to GCD queue or `addOperationWithBlock` to `NSOperationQueue`). – Rob Apr 26 '13 at 03:09
  • @Rob, the simple cases ARE easy. I have to do multiple networking transactions (parse.com actually) in the background. Then return to the main thread. I found the existing facilities hard to use that way. Rob, and GordonDove, each of you appears to be knowledgable in this area. I was hoping for comments on what I presented on GitHub from just your sort of person. None of the comments so far indicate that anyone has clicked through and looked. – LostInTheTrees Apr 26 '13 at 16:32
  • @Rob - I am not sure why you think I am abandoning conventional patterns. Promises simply provide additional structure for using GCD and blocks. I hope you'll reconsider that -1 you dropped on me. I think your answer below is valuable even if you don't think Promises are the best answer. I'm a sample size of 1, but I would have been thrilled to find this when I really needed it. – LostInTheTrees Apr 26 '13 at 21:34
  • @Rob - I don't understand why your answer has been deleted. It would have been useful to many. It just seems wasteful to have deleted it. – LostInTheTrees Apr 29 '13 at 00:15