NSOperationQueue gets complete notification before completing tasks

Question

I am using NSOperation subclass in my app which will do following 4 tasks in a single operation, i wanted all these 4 tasks to run on background thread so I wrapped up into single NSOperation class, so that I can easily either pause or cancel it

Tasks

long time running calculation
fetching data from core data
Updating to server
Updating coredata

here each has to execute synchronously which means each one is depend on another one except long time running calculation.

Code

// MyOperation.h
@interface MyOperation : NSOperation {
}
@property (nonatomic, getter = isCancelled) BOOL cancelled;
@end

// MyOperation.m
@implementation MyOperation

- (void)cancel
{
   @synchronized (self)
   {
     if (!self.cancelled)
     {
        [self willChangeValueForKey:@"isCancelled"];
        self.cancelled = YES;
        [webServiceOperation cancel]
        [self didChangeValueForKey:@"isCancelled"];
     }
   }
}

- (void)main {
   if ([self isCancelled]) {
    NSLog(@"** operation cancelled **");
    return;
   }    
   @autoreleasepool{
    [self performTasks];
   }
}
- (void)performTasks {

    [self calculate:^{

          if (self.isCancelled)
              return;

          [self fetchDataFromCoredata:^{

                if (self.isCancelled)
                    return;

                //I am using AFNetWorking for updateWebService task so it shall run on separate NSOperation so it would be like nested NSOPeration

                webServiceOperation = [self updateWebService:^{

                                            if (self.isCancelled)
                                            return;

                                            [self updateCoreData:^{

                                                  if (self.isCancelled)
                                                        return;
                                            }];
             }];
        }];


    }];

}
@end

I am assuming that I am not following proper approach because when I tested this code using KVO the NSOperationQueuegets complete notification before it reaches calculate's completion block.

Questions

Is my approach right?
If not, can you some please guide me the right approach?
If it is right approach then why does NSOPerationQueue get complete notification before completion block execution?

Thanks in advance! looking forward your response

You're handling cancellation as if this was asynchronous operation, but havent implemented `isAsychronous`, nor doing any of the `isExecuting` or `isFinished` KVO. — Rob, Jan 26 '15 at 08:06
@Rob The question is: why do you use operations? *AFNeworking* already provides them under the hood. — Lorenzo B, Jan 26 '15 at 08:27
@flexaddicted Why operations? To nicely encapsulate complex logic within stand-alone object. To control degree of concurrency. To manage dependencies. Etc. There are lots of reasons to use `NSOperation` objects and I'm not going to begrudge anyone who wants to understand this incredibly useful pattern. Re AFNetworking, while it is not without its own flaws, you're right that it is it is strong, and should be considered. FYI, it only provides operation pattern within the `NSURLConnection`-based `AFHTTPRequestOperationManager`, but not within the `NSURLSession`-based `AFHTTPSessionManager`. — Rob, Jan 26 '15 at 11:54
@Rob My question was concerning about abstraction. In other words, *AFNetworking* provides a nice level of abstraction. So, IMO, there is no need to wrap it within `NSOperation`s. Anyway, yes. If the OP wants to learn about pros about using operations, I agree your comment. — Lorenzo B, Jan 26 '15 at 12:34
@flexaddicted Agreed. Sorry, I missed your point. Yes, of course, one shouldn't reinvent the wheel. AFNetworking is a good place to start. And the OP can also look at the source for `AFURLConnectionOperation` for an example of what a proper `NSOperation` subclass implementation looks like (though, admittedly, a complex one). — Rob, Jan 29 '15 at 13:22

score 1 · Accepted Answer · answered Jan 26 '15 at 07:52

1

Only actually the web call needs to be explicitly asynchronous as your operation will already run on a background thread. So you can simplify the block structure in your code so there isn't so much nesting.

Then you need to properly construct your operation subclass to handle asynchronous content, as described here.

answered Jan 26 '15 at 07:52

Wain

118,658
15
128
151

3

FYI, that link is a little dated nowadays you set `isAsynchronous`, not `isConcurrent`. He also doesn't handle the cancellation of a request in progress. But it's a decent, if dated, primer on the topic. I'd also refer OP to subclassing notes in NSOperation Reference as well as the operation queues chapter of the concurrency programming guide. – Rob Jan 26 '15 at 08:01

score 0 · Answer 2 · edited May 23 '17 at 11:57

0

If you want to use NSOperation just follow "Wain's" answer you need process task sequentially.

You can still go with your nested block structure using GCD and avoiding use NSOperation.

NSOperation vs Grand Central Dispatch

edited May 23 '17 at 11:57

Community

1
1

answered Jan 26 '15 at 08:09

Girish Kolari

2,515
2
24
34

1

"Block with NSOperation is not a good option." Not true. It's a perfectly acceptable pattern. Sure, sometimes GCD approach is adequate, but I other cases, operation queue approach is much better. It depends upon considerations beyond the scope of this question. – Rob Jan 26 '15 at 12:39

score 0 · Answer 3 · answered Jan 26 '15 at 08:19

The performTasks method doesn't actually perform any tasks. It dispatches tasks to queues or calls methods that dispatch tasks to queues. When the dispatching is done, performTasks is finished and your NSOperationQueue will treat it as finished, even though the task is still executing.

I don't think there's much reason to use NSOperation here. Just use GCD.

NSOperationQueue gets complete notification before completing tasks

3 Answers3