On 19 Feb 2009, at 21:41, Ricky Sharp wrote:
On Feb 19, 2009, at 2:18 PM, James Montgomerie wrote:
Returning to this months-old thread... Apologies for the length of
the mail, I thought it best to summarise what went before.
I now have shipping iPhone OS apps and during all my tests and
analyzing things in Instruments (connected to real hardware), I
didn't see a reason to put the proposed code in.
Perhaps this is just how I've coded things, but I've seen views get
unloaded and reloaded perfectly without any leaks. This included my
"main" screen view that was currently on the bottom of a nav
controller stack (not the current view). When I popped the current
screen, it was appropriately re-loaded. All IBOutlets re-wired, etc.
My dealloc code is doing stuff like:
self.someIBOutlet = nil;
self.someOtherIvar = nil;
...
[super dealloc]
I'm _definitely_ not trying to be argumentative or propose that
others avoid the "proper" solution. Just wanted to point out that
in my real-world situation, I just haven't had the need for it.
I feel like I may have opened a can of worms here.
To be clear, I was not saying that there were any problems at-all with
default implementations of these methods - the only potential problem
is if you try to be 'smart' in the wrong way about what you do in
didReceiveMemroyWarning with respect to outlets or other resources
loaded manually in loadView.
There's also no problem if you follow the now-recommended route of
nilling out outlets in setView - I was just enquiring if my way of
doing things was actively /wrong/ (which seems to be the case,
unfortunately for me).
Jamie.
_______________________________________________
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 arch...@mail-archive.com
