Shrutimarkad123 / wsdl2objc

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

SOAP Binding Operation delegate property should be retained #151

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Create classes from WSDL
2. Create a delegate class for an asynchronous call
3. Instantiate (alloc, init) the delegate "d"
4. Call [binding XXXAsyncUsingParameters:param delegate:d];
5. Release the delegate

What is the expected output?
No problems

What do you see instead?
Runtime crash.

What version of the product are you using? On what operating system?
0.7, iOS 4.3

Please provide any additional information below.
The problem appears to be that the delegate is not retained when calling the 
...AsyncUsingParameters:delegate: method.
Because I alloced/inited it, it is my responsibility to release it, but due to 
the async call, it will no longer be there, when the NSOperation background 
call actually happens (same with autorelease).

As a workaround, I can leave out the release call, but that causes a memory 
leak.

Suggested fix: Make the delegate a retained property and release it in the 
operations dealloc method, before setting it to nil. (At least that's what 
works for me without crashing and without leaking, according to Instruments)

Original issue reported on code.google.com by daniel.s...@gmail.com on 24 Jun 2011 at 2:27

GoogleCodeExporter commented 8 years ago
This matter was already discussed, and the decision is not to retain the 
delegate.
In order to avoid cyclic references, the Apple guidelines specify that when 
using the delegate pattern, the delegate object should not be retained.
It is your responsibility to make sure the delegate is not released until the 
operation is finished.

The case you have described above can easily be resolved by adding one more 
object in the chain.
E.g. In my application I have one class called SOAPConnector, and each SOAP 
request is sent in a separate connector instance. I keep all the connectors in 
a global array, so the rest of the application can freely retain/release the 
connector. Once the response is received (or error), I remove the connector 
from the pool. If the other objects of the application have already released 
the connector (e.g. they don't need the result anylonger) the connector will 
simply get deallocated and the response would be ignored.

Original comment by pmilosev on 4 Oct 2011 at 11:53