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: Roland King <email@hidden>
- Date: Tue, 18 Nov 2008 13:59:42 +0800
Hey Brian -
Outlets for iPhone OS are established by calling
setValue:forKeyPath:. The behavior of setValue:forKeyPath: is that
if a setter exists, it is called. If a setter does not exist, the
instance variable is looked up and set directly, and if it is an
object, it is retained. This means that for IBOutlets, with no
setters, they're retained in iPhone OS. This is different from Mac
OS X. If you're writing code on both platforms, or are planning to,
you should always use properties on both platforms since it makes
the decision to retain outlets explicit and obvious.
How come the documentation that mmalc quoted doesn't have this clear
statement?
which one did he quote, the one I suggested to you has it .. it's under
Nib Object Retention. It's a page I have bookmarked because as I switch
between iPhone and regular OSX I like to remind myself what it says.
It's pasted below.
iPhone OS - managed memory model
Objects in the nib file are created with a retain count of 1 and then
autoreleased. As it rebuilds the object hierarchy, however, UIKit
reestablishes connections between the objects using the
|setValue:forKey:| method, which uses the available setter method or
retains the object by default if no setter method is available. If you
define outlets for nib-file objects, you should also define a setter
method for accessing that outlet. Setter methods for outlets should
retain their values, and setter methods for outlets containing top-level
objects must retain their values to prevent them from being deallocated.
If you do not store the top-level objects in outlets, you must retain
either the array returned by the |loadNibNamed:owner:options:| method or
the objects inside the array to prevent those objects from being
released prematurely.
_______________________________________________
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