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.
This is standard (best) practice for memory management. It's not
clear what the problem is here.
The only difference with outlets is that, if you don't follow best
practice, you have to spend some time thinking about whether or not
you have to release in dealloc (more on this below).
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.
You're shifting the goalposts; this is not the problem you originally
described.
In fact there have been several problems: You didn't understand the
documentation as written; in testing the implementation of outlets you
made a fundamental mistake; and -- as noted in my original message in
this sub-thread -- the "situation" with outlets has heretofore been "a
mess".
To reiterate points that Jon and Joar have made:
You shouldn't have to think about something as mundane as "how do I
manage memory for outlets?". There are far more interesting issues
for a programmer to spend their time on. This is the reason for
proposing a new "best practice" that will address all situations
simply and easily. *If* you know what you're doing -- and your
"experiment" has shown that even relatively experienced developers may
sometimes not "know what they're doing" -- then it is perfectly
possible to deviate from the suggested pattern, but you then do this
at your own risk.
I do, though, have to apologise for introducing a wrinkle (the problem
of UIViewController's response to memory warnings) and then providing
an incorrect solution. I managed to mistake a question from some time
ago for the answer -- mainly because I never received an answer. I
have now and can relay part of it (note to self: <rdar://problem/
5834347>). There are several issues:
The template clearly indicates what should be done:
- (void)didReceiveMemoryWarning {
[super didReceiveMemoryWarning]; // Releases the view if it
doesn't have a superview
// Release anything that's not essential, such as cached data
}
In theory, you should simply check whether the view has a superview:
- (void)didReceiveMemoryWarning {
if ([_view superview] == nil) {
// set outlets to nil
}
[super didReceiveMemoryWarning];
}
but since _view is declared as @package, you can't do that.
You could invoke 'view':
- (void)didReceiveMemoryWarning {
if ([self.view superview] == nil) {
// set outlets to nil
}
[super didReceiveMemoryWarning];
}
but this has the disadvantages that (a) in some situations it will
cause the view to be loaded before it is subsequently unloaded, and
(b) it isn't future proof.
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.
(b) For non-top-level-object, specify an assign attribute for the
property -- and risk dangling pointers.
It may be that a better approach will present itself time...
mmalc
_______________________________________________
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]
