Re: further confusion regarding the release of controls loaded from a nib
Well, my code doesn't show things being allocated and assigned to the IBOutlets, but it shows a bunch of releases of the associated members. As far as I can gather, the code is now correct. It is this asymmetry that strikes me as messy and error-prone. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
On Mar 20, 2012, at 5:59 PM, G S wrote: > I'm doing an iPhone app. I'm not doing any Mac app. > > I should simply have said "the nib-loading behavior". Except the nib loading behavior is vastly different on the two operating systems. This is why the documentation goes into detail about both. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
I'm doing an iPhone app. I'm not doing any Mac app. I should simply have said "the nib-loading behavior". ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
On Mar 20, 2012, at 5:33 PM, G S wrote: > Needless to say, it seems like ARC was a desperately needed step forward. > I don't mind doing things "the right way" and I have a high tolerance for > syntactic tedium, but the invisibility of NSNib's usage of properties and > the resulting asymmetry of the code (a bunch of releases in dealloc with no > corresponding allocations) is just asking for trouble. You said you're using UIViewController. NSNib is a Mac OS X only class. UINib is the iOS counterpart, and it has much saner behavior. So which are you actually using? It's important to be very precise. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
I went through and removed all the IBOutlet notation from the members and reconnected everything to the properties in IB. Also added release calls for all the controls in dealloc. The app appears to be quite solid, with no leaks or analyzer issues detected. I'm calling it done! Needless to say, it seems like ARC was a desperately needed step forward. I don't mind doing things "the right way" and I have a high tolerance for syntactic tedium, but the invisibility of NSNib's usage of properties and the resulting asymmetry of the code (a bunch of releases in dealloc with no corresponding allocations) is just asking for trouble. Compounding this mess was IB's wretchedly defective display of outlets. If you rename members, or remove their IBOutlet notations, the three lists of outlets in IB are wildly wrong and will actually change before your eyes with no user interaction. Outlets will appear and disappear from the two context menus on "File Owner" and from the Inspector seemingly at random. IB simply used to crash in this situation (reconnecting renamed members to controls), but that was fixed in 4.3.1 (Radar 10780292 filed, confirmed, and returned to me for verification). Then there's the display of redundant outlets if you've put "IBOutlet" on both the member and the property as was shown in examples in the past. IB should take @synthesize aProperty=_aProperty into account. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
Set breakpoints on them and right after them and when you hit them see: 1) what their values are 2) if they ever get hit at all. That should help you get to the bottom of what's being used when. On Mar 20, 2012, at 5:50 PM, G S wrote: > OK, I think I know why there weren't any leaks. > > Per (possibly old) examples, I have "IBOutlet" in both the member-variable > declarations and the property declarations. > > Now I'm realizing that IB will show two outlets: one for the member > variable itself, and one for the property when you have this: > > @synthesize webView=_webView > > All of my connections in IB are still made to the member variables. So are > the properties not being used by NSNib? My guess is that they aren't, and > thus the controls aren't being retained. > ___ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com - Alex Zavatone ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
OK, I think I know why there weren't any leaks. Per (possibly old) examples, I have "IBOutlet" in both the member-variable declarations and the property declarations. Now I'm realizing that IB will show two outlets: one for the member variable itself, and one for the property when you have this: @synthesize webView=_webView All of my connections in IB are still made to the member variables. So are the properties not being used by NSNib? My guess is that they aren't, and thus the controls aren't being retained. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
Thanks. I didn't know whether they meant weak as a keyword necessarily, or simply the concept of a weak reference. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
The material quoted is post-ARC usage (not the use of "weak" and not "assign"). In the legacy paradigm material, you will see that pre-ARC. You can choose "retain" or "assign" (or "copy", but I'll leave that out here). iOS outlets should be held as "retain", and therefore need to be nil-ed in viewDidUnload (so that they can be released in low memory situations) and released in dealloc (or they will leak). You probably don't want to use "assign" because then if your view unloads, your outlets will be pointing at garbage until your view is reloaded. In iOS 4 ARC, the choices are "strong" (retain equivalent), "unsafe_unretained" (assign equivalent). Here, outlets should be "strong" but you will no longer need to call release in dealloc since ARC handles that. You will need to nil them in viewDidUnload (so that they can be released in low memory situations). You probably wouldn't want to use "unsafe_unretained" for the same reasons as above. In iOS 5 ARC, you can also use "weak". "Weak" acts like "assign" except that the references will be automatically nil-ed when the object is released. Here, outlets should be "weak." So when your view gets unloaded, your outlets will get deallocated (as you aren't holding on to them with strong), but ARC will magically nil your outlets so there is no chance that you will try access a zombie. Aaron On Mar 20, 2012, at 1:49 PM, G S wrote: > The Apple doc for iOS says: > "From a practical perspective, in iOS and OS X outlets should be defined as > declared properties. Outlets should generally be weak, except for those from > File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard > scene) which should be strong. Outlets that you create should will therefore > typically be weak by default because: > Outlets that you create to, for example, subviews of a view controller’s view > or a window controller’s window, are arbitrary references between objects > that do not imply ownership." > > This just adds more confusion. If the properties for the majority of > IBOutlets are weak (since they're usually all going to be owned by the > UIViewController's view), why would we release them in dealloc? That seems > like an error. And setting them all to nil in viewDidUnload wouldn't seem to > have any effect, other than simply being good practice for safety. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: further confusion regarding the release of controls loaded from a nib
On Mar 20, 2012, at 1:49 PM, G S wrote: > This just adds more confusion. If the properties for the majority of > IBOutlets are weak (since they're usually all going to be owned by the > UIViewController's view), why would we release them in dealloc? If you aren't using ARC, then you couldn't have declared them weak, and most likely declared them as retain. As such you are responsible for releasing them. -- David Duncan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
further confusion regarding the release of controls loaded from a nib
The Apple doc for iOS says: "From a practical perspective, in iOS and OS X outlets should be defined as declared properties. Outlets should generally be weak, except for those from File’s Owner to top-level objects in a nib file (or, in iOS, a storyboard scene) which should be strong. Outlets that you create should will therefore typically be weak by default because: - Outlets that you create to, for example, subviews of a view controller’s view or a window controller’s window, are arbitrary references between objects that do not imply ownership." This just adds more confusion. If the properties for the majority of IBOutlets are weak (since they're usually all going to be owned by the UIViewController's view), why would we release them in dealloc? That seems like an error. And setting them all to nil in viewDidUnload wouldn't seem to have any effect, other than simply being good practice for safety. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
