Okay, so as I understand it, you have two questions:
-
Do you need the
performSelectorOnMainThread:
segment that appears in comments in your code? What does that code do? -
Why is the
_isCancelled
flag is not modified when you callcancelAllOperations
on theNSOperationQueue
that contains this operation?
Let’s deal with these in order. I’m going to assume that your subclass of NSOperation
is called MyOperation
, just for ease of explanation. I’ll explain what you’re misunderstanding and then give a corrected example.
1. Running NSOperations concurrently
Most of the time, you’ll use NSOperation
s with an NSOperationQueue
, and from your code, it sounds like that’s what you’re doing. In that case, your MyOperation
will always be run on a background thread, regardless of what the -(BOOL)isConcurrent
method returns, since NSOperationQueue
s are explicitly designed to run operations in the background.
As such, you generally do not need to override the -[NSOperation start]
method, since by default it simply invokes the -main
method. That is the method you should be overriding. The default -start
method already handles setting isExecuting
and isFinished
for you at the appropriate times.
So if you want an NSOperation
to run in the background, simply override the -main
method and put it on an NSOperationQueue
.
The performSelectorOnMainThread:
in your code would cause every instance of MyOperation
to always perform its task on the main thread. Since only one piece of code can be running on a thread at a time, this means that no other MyOperation
s could be running. The whole purpose of NSOperation
and NSOperationQueue
is to do something in the background.
The only time you want to force things onto the main thread is when you’re updating the user interface. If you need to update the UI when your MyOperation
finishes, that is when you should use performSelectorOnMainThread:
. I’ll show how to do that in my example below.
2. Cancelling an NSOperation
-[NSOperationQueue cancelAllOperations]
calls the -[NSOperation cancel]
method, which causes subsequent calls to -[NSOperation isCancelled]
to return YES
. However, you have done two things to make this ineffective.
-
You are using
@synthesize isCancelled
to override NSOperation’s-isCancelled
method. There is no reason to do this.NSOperation
already implements-isCancelled
in a perfectly acceptable manner. -
You are checking your own
_isCancelled
instance variable to determine whether the operation has been cancelled.NSOperation
guarantees that[self isCancelled]
will returnYES
if the operation has been cancelled. It does not guarantee that your custom setter method will be called, nor that your own instance variable is up to date. You should be checking[self isCancelled]
What you should be doing
The header:
// MyOperation.h
@interface MyOperation : NSOperation {
}
@end
And the implementation:
// MyOperation.m
@implementation MyOperation
- (void)main {
if ([self isCancelled]) {
NSLog(@"** operation cancelled **");
}
// Do some work here
NSLog(@"Working... working....")
if ([self isCancelled]) {
NSLog(@"** operation cancelled **");
}
// Do any clean-up work here...
// If you need to update some UI when the operation is complete, do this:
[self performSelectorOnMainThread:@selector(updateButton) withObject:nil waitUntilDone:NO];
NSLog(@"Operation finished");
}
- (void)updateButton {
// Update the button here
}
@end
Note that you do not need to do anything with isExecuting
, isCancelled
, or isFinished
. Those are all handled automatically for you. Simply override the -main
method. It’s that easy.
(A note: technically, this is not a “concurrent” NSOperation
, in the sense that -[MyOperation isConcurrent]
would return NO
as implemented above. However, it will be run on a background thread. The isConcurrent
method really should be named -willCreateOwnThread
, as that is a more accurate description of the method’s intention.)