On Nov 18, 2008, at 1:14 AM, Brian Stern wrote:
On Nov 18, 2008, at 12:59 AM, Roland King wrote: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.Yes, that's it. I've read it plenty of times.iPhone OS - managed memory modelObjects 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.I admit that I didn't internalize this statement because the behavior is different from the Mac. I also didn't internalize this because it seems to contradict the standard Cocoa memory management rules. My code doesn't retain the outlets so it shouldn't have to release them.If you define outlets for nib-file objects, you should also define a setter method for accessing that outlet.Why SHOULD?
So that it's obvious to the reader of the code what is retained, and what isn't. If you have setters then you can easily look at the .m file and verify that the retains and releases are all balanced without having to know anything else.
Setter methods for outlets shouldWhy SHOULD?
You're free to have an outlet be non-retained, it's up to you. The same rules should apply to outlets that apply to other instance variables. You should retain your instance variables so they don't go away when you don't expect them to. You just have to watch out for creating cycles. If you do create a cycle, you can either break it explicitly, or you can use some non-retained instance variables.
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.In a nib loaded by UIViewController I have no access to the top level objects array so this isn't usually relevant.The shoulds in there confused me. The fact that the behavior is different from the Mac confused me. The fact that the behavior seems contrary to standard Cocoa memory management rules confused me.
Which parts do you feel are contrary? I'm guessing it's that outlets with no setters are retained. If that's the case, you might consider thinking of it this way: Interface Builder for the iPhone uses key value coding. That's really the truth of the matter and accurately describes everything that is going on. That outlets without a setter are retained is a side effect of using key value coding. Additionally having the outlet retain by default, and making that be the recommendation when you use properties or setters comes into balance with the fact you don't have to send a release massage to each top level nib object after loading a NIB on the iPhone. With that, the memory management rules for NIB loading on the iPhone actually pretty concise:
1. Outlets are set with key value coding - implies outlets with no setters are retained.
2. If you retain an outlet, you must release it.
3. If you want something to stay alive after the call to
loadNibNamed: you need to retain it in some way.
There really isn't anything in that list that is out of line with Cocoa memory management patterns.
Also, just incase you aren't familiar with it, here's a link to the key value coding programming guide: http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/
Good Luck - Jon Hess
I assure you that I'm not the only person confused by this and who doesn't understand this._______________________________________________ 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/jhess%40apple.com This email sent to [EMAIL PROTECTED]
_______________________________________________ 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]
