Re: Does autoreleased NSURLConnection object guarantee job completion?
Re: Does autoreleased NSURLConnection object guarantee job completion?
- Subject: Re: Does autoreleased NSURLConnection object guarantee job completion?
- From: Keary Suska <email@hidden>
- Date: Thu, 12 Aug 2010 18:46:00 -0600
On Aug 12, 2010, at 1:41 PM, Conrad Shultz wrote:
> On Aug 12, 2010, at 11:06, Keary Suska <email@hidden> wrote:
>
>> If you really don't want (or can't have) an instance variable, you can init/alloc then release in connectionDidFinishLoading: and connection:didFailWithError:. I wouldn't recommend this though, as it is probably "bad form", but as long you never want to memory-manage NSURLConnections in that class, ever, it would be somewhat future proof.
>
> (First humble post - I will introduce myself properly when I have time to send out my own lingering Cocoa question.)
>
> Could you clarify why you think this paradigm is "bad form?" I only ask because as far as I can tell all of Apple's API docs follow said model. It seems like a good approach is to use init/alloc and still use an instance variable (to cancel the request, for example).
The "bad form" paradigm is when you do *not* use an instance variable, or some other means that allows reference within the class scope.
> I also notice in the documentation that either of the init methods retain the delegate, whereas the class method is not documented as retaining the delegate. If my reading is correct, this will have design impact as well.
Which is further reason why not having a reference to the instance could be "bad idea". Retain cycle, anyone? Note also that retaining delegates is inadvisable and should not be expected, hence the explicit documentation of the behavior. A bug should be filed against the docs about the class constructor--it either should indicate differing behavior or otherwise indicate that it uses a specific instance init method.
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
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