iphone - Should I use NSOperationQueue and NSOperation instead of NSThread?

Question

I am facing a design problem of my app.

---

Basically, the followings are what I am going to do in my app.

A single task is like this:

1. Read custom object from the underlying CoreData databse
2. Download a json from a url
3. Parse the json to update the custom object or create a new one (parsing may take 1 - 3 secs, big data)
4. Analyse the custom object (some calculations will be involved, may take 1 - 5 sec)
5. Save the custom object into CoreData database.

There may be a number of tasks being executed concurrently.

The steps within one task obviously are ordered (i.e., without step 2 downloading the json, step 3 cannot continue), but they also can be discrete. I mean, for example, task2's step 4 can be executed before task1's step 3 (if maybe task2's downloading is faster than task1's)

Tasks have priorities. User can start a task with higher priority so all the task's steps will be tried to be executed before all others.

---

I hope the UI can be responsive as much as possible.

So I was going to creating a NSThread with lowest priority.

I put a custom priority event queue in that thread. Every step of a task becomes an event (work unit). So, for example, step 1 downloading a json becomes an event. After downloading, the event generates another event for step 3 and be put into the queue. every event has its own priority set.

---

Now I see this article: Concurrency and Application Design. Apple suggests that we Move Away from Threads and use GCD or NSOperation.

I find that NSOperation match my draft design very much. But I have following questions:

• In consideration of iPhone/iPad cpu cores, should I just use one NSOperationQueue or create multiple ones?
• Will the NSOperationQueue or NSOperation be executed with lowest thread priority? Will the execution affect the UI response (I care because the steps involve computations)?
• Can I generate a NSOpeartion from another one and put it to the queue? I don't see a queue property in NSOperation, how do I know the queue?
• How do I cooperate NSOperationQueue with CoreData? Each time I access the CoreData, should I create a new context? Will that be expensive?
• Each step of a task become a NSOperation, is this design correct?

Thanks

Answer 1

In consideration of iPhone/iPad cpu cores, should I just use one NSOperationQueue or create multiple ones?

Two (CPU, Network+I/O) or Three (CPU, Network, I/O) serial queues should work well for most cases, to keep the app responsive and your programs streaming work by what they are bound to. Of course, you may find another combination/formula works for your particular distribution of work.

Will the NSOperationQueue or NSOperation be executed with lowest thread priority? Will the execution affect the UI response (I care because the steps involve computations)?

Not by default. see -[NSOperation setThreadPriority:] if you want to reduce the priority.

Can I generate a NSOpeartion from another one and put it to the queue? I don't see a queue property in NSOperation, how do I know the queue?

Sure. If you use the serial approach I outlined, locating the correct queue is easy enough -- or you could use an ivar.

How do I cooperate NSOperationQueue with CoreData? Each time I access the CoreData, should I create a new context? Will that be expensive?

(no comment)

Each step of a task become a NSOperation, is this design correct?

Yes - dividing your queues to the resource it is bound to is a good idea.

Answer 2

• By the looks, NSOperationQueue is what you're after. You can set the number of concurrent operations to be run at the same time. If using multiple NSOperation, they will all run at the same time ... unless you handle a queue on your own, which will be the same as using NSOperationQueue

• Thread priority ... I'm not sure what you mean, but in iOS, the UI drawing, events and user interaction are all run on the main thread. If you are running things on the background thread, the interface will still be responsive, no matter how complicated or cpu-heavy operations you are running

• Generating and handling of operations you should do it on the main thread, as it won't take any time, you just run them in a background thread so that your main thread doesn't get locked

• CoreData, I haven't worked much with it specifically, but so far every Core~ I've worked with it works perfectly on background threads, so it shouldn't be a problem

• As far as design goes, it's just a point of view ... As for me, I would've gone with having one NSOperation per task, and have it handle all the steps. Maybe write callbacks whenever a step is finished if you want to give some feedback or continue with another download or something

Answer 3

The affection of computation when multithreading is not going to be different just because you are using NSThread instead of NSOperation. However keep in mind that must current iOS devices are using dual core processors.

Some of the questions you have are not very specific. You may or may not want to use multiple NSOperationQueue. It all depends on how you want to approach it. if you have different NSOperation subclasses, or different NSBlockOperations, you can manage order of execution by using priorities, or you might want to have different queues for different types of operations (especially when working with serial queues). I personally prefer to use 1 operation queue when dealing with the same type of operation, and have a different operation queue when the operations are not related/dependable. This gives me the flexibility to cancel and stop the operations within a queue based on something happening (network dropping, app going to the background).

I have never found a good reason to add an operation based on something happening during the execution of a current operation. Should you need to do so, you can use NSOperationQueue's class method, currentQueue, which will give you the operation queue in which the current operation is operating.

If you are doing core data work using NSOperation, i would recommend to create a context for each particular operation. Make sure to initialize the context inside the main method, since this is where you are on the right thread of the NSOperation background execution.

You do not necessarily need to have one NSOperation object for each task. You can download the data and parse it inside the NSOperation. You can also do the data download abstractly and do the data manipulation of the content downloaded using the completion block property of NSOperation. This will allow you to use the same object to get the data, but have different data manipulation.

My recommendation would be to read the documentation for NSOperation, NSBlockOperation and NSOperationQueue. Check your current design to see how you can adapt these classes with your current project. I strongly suggest you to go the route of the NSOperation family instead of the NSThread family.

Good luck.

Answer 4

Just to add to @justin's answer

How do I cooperate NSOperationQueue with CoreData? Each time I access the CoreData, should I create a new context? Will that be expensive?

You should be really careful when using NSOperation with Core Data.
What you always have to remember here is that if you want to run CoreData operations on a separate thread you have to create a new NSManagedObjectContext for that thread, and share the main's Managed Object Context persistant store coordinator (the "main" MOC is the one in the app delegate).

Also, it's very important that the new Managed Object Context for that thread is create from that thread. So if you plan to use Core Data with NSOperation make sure you initialize the new MOC in NSOperation's main method instead of init.

Here's a really good article about Core Data and threading

Answer 5

Use GCD - its a much better framework than NS*

Keep all your CoreData access on one queue and dispatch_async at the end of your routines to save back to your CoreData database.

If you have a developer account, check this WWDC video out: https://developer.apple.com/videos/wwdc/2012/?id=712