Is it right if I cancel an NSInvocationOperation inside the operation?
example:
.h file:
//defined in the interface
NSInvocationOperation *op1;
NSOperationQueue *loadQueue;
.m file:
-(id)init{
op1 = [NSInvocationOperation new];
loadQueue = [NSOperationQueue new];
}
-(void)downloadData{
op1 = [[NSInvocationOperation alloc] initWithTarget:self selector:#selector(loadServerResponse:) object:newerRequest];
[loadQueue addOperation:op1];
}
Now I have a method to download data from the server. I added a condition to check if there is an error. If so I'm cancelling that operation inside the method and calling back the same method upon retrieving the new login token.
- (void)loadServerResponse{
if(server_error){
[op1 cancel];
//fetch login token again
[self downloadData];
return;
}
Am I doing anything wrong?
First, referencing op1 (which I'm assuming is a class-level ivar) is a Bad Thing™ on multiple levels, the first of which is NSOperationQueue dispatches your operation onto a background thread, so op1 will (at best) be copied into that thread's context and no longer reference the original operation you were attempting to cancel.
I think you don't need to worry about canceling the operation, given the logic you have shared. You specifically seem to want to call downloadData after canceling, and there's no guarantee that will happen if you cancel the operation first. I would just remove the call to cancel the operation, and continue on. Normally you only cancel a running operation from an external source (say if you receive a notification that your application will enter background state).
Related
I am building a simple messaging app using Parse's framework. I have a method called displayMessages. This is called each time the phone receives a push.
However, as this message is doing work in the Parse database I don't want to call it again if it's already running. I want to wait until it is finished and then call it.
I am using the following code:
-(void)receivedPush
{
[self displayMessages];
}
and:
-(void)displayMessages
{
//code here
}
If received push is called I want it to wait until displayMessages is finished before calling it. Could someone please point me in the right direction with this?
UPDATE
I tried using the NSOperationQueue method and realised that although this does work for waiting for displayMessages it doesn't result in the required behavior.
In displayMessages I have: [PFObject deleteAllInBackground:toDelete]; it's actually this I need to wait for completion before calling displayMessages again.
Create a NSOperationQueue and set the maxConcurrentOperationCount to 1. Implement your data access method as an operation (possibly block-type operation) and submit it to the queue. (I like this better than gcd since you can do cancellation or test the number of items already in the queue.)
Note that if the method actually displays things, you'll need to dispatch back to the main queue for UI work.
You could use a NSOperationQueue with maxConcurrentOperationCount set to 1.
Declare the NSOperationQueue as an iVar of your class, initialize it in the init method and set
[_opQueue setMaxConcurrentOperationCount:1];
and then when you receive the push:
- (void)receivedPush {
NSInvocationOperation *op = [[NSInvocationOperation alloc] initWithTarget:self selector:#selector(displayMessages) object:nil];
[_opQueue addOperation:op];
}
Shortest and simples would be creating BOOL isExecuting and checking if you can call method based on that (changing values before execution but after check and after execution)
How about this for a fairly lightweight solution:
#property (nonatomic, assign) BOOL needsToDisplayMessages;
#property (nonatomic, assign) BOOL displayingMessages;
Then
-(void)receivedPush
{
if (!self.displayingMessages) {
[self displayMessages];
} else {
self.needsToDisplayMessages = YES;
}
}
-(void)displayMessages
{
self.needsToDisplayMessages = NO;
self.displayingMessages = YES;
//long-running code here
self.displayingMessages = NO;
if (self.needsToDisplayMessages) {
[self displayMessages]
}
(ignoring concurrency issues ... for which you could use GCD in displayMessages or NSOperationQueue as per a couple of the other answers)
With your new updated requirement, you can use deleteAllInBackground:block:. According to document:
"Deletes a collection of objects all at once asynchronously and executes the block when done."
Why not schedule each message handling using:
-(void)receivedPush
{
dispatch_async(dispatch_get_main_queue(), ^{
/* Show the update on the display */
NSLog(#"Handling new messages");
NSArray *newMessages=<populate with new messages>;
[handler displayMessages:newMessages];
});
}
This will queue up your handling of each set as they come in. Only one displayMessages will run at a time.
Basically, I would like to perform a cancel if the operation I'm adding to the queue does not respond after a certain timeout :
NSOperationQueue * queue = ...
[self.queue addOperationWithBlock:^{
// my block...
} timeoutInSeconds:5.0 hasTimedOutWithBlock:^{
// called after 5.0, operation should be canceled at the end
}];
Thanks Guys !
You could do something like you asked for, but I might suggest adding a parameter to the first block by which the first block could check to see if the operation was canceled.
[queue addOperationWithBlock:^(NSOperation *operation) {
// do something slow and synchronous here,
// if this consists of a loop, check (and act upon) `[operation isCancelled]` periodically
} timeout:5.0 timeoutBlock:^{
// what else to do when the timeout occurred
}];
Maybe you don't need to check isCancelled, but in some cases you would (generally the burden for responding to a cancellation rests on the operation itself), so that's probably a prudent parameter to add.
Anyway, if that's what you wanted, you might do something like the following:
#implementation NSOperationQueue (Timeout)
- (NSOperation *)addOperationWithBlock:(void (^)(NSOperation *operation))block timeout:(CGFloat)timeout timeoutBlock:(void (^)(void))timeoutBlock
{
NSBlockOperation *blockOperation = [[NSBlockOperation alloc] init]; // create operation
NSBlockOperation __weak *weakOperation = blockOperation; // prevent strong reference cycle
// add call to caller's provided block, passing it a reference to this `operation`
// so the caller can check to see if the operation was canceled (i.e. if it timed out)
[blockOperation addExecutionBlock:^{
block(weakOperation);
}];
// add the operation to this queue
[self addOperation:blockOperation];
// if unfinished after `timeout`, cancel it and call `timeoutBlock`
dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(timeout * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
// if still in existence, and unfinished, then cancel it and call `timeoutBlock`
if (weakOperation && ![weakOperation isFinished]) {
[weakOperation cancel];
if (timeoutBlock) {
timeoutBlock();
}
}
});
return blockOperation;
}
#end
Having provided that code sample, I must confess that there are a very narrow set of situations where something like the above might be useful. Generally it would be better addressed using another pattern. The vast majority of the time, when you want a cancelable operation, you would implement a NSOperation subclass (often a concurrent NSOperation subclass). See the Defining a Custom Operation Object section of the Operation Queues chapter of the Concurrency Programming Guide for more information.
I have troubles with multiple threads. Here is the situation:
I make asynchronous requests to backend and, in some cases, need to cancel these. Canceling the requests happens in a separate thread. All requests to the backend are canceled and, as I exit a screen, multiple class instances are deallocated.
When I have the order request-cancel, everything works fine. However, sometimes the cancel method is invoked when I am already in the middle of the finish method (which needs a little bit time because of decoding and conversion of data). In such cases, the app crashes, a messages to deallocated instance is sent. It is not an exception that can be easily cached, I get the crash even when I check for the existence of the instances a line before. Actually, if I understand it right, the instance of the class where the finish and the cancel method are located, is deallocated. Nevermind, the problem is that the thread is switched in the middle of the finish method and I need to prevent that.
My question is: Is there a way to block switching the thread in the middle of a method? To declare this method as a whole (transaction)? Or is there another standard solution for such a problem?
I read this post but I don't really understand whether it can be used in my case or how to do that.
EDIT: Canceling
for (XXX *request in [XXX sharedQueue].operations)
{
[request setDelegate:nil];
[request setDownloadProgressDelegate:nil];
[request setUploadProgressDelegate:nil];
[request setQueue:nil];
[request cancel];
}
XXX is the class used for the requests.
Order of the methods
Here is the order in which the methods are invoked (in the cases of error). Handler is the class for handling the requests.
Handler 1: make request
Handler 1: finish begin
Handler 2: cancel begin
Handler 2: cancel end
Handler 2: dealloc
Handler 1: dealloc
Handler 1: finish middle
Handler 1 and 2 are two instances of the class. The first one is deallocated in the middle of the finish method, so at the end of this I get a crash. Deallocating it is normal because after cancel I go to another view and basically everything gets deallocated.
My ideas for solution are either to somehow prevent going back to the finish method or to execute the entire finish method before switching the thread. Unfortunately, I have no idea how one of these could be implemented.
The following approach might help you:
add a flag to your controller managing all requests;
when a request finish block is entered do like this:
completionBlock:^() {
#synchronized(self.myFinishFlag) {
...
}
}
in your cancel method do like this:
-(void)userCancelledRequests:(id)sender {
#synchronized(self.myFinishFlag) {
...
}
}
This will delay the execution of 'userCancelledRequestsbody if a finish block is currently running (i.e., lockingself.myFinishFlag`).
Hope this helps.
It appears that the cancel method of class XXX is not correctly implemented.
Suppose there is some asynchronous operation of type XXX which responds to a cancel message. In order to function reliable, the following requirements must be fulfilled:
The cancel message can be send from a client from any thread.
The cancel message can be send at any time and multiple times.
When the operation receives the cancel message, it stops it asynchronous task and cleans up itself properly at the next "cancelation point". Note: this may happen asynchronously with respect to the cancel method. The implementation needs to be "thread safe"!
The receiver shall notify the delegate that it has been cancelled (for example in a failure handler).
Furthermore, there should be no need for a caller to reset the delegate(s) or prepare the receiver in any way before sending the cancel message.
These requirements needs to be fulfilled by the implementation of class XXX.
Now, suppose you have an internal finish method for that operation and lets suppose that this is the last method which will be executed by the operation. When that method is executed, and when the operation receives a cancel message concurrently, the implementation must guarantee that the cancel has no effect, since it is too late: the last opportunity to cancel the operation has been passed. There are a number of ways how to accomplish this.
If this is true, then the following code should properly cancel your operations:
for (XXX *request in [XXX sharedQueue].operations) {
[request cancel];
}
Edit:
Example for an "NSOperation like" implementation of a cancel and finish method:
Note:
Accessing ivars must be synchronized! Ivars will be accessed in various internal methods. All accesses will be serialized via a private serial dispatch queue, named "sync_queue".
- (void) cancel {
dispatch_async(self.sync_queue, ^{
if (_isCancelled || _isFinished) {
return;
}
[self.task cancel]; // will sets _isCancelled to YES
[self finish]; // will set _isFinished to YES
});
}
- (void) finish
{
assert(<execution context equals sync_queue>);
if (_isFinished)
return;
completionHandler_t onCompletion = self.completionHandler;
if (onCompletion) {
id result = self.result;
dispatch_async(dispatch_get_global_queue(0, 0), ^{
onCompletion(result);
});
};
self.completionHandler = nil;
self.task = nil;
self.isExecuting = NO;
self.isFinished = YES;
}
The best way to block is to perform all operations on a dedicated queue. When you want to cancel, do it like this:
dispatch_async(_someQueue, ^{
for (XXX *request in [XXX sharedQueue].operations)
{
[request setDelegate:nil];
[request setDownloadProgressDelegate:nil];
[request setUploadProgressDelegate:nil];
[request setQueue:nil];
[request cancel];
}
});
Then when the finished callback is triggered, you can do this:
dispatch_async(_someQueue, ^{
if ([request isCancelled] == NO)
{
// Process request
}
});
So long as _someQueue is not marked as a concurrent queue, this should do the trick.
From a view controller, as a result of a button action, I need to create a custom object that manages a set of asynchronous remote service calls, and call the method of such object that fires those service calls. I need the view controller to wait for all the async networking operations to have finished in order to update its view. Since the networking operations are async, I don't know how I'd communicate from the custom object managing this tasks to the view controller when all operations are done.
Here is the code I currently have. The code snippet in the view controller is like this (result var is not currently used):
- (void)loadData
{
BOOL __block result = NO;
dispatch_queue_t queue = dispatch_queue_create(dataLoadQueue, NULL);
dispatch_async(queue,^{
Loader *loader = [[Loader alloc] init];
[loader loadData];
dispatch_async(dispatch_get_main_queue(), ^{
if (result) {
// Update view and notify success
}
else {
// Update view and notify error
}
});
});
dispatch_release(queue);
}
And this is the loader custom object side:
- (void)loadData
{
if ([Reachability checkNetStatus]) {
Service1 *service1 = [[Service1 alloc] init];
[service1 callAsyncService];
Service2 *service2 = [[Service2 alloc] init];
[service2 callAsyncService];
// More service calls
}
else {
// Notify network not reachable
}
}
Objects service1, service2... serviceN conform the NSURLConnectionDelegate and I notify they have finished in its connectionDidFinishLoading: by means of the NSNotificationCenter (loader object is listening for such notifications). Then, I don´t know what is the correct way of making loader wait for all the networking operations, and notify back the view controller.
Thanks in advance
There are probably lots of ways you could do this. First, I don't think there's any need to use GCD in the view controller -- loader is already doing things asynchronously, so the creation of loader is fast.
As for how Loader knows when all its network operations are done, you could just keep a list of strings in a mutable array, like "1 done", "2 done", etc. that would be the same as strings sent in the user info of the notifications called in connectionDidFinishLoading:. All the services could send the same notification, but with different user info. In the selector for the observer, remove the string identical to the one in the user info, and check if the array is empty -- when it is, all your services are done. At that point, I would use a delegate method to pass back the data to the view controller. Something like this in Loader:
- (void)viewDidLoad {
[super viewDidLoad];
self.doneStrings = [#[#"1 done", #"2 done", #"3 done", #"4 done"] mutableCopy];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(notificationReceived:) name:#"SeriveFinishedNotification" object:nil];
}
-(void)notificationReceived:(NSNotification *) aNote {
[self.doneStrings removeObjectIdenticalTo:[aNote.userInfo objectForKey:#"doneString"]];
if (self.doneStrings.count == 0)
[delegate doSomethingWithTheData: theData];
}
You would probably need to some other things like handle the case where some of the network operations fail.
If you want to wait until the async tasks were done, you can use a semaphore. See the example below, the logic is pretty simply. I think you can easily adapt to your case.
//create the semaphore
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
[objectManager.HTTPClient deletePath:[address addressURL] parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
//some code here executed in background
dispatch_semaphore_signal(semaphore); //sends a notification to release the semaphore
}failure:^(AFHTTPRequestOperation *operation, NSError *error) {
//some other code here also executed in background
dispatch_semaphore_signal(semaphore); //sends a notification to release the semaphore
}];
//holds the thread until the dispatch_semaphore_signal(semaphore) is send
while (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW))
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:10]];
}
You haven't shared the details of how these asynchronous requests work, but another approach is to make these asynchronous requests NSOperation objects that you submit to a NSOperationQueue. (AFNetworking is an example of this sort of implementation.) When you do that, you can create yet another NSOperation to be triggered upon the completion of the network request operations, by make it dependent upon those network request operations. Thus it will only run when all of the network requests are done. Using an NSOperation-based solution enjoys other benefits, too (e.g. you can use setMaxConcurrentOperationCount to let you enjoy concurrency, but not run too many concurrent requests at any given time).
References
Ray Wenderlich's How To Use NSOperations and NSOperationQueues
Defining a Custom Operation Object in Apple's Concurrency Programming Guide
The problem is that I manage scrollView with lots of tiles in it.
Each visible tile display image loaded from URL or (after first URL load) cached file in background. Invisible tiles recycles (set new frame and redraw).
Image load depends on tile position.
With long range scroll there is multiple redraw called for each tile: each tile loads (and display) different image several times before display the correct one.
So problem is to cancel all previously added operations for tile before add new.
I subclass NSInvocationOperation just to contain context object to detect operation attached to and before add new operation I canceling all operation for same tile:
-(void)loadWithColler:(TileView *)coller {
if (queue == nil) {
queue = [NSOperationQueue new];
}
NSInvocationOperationWithContext *loadImageOp = [NSInvocationOperationWithContext alloc];
[loadImageOp initWithTarget:self selector:#selector(loadImage:) object:loadImageOp];
[loadImageOp setContext:coller];
[queue setSuspended:YES];
NSArray *opers = [queue operations];
for (NSInvocationOperationWithContext *nextOperation in opers) {
if ([nextOperation context] == coller) {
[nextOperation cancel];
}
}
[queue addOperation:loadImageOp];
[queue setSuspended:NO];
[loadImageOp release];
}
And in operation itself I check isCancelled:
-(void)loadImage:(NSInvocationOperationWithContext *)operation {
if (operation.isCancelled) return;
TileView *coller = [operation context];
/* TRY TO GET FILE FROM CACHE */
if (operation.isCancelled) return;
if (data) {
/* INIT WITH DATA IF LOADED */
} else {
/* LOAD FILE FROM URL AND CACHE IT */
}
if (operation.isCancelled) return;
NSInvocationOperation *setImageOp = [[NSInvocationOperation alloc] initWithTarget:coller selector:#selector(setImage:) object:cachedImage];
[[NSOperationQueue mainQueue] addOperation:setImageOp];
[setImageOp release];
}
But it is do nothing. Some times early returns works but tiles still load many images before the correct one.
So how could I success? And could this lots of unneeded operations cause delays on main thread when scrolling? (Because delays are exists and I do not know why...all load in background..)
Update:
With NSLog:
isCancelled while executing:
>
cancel loadImage method for:
>
So canceling work.
Now I save reference to last operation in TileView object and perform setImage operation only if invoked operation is equal to TileView operation.
Doesn't make any difference...
Looks like there IS number of operations to load different images to one tile invoked one after another.
Any another suggestions?
For clearance:
There is singleton DataLoader (all code from it). And all tiles has call to it in drowRect:
[[DataLoader sharedDataLoader] loadWithColler:self];
Update:
NSInvocationOperation subclass:
#interface NSInvocationOperationWithContext : NSInvocationOperation {
id context;
}
#property (nonatomic,retain,readwrite) id context;
#end
#implementation NSInvocationOperationWithContext
#synthesize context;
- (void)dealloc
{
[context release];
[super dealloc];
}
#end
Thanks a lot for any help!
SOLUTION:
From answer below: need to subclass from NSOperation
As I subclass NSOperation and put all loadImage: code into it "main" method (just move all code here and nothing else) and all work just perfect!
As about scroll delaying: it occurs cause loading images to UIImageView (it takes long time because of decompress and rasterize (as I understood).
So better way is to use CATiledLayer. It loads data in background and do it much faster.
The delays on main thread is due to a the mode of the runloop while you scroll. I suggest you to watch the WWDC2011 networking app sessions. I don't know if it is fine to subclass an NSInvocationOperation that is a concrete subclass of NSOperation. I will subclass NSOperation instead. For my experience if you like to avoid sluggish scrolling, you should create NSOperation subclasses that load their main on a specific thread for networking operation (you must create it). There is a wonderful sample code from apple https://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html
The way that NSOperationQueue works with respect to "setSuspended" is that it won't start to run newly added NSOperations added to it after that point, and won't start to run any that are currently in it that haven't started running yet. Are you sure your operations you're trying to cancel haven't already started yet?
Also - does your NSOperation subclass correctly deal with Key Value Observing? Concurrent Queue subclassed NSOperations have to call willChangeValueForKey and didChangeValueForKey for some properties here - but doesn't look like that's the issue as your queue doesn't set isConcurrent. Just FYI if you go that route.