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: Wed, 19 Nov 2008 16:57:48 -0500
On Nov 19, 2008, at 4:41 PM, Ricky Sharp wrote:
From Apple's template code, didReceiveMemoryWarning does have these
code comments generated:
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
// Release anything that's not essential, such as cached data
So, one should release all outlets that are tied to the view _iff_
it doesn't have a superview. And then of course purge all support
objects that would not be of any use.
Having said that, I'll probably adopt the following:
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
if ([self.view superview] == nil)
{
The problem with this code is that the view accessor causes the view
to be loaded if it's not already loaded. So simply by asking for
self.view.superview you may be causing your entire view hierarchy to
be loaded in from the nib. This doesn't seem to be a good thing to do
inside a memory warning. Besides that, the code you showed is wrong.
You have to have the call to super at the end of the method after you
call self.view.superview, otherwise you're guaranteeing that the view
will be loaded every time your method is called.
This is not just an academic point. The way that many iPhone apps are
constructed with navbars means that you've got a root view and then
one or more other view controllers that get pushed. The root view
will participate in all memory warnings for the life of the app and
may be unloaded many times. And that's all fine. It just doesn't
make any sense to load it in response to a memory warning.
That's why I said upthread that self.view will never be non-nil.
I'm starting to think that maybe using the assign properties is the
better way to handle this.
--
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