Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
- Subject: Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
- From: Ricky Sharp <email@hidden>
- Date: Fri, 21 Nov 2008 19:21:00 -0600
On Nov 21, 2008, at 6:53 PM, mmalcolm crawford wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in
many respects academically unsatisfying.
- (void)setView:(UIView *)aView;
{
if (!aView) {
// set outlets to nil, e.g.
self.anOutlet = nil;
}
// Invoke super's implementation last
[super setView:aView];
}
Unfortunately, although in principle this is correct, in practice it
may fall foul of another issue.
Because UIViewController currently implements its dealloc method
using the setView: accessor method (rather than simply releasing the
variable directly...), self.anOutlet = nil will be called in dealloc
as well as in response to a memory warning... This will lead to a
crash in dealloc.
But, that's only if dealloc releases objects directly and doesn't use
accessors or use the workaround shown below.
I'm now really curious as to why UIViewController uses an accessor in
dealloc since that's supposed to be bad practice. Has a bug been
filed against that too?
The remedy is to ensure that outlet variables are also set to nil in
dealloc:
- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}
That is indeed a workaround, but one of the reasons I moved towards
using accessors instead (i.e. I didn't have to think about all the
edge cases where clearing out the ivar was absolutely necessary; the
accessor always does the right thing).
Now then, two things...
(1) In my personal code, I'm the only developer and do not integrate
with any third party code (I only use Apple's SDKs directly). Having
said that, I do have full control over my own objects and thus don't
have any pitfalls in using accessors in inits and/or deallocs.
(2) But, I can see where in the general case, this is becoming quite
problematic for folks. After all, it's always dangerous to base your
code on implementation details such as these.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
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