Calling -(void) cancelAllOperations on NSoperationQueue is not setting the isCancelled property of NSOperation that is present inside the Queue

Question

I am facing problem related to NSoperationQueue. In my code in :

-(void) viewDidLoad
{
    //Initialisation of queue and operation.
    //adding operation to queue
    [self.operationQueue addOperation:op];

}

 -(void) viewWillDisappear:(BOOL)animated 
{
   [super viewWillDisappear:animated];
   [self.operationQueue cancelAllOperations];
}

So during execution of my NSOperation main function when i am checking for isCancelled property it always returns NO. Infact after calling cancellAllOperation on NSOperationQueue. eg.

-(void)main
{
   if(self.isCancelled)
   {
    // Never executing this block :-(
   }

 }

For more details i am doing some network calls in my NSOperation.And when i switched to other view by then cancelAllOperation is called up. And when network response came back to in my NSOperation i am checking if(Self.isCancelled) and now i am in another view(means isCancelled should set YES). but this check always fails.

Answer 1

Your operation is added to the queue just after loading the view in viewDidLoad, and the queue will then assume responsibility to start the operation.

Since you cancel your operation(s) when the view disappears (viewWillDisappear), the operation should most likely be finished at this time. In other words, your operation is cancelled after being terminated. You could check the isExecuting property to know whether the operation is actively working.

Answer 2

Your operation is probably no longer running, and so won't be cancelled. (Once your operation has finished, the operation queue will no longer keep track of it, so calling cancelAllOperations won't do anything.)

If the network response you're waiting for is calling a callback rather than blocking the call to main, your operation will already have finished (when main returns). You could fix this by using a "concurrent" operation (see the NSOperation docs; you can indicate when you're done, rather than just automatically being done when main returns) or by using synchronous networking calls (so main doesn't return until you're really done).