Open GoogleCodeExporter opened 9 years ago
We could instead have the searchAsyncUsingRequest:delegate: method return a
pointer to the operation called.
Then you could grab the NSURLConnection using the urlConnection property, and
you could kill it whenever you
wanted.
Thoughts?
Original comment by hasse...@gmail.com
on 1 Jun 2010 at 2:10
I could call [operation.urlConnection cancel] now, but is there other cleanup
that
needs to happen?
I'm not 100%, what are your thoughts?
Original comment by vijay.sa...@gmail.com
on 1 Jun 2010 at 2:49
No other cleanup, no. But how can you get the operation? Right now it's not
exposed in the binding class (unless you bypass searchAsyncUsingRequest and
manually call performAsynchronousOperation)
Original comment by hasse...@gmail.com
on 22 Jun 2010 at 10:25
I've attached a simple patch that returns the binding operation object instead
of void on the Async calls.
However, I've tried to call cancel on this object, and was hoping to use the
isCancelled property in the incoming message handling to ignore the returned
data and thus avoid the crash, but to no avail.
It seems that cancel may not exist or some other reason, but isCancelled is not
set as per Apple's documentation.
So my solution is this (when used with my patch attached)
Keep a reference to an operation that is known to be in progress:
operation = [binding __MyCall__AsyncUsingParameters:request delegate:self];
and when you dealloc your delegate (in this case self) you need to call:
operation.delegate = nil;
so that the internal handler will just ignore the incoming message.
(To be safe I set my operation to nil on init and after my calls complete.)
Original comment by lailo...@gmail.com
on 28 Feb 2011 at 9:31
Attachments:
The thing is that when you cancel an operation that is in progress, nothing
happens.
Only when an op is in the queue will it cancel and be set as cancelled and not
trigger. When it's already triggered and in progress, you can't do anything
with it "by default" in the base NSOperation class. If you want to implement an
in-progress cancelling, you have to do the whole work manually, making sure
that every dependency is properly taken care of.
Original comment by hasse...@gmail.com
on 9 Mar 2011 at 2:48
If you call cancel something is supposed to happen... NSOperation is supposed
to set isCancelled to true. Which for some reason for me it does not. Sure it
is up to you to do the cancellation footwork in the main loop.
So since this does not happen, all I can really do is orphan the task and
remove its binding.
Original comment by lailo...@gmail.com
on 9 Mar 2011 at 3:30
"If you call cancel something is supposed to happen... NSOperation is supposed
to set isCancelled to true."
That's correct. SInce it doesn't seem to happen, this is weird to say the least.
Original comment by hasse...@gmail.com
on 9 Mar 2011 at 3:37
Original issue reported on code.google.com by
vijay.sa...@gmail.com
on 14 May 2010 at 6:06