Re: NSURLConnection retaining delegate?
Re: NSURLConnection retaining delegate?
- Subject: Re: NSURLConnection retaining delegate?
- From: Mike Abdullah <email@hidden>
- Date: Thu, 26 Nov 2009 11:20:31 +0000
On 26 Nov 2009, at 07:23, Alexander Spohr wrote:
>
> Am 25.11.2009 um 23:25 schrieb Jerry Krinock:
>
>>
>> On 2009 Nov 25, at 12:53, Alexander Spohr wrote:
>>
>>> I meant NSURLConnection.
>>
>> * Normally the delegate is receiving and storing headers, data and errors for you. You should retain the delegate as long as you are interested in the headers, data or errors being stored. Once you have extracted or wish to abandon this information, release the delegate or allow it to be autoreleased.
>
> This is the problem. Releasing is not enough in this case.
>
> I have this layout:
>
> Ownership:
> Controller -> Loader -> NSURLConnection
>
> Delegation:
> NSURLConnection -> Loader -> Controller
>
>> The idea is that you mind your own references, and NSURLConnection will mind its own references.
>
> Controller's dealloc would just release Loader.
> Loaders dealloc would just call cancel and release NSURLConnection.
> Controller does not set Loader's delegate to nil because it will get recycled anyway because Controller and no one else owns it.
> -BUT-
> NSURLConnection still holds on to Loader and sends it connectionDidFinish. This in turn makes Loader tell its own delegate that the loading is complete. Because Loader does not retain its delegate (avoiding retain-cycles) everything blows up.
In practice, NSURLConnection does the right thing. But it appears to be unwanted behaviour to begin with until you dig a little deeper.
All that happens (as far as I am aware) is the connection will retain its delegate for the duration of the connection, releasing it the connection finishes, fails, or is cancelled. One advantage is that you can happily set up a connection without retaining it, and it will be deallocated once done loading; sometimes helpful for small throwaway tasks.
>
> Or is the contract to always [anyObject setDelegate:nil] before you release the related objects? That would be news for me.
You should ALWAYS do this. Otherwise, if anything else in the system has chosen to retain anyObject, then it will still have a weak reference to the delegate but that reference is now to an invalid object. i.e. a dangling pointer. It's all to easy for anyObject to stick around just a little longer than you expected, try to message its delegate, and then crash.
NSURLConnection is a bit of a twist on this behaviour, as there is no -setDelegate: method. Instead it is expected that when you are done with the connection it will be because it finished/failed, OR because you are cancelling it. Cancelling should release the delegate, achieving the same effect as -setDelegate:nil.
Work within this setup and you should find NSURLConnection behaves perfectly.
>
> atze
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden