arishanapalli / wsdl2objc

Automatically exported from code.google.com/p/wsdl2objc
MIT License
0 stars 0 forks source link

Add cancel method to SoapOperationBaseClass #91

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I need cancellation to safely close underlying connections when the user
wishes to abort all requests manually

It seems the right place to add this is on the base class SoapOperation,
which then calls [urlConnection cancel];

Original issue reported on code.google.com by vijay.sa...@gmail.com on 14 May 2010 at 6:06

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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:

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
"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