On Nov 19, 2008, at 10:13 AM, Brian Stern wrote:
I think that you're probably right and that it's redundant.
Needless to say, mmalc's best practice has the outlets being
released in dealloc. That's why I had that code there in the first
place.
FWIW, I don't think that UIViewController is documented as setting
its view to nil from its dealloc method. Frankly I don't know why
it does it. I don't think it needs to. It could certainly change in
the future. In fact another best practice (I think this is from
mmalc) is to not set properties to nil in dealloc but to simply
release them. If this changed the retained outlets would leak.
But if your dealloc is like this...
- (void)dealloc
{
self.thisProp = nil;
self.thatProp = nil;
...
}
then you'll be calling the accessors and the right thing will happen
(i.e. release if necessary). This is what I currently do for all dev
work (iPhone or Mac OS X). In fact, I use accessors everywhere and
never do direct ivar access.
I don't feel strongly about this, but not having the release code in
my dealloc method makes me a little nervous. I do understand that
my releaseOutlets method gets called twice when the object is being
dealloced.
This has been a very interesting read. I currently do not have any
special code in place to handle low-memory stuff.
In short, the way I think of it, -setView: _IS_ the one centralized
place that deals with all view-related pointers, including all
outlets. And UIViewController calls -setView: at all the necessary
times (setup, memory warning, dealloc), so you don't have to do
anything else.
I certainly had never thought of any reason to override this
accessor before this issue came up. loadView and viewDidLoad are
the normal override points for view creation and there are others
for view appearance and disappearance, as I'm sure you know. It's
just that there's no comparable override point for the view being
unloaded, even though that's a normal part of view controller life
on iPhone.
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.
If a view ends up not being loaded due to error warnings, it could be
loaded at a later point in time. Assuming there's enough memory at
that point, your loadView will once again be called.
Personally, if any of my instances do get sent the
didReceiveMemoryWarning message and there is no superview, I'll just
purge everything. I don't yet see any need to have only some objects
live.
Having said that, I'll probably adopt the following:
- (void)dealloc
{
[self myCleanup];
[super dealloc];
}
- (void)didReceiveMemoryWarning
{
[super didReceiveMemoryWarning];
if ([self.view superview] == nil)
{
[self myCleanup];
}
else
{
// in some cases, I lazily load objects (dictionarys, views,
etc.)
// such objects could also be purged here. If needed again,
they'll be
// lazily loaded once more.
}
}
- (void)myCleanup
{
self.thisProp = nil;
...
}
___________________________________________________________
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
