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.
Or is the contract to always [anyObject setDelegate:nil] before you release the
related objects? That would be news for me.
atze
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
