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: Tue, 18 Nov 2008 13:39:30 -0500
Thanks Greg,
That does work and has no bad side effects. I can leave in the retain
properties and release the outlets in the view controller's dealloc
method.
Thanks,
Brian
On Nov 18, 2008, at 1:19 PM, Greg Titus wrote:
Brian,
The way to handle this is to _not_ respond to memory warnings in
subclasses (at least not for the purposes of view outlet handling -
there may be other non-view memory you want to free up in response
to a memory warning). Instead, implement -setView: in your
UIViewController subclass, and release outlets when the argument is
nil. For example:
- (void)setView:(UIView *)aView;
{
if (!aView) {
self.anOutlet = nil;
self.anotherOutlet = nil;
self.thirdOutlet = nil;
}
[super setView:aView];
}
This will correctly clean up all of your outlets whenever the
UIViewController unloads its view, and not otherwise.
Hope this helps,
- Greg
On Nov 18, 2008, at 10:01 AM, Brian Stern wrote:
OK Erik, I'll bite. What you describe above is correct as far as
it goes. However, when you say all the memory management is
handled in one place, of course it's two. The object has to be
released. The normal place to release objects is in their owner's
dealloc method, and this also applies to outlets.
However, UIViewController has the ability to unload its view outlet
in response to a memory warning. Any subclass should also release
its outlets in response to the memory warning, if the base class
releases its view, but not otherwise. So now there are three
places to manage the memory of these outlets. The problem is that
the base class doesn't always release its view in response to a
memory warning and as far as I can tell the subclass has no clean
way of telling if the view will be released or has been released.
That's the problem.
--
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