On Nov 19, 2008, at 10:29 AM, Greg Titus wrote:
On Nov 19, 2008, at 7:00 AM, Brian Stern 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.
(b) For non-top-level-object, specify an assign attribute for the
property -- and risk dangling pointers.
The override of setView is very similar to the viewDidUnload
callback that I proposed as a solution for this. It has its own
further issues. UIViewController calls [setView:nil] from its
dealloc method so the subclass has to be prepared for this. What
I've done is to add all the public retain properties for all the
outlets. Additionally I've added a
-(void)releaseOutlets
method that uses the properties and sets them all to nil. I call
this method from my subclass's dealloc method and setView:
override. That way I only have one place to write the code that
releases all the outlets.
Brian,
What is your reason for having a separate -releaseOutlets method to
do this?
The sample that I gave (calling self.anOutlet = nil; when the
argument to -setView: is nil) will do whatever releasing is required
(if the anOutlet property is "retain") or simple zeroing the pointer
(if the anOutlet property is "assign"). The fact that
UIViewController calls -setView:nil from its -dealloc is just
additional convenience. All of your outlets get cleaned up at the
same time as the UIViewController cleans up the main view. There is
no need to write any outlet related code in your -dealloc at all,
since it is all handled via the superclass and the -setView: override.
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.
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.
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.
Brian
_______________________________________________
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]
