> On Jun 16, 2013, at 9:08 PM, Quincey Morris wrote: > > On Jun 16, 2013, at 17:29 , Kyle Sluder <k...@ksluder.com> wrote: > >> For this reason, that document recommends you use a weak declared >> property for outlets to non-top-level objects. You should probably >> follow that recommendation. > > Under the circumstances, since this is a manual RR app, just releasing the > UIDatePicker [ivar] in dealloc might be a superior approach. > > If the UIDatePicker is a *top-level* object in the nib, the IBOutlet needs to > be a strong reference -- unless there is some other guarantee that it will > outlive the nib itself. > > If it's not a top-level object, then the lifetime of whatever is keeping it > alive needs to be considered instead. > > In either case, using a strong reference seems more robust, since it doesn't > involve reasoning about the lifetime dependences, at the slight cost of an > explicit release.
For what it's worth, the Apple doc went on to say, for "legacy" memory management (I feel so old!): For iOS, you should use: @property (nonatomic, retain) IBOutlet UserInterfaceElementClass *anOutlet; Then: You should then either synthesize the corresponding accessor methods, or implement them according to the declaration, and (in iOS) release the corresponding variable in dealloc. I did this, with a @synthesize up front and an explicit release in the dealloc. Instruments shows the favorable return of memory when the UI is popped. Thanks again for the assistance! -Dan _______________________________________________ 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
