Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)
Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)
- Subject: Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)
- From: Brian Stern <email@hidden>
- Date: Mon, 17 Nov 2008 23:15:31 -0500
On Nov 17, 2008, at 11:05 PM, Roland King wrote:
OK, this issue has come up for me very recently. It appears
that on iPhoneOS IBOutlets are retained, regardless of the
presence of properties. Even worse, in the presence of an
assign property the outlet is still retained. Whatever code is
retaining the outlets never releases them. So it seems that
client code must release all outlets.
Seems to me that the outlets must have a retain count of at
least one when they're unarchived, as though they were alloc'd.
It makes sense that the programmer should have to manually
release objects in dealloc. How else would it happen?
IBOutlets are not necessarily top level objects. Most are simply
views that happen to be in the view hierarchy. There will
typically be one top level object in an iPhone nib. This will be
the view that belongs to UIViewController. It is the
UIViewController base class that loads the nib. As long as it
retains that top level view then all the subviews will also be
retained. They should be released when the UIViewController
releases its view outlet.
Right, and view is a property of UIViewController. When you have
your UIViewController release view, that is an example of the
programmer releasing an outlet assigned from IB, which you seem to
be arguing that the programmer shouldn't have to release objects
given to it from IB.
Luke
Exactly - most of the things you're hooking up in IB are your own
objects, those outlets are just instance variables which are being
set for you. It's your object, you have to deal with the lifetimes
of the objects you refer to. I don't see why IB makes any
difference, it's just calling setFoo: on some instance of your
class, what you define setFoo to do is entirely up to you, but if it
retains the argument, then you have to release it one day, in
dealloc() would be the natural place.
The iPhone version of nib unarchiving and hookup seemed very
consistent to me, it makes use of properties or setFoo: if you have
them, allowing you to manage objects any way you like.
Perhaps the new @property() syntax makes it easy to forget about
object lifetimes because it does the set/get/change automagically.
These days when I add any property I go right to the dealloc method
(and init if I have one) and ensure I've managed that property
before I forget.
Yes, but this is exactly the point. If I have no property for an
Outlet it's still retained. If I have a property for an outlet that
is assign, and not retain the outlet is still retained, and I still
must release it, even though I never retained it.
When you say I can manage the outlets any way I like this is wrong.
They are managed for me. I want them to not be retained. I don't
have that option.
Now that I understand this I can live with it. But it still makes no
sense to me.
_______________________________________________
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