Re: Confused by memory issue with UIDatePicker
Re: Confused by memory issue with UIDatePicker
- Subject: Re: Confused by memory issue with UIDatePicker
- From: Daniel Wambold <email@hidden>
- Date: Sun, 16 Jun 2013 21:21:35 -0400
> On Jun 16, 2013, at 9:08 PM, Quincey Morris wrote:
>
> On Jun 16, 2013, at 17:29 , Kyle Sluder <email@hidden> 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 (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