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: Jonathan Hess <email@hidden>
- Date: Mon, 17 Nov 2008 21:34:47 -0800
On Nov 17, 2008, at 10:12 PM, Brian Stern wrote:
On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote:
One other consideration, particularly in iPhone applications, is
where you might have outlets to subviews of a main view that might
be released in sime situations -- e.g. a UIViewController whose
view is released in didReceiveMemoryWarning. To ensure that you
don't prolong the lifetime of objects you got from the nib, you
should set (use your accessor methods to) set those variables to
nil in the relevant method, e.g.:
@interface MyController : UIViewController {
UILabel *label;
...
}
@property (nonatomic, retain) IBOutlet UILabel *label;
then
- (void)didReceiveMemoryWarning {
self.label = nil;
[super didReceiveMemoryWarning];
}
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.
The above statements are not true. On the iPhone, outlets are
connected with setValue:forKeyPath:, and no explicit retention is done
by the NIB unarchiving code. It maybe true that the objects are
retained in some other fashion, independent of outlets. For example,
when the MainWindow.nib is loaded by UIApplication, UIApplication
explicitly retains the returned top level objects. That's a property
of UIApplication, and doesn't really have anything to do with NIB
loading in general. In the future, other nib loading classes may
choose to do the same thing. If this is the situation you're referring
to, and you're sending your outlet objects an extra release message,
you're over releasing them.
The solution to a memory leak should never be an unbalanced release.
You should use instruments and object alloc to determine exactly where
the unbalanced retain is, and then balance it correctly. If you find a
leak in framework code, you should file a bug, and you may consider
over releasing it on your end for ballence, but if you choose to do
that, you should do it with extreme caution. If there really is a leak
in the framework code, then when it's fixed, you're unbalanced
releases will start causing crashes.
The documentation on this is vague, with a lot of 'should's and not
clear statements of what really happens.
If you ask specific questions about specific pieces of documentation,
I'm sure that many readers would be happy to help you.
Jon Hess
Actually this isn't (only) related to didReceiveMemoryWarning (which
I hadn't considered related to this problem until you raised it).
Is this the way that things are supposed to work on iPhone OS?
--
Brian Stern
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
_______________________________________________
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