Yesterday I had a drunken rant of a post describing how much I detest blocks, this morning I sobered up and started to research another method for multithreading. Surely there has got to be one, right? Good thing is there IS a way to multithread your application without using blocks, each with their own advantages and disadvantages. Glancing at a fantastic book iOS Components and Frameworks gave a really solid review. Lets list them:
1 the Selector:
The selector gives us an opportunity to run code and bounce back between threads.
Pros: very easy on the eyes, intuitive
Cons: completion of tasks are unpredictable, chaotic, and out of order
Pretty much whatever data you put into the thread can come back out of order. If merely updating your interface is important without regard to FIFO, this should suffice. Generally, we want an order so we can try again with a different method
NSOperationQueue is a bit more involved, and it requires blocks, but smaller more manageable ones. We can begin by creating a property NSOperationQueue
alloc, init like we are supposed to in viewDidLoad
then use viewDidAppear for declaring the selector, and instantiate your invocationOperation using the selector you just created as a parameter and pass a nice NSLog message:
Pros: Keeps thread returns coming back in order
Cons: more code, selectors and BLOCKS (??)
Ironically block syntax is starting to grow on me after I try to find methods that avoid them. And the methods that are supposed to avoid them still use them.
There is one more which I’d like to share, dispatch_async(someVar, ^{/*block syntax*/});
These are blocks, I know. It looks like old-school C and upon reflection it is probably what scared me away from actually enjoying them.
Pros: Allows more flexibility and customization
Cons: Not beginner-friendly.
This blogger will try and research block syntax (especially dispatch_async) over the next few days. Wish me luck
**also- do yourself a favor and buy iOS Components and Frameworks. Lots of fun for developers of all ages



