Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Le 25 févr. 09 à 00:44, Jonathan Hess a écrit :
On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote:
Am 20.02.2009 um 04:18 schrieb mmalc Crawford:
On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote:
See also updated: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html
The Doc states:
You should therefore also set outlet variables to nil in dealloc:
- (void)dealloc {
// release outlets and set outlet variables to nil
[anOutlet release], anOutlet = nil;
[super dealloc];
}
why not just use
[self setAnOutlet = nil];
or
self.anOutlet = nil;
Any danger in this? (except a bad implementation of setAnOutlet:)
Any of the standard arguments about not calling setters in dealloc
and init would apply. For example, if you were subclassed, and your
subclass had an override of one of your setters, and you called it
from dealloc you'd be calling one of their methods after they'd
called [super dealloc]. Or, you might later implement side-effects
for one of your setters not thinking about the called-from-dealloc-
case and introduce a subtle bug into your own code.
One question about this.
If I understand correctly the 64bit runtime, for property we don't
have to declare ivar.
Then, if I want to init a property and clear it in dealloc I must do :
self.myProperty = anObject; // in init
and
self.myProperty = nil; // in dealloc
Does it mean I must always declare ivars even for 64bit only
architecture ?
Frédéric___
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_4.html#//apple_ref/doc/uid/TP30001163-CH17-SW16 mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Le 25 févr. 09 à 18:37, mmalc Crawford a écrit : http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_4.html#//apple_ref/doc/uid/TP30001163-CH17-SW16 mmalc OK, thank you Frédéric ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote:
Am 20.02.2009 um 04:18 schrieb mmalc Crawford:
On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote:
See also updated: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html
The Doc states:
You should therefore also set outlet variables to nil in dealloc:
- (void)dealloc {
// release outlets and set outlet variables to nil
[anOutlet release], anOutlet = nil;
[super dealloc];
}
why not just use
[self setAnOutlet = nil];
or
self.anOutlet = nil;
Any danger in this? (except a bad implementation of setAnOutlet:)
Any of the standard arguments about not calling setters in dealloc and
init would apply. For example, if you were subclassed, and your
subclass had an override of one of your setters, and you called it
from dealloc you'd be calling one of their methods after they'd called
[super dealloc]. Or, you might later implement side-effects for one of
your setters not thinking about the called-from-dealloc-case and
introduce a subtle bug into your own code.
Jon Hess
atze
___
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 jh...@apple.com
___
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Am 20.02.2009 um 04:18 schrieb mmalc Crawford:
On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote:
See also updated: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html
The Doc states:
You should therefore also set outlet variables to nil in dealloc:
- (void)dealloc {
// release outlets and set outlet variables to nil
[anOutlet release], anOutlet = nil;
[super dealloc];
}
why not just use
[self setAnOutlet = nil];
or
self.anOutlet = nil;
Any danger in this? (except a bad implementation of setAnOutlet:)
atze
___
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 20, 2009, at 1:05 AM, Alexander Spohr wrote:
You should therefore also set outlet variables to nil in dealloc:
- (void)dealloc {
// release outlets and set outlet variables to nil
[anOutlet release], anOutlet = nil;
[super dealloc];
}
why not just use
[self setAnOutlet = nil];
or
self.anOutlet = nil;
The paragraph above illustrates exactly why you shouldn't do this.
See also, for example, http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_4_section_4.html#//apple_ref/doc/uid/TP30001163-CH22-SW13
mmalc
___
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Returning to this months-old thread... Apologies for the length of
the mail, I thought it best to summarise what went before.
I suggested that an appropriate implementation for
didReceiveMemoryWarning in a UIViewController subclass would be
On 22 Nov 2008, at 15:58, James Montgomerie wrote:
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
// Will not call loadView if the view is not loaded, because
// we can assume that if we get past the check for anOutlet
// the view must already be loaded.
self.anOutlet = nil;
}
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
}
mmalc looked into it, and said:
On 23 Nov 2008, at 20:10, mmalcolm crawford wrote:
It seems that, for various reasons, the setView: approach is still
preferred.
I left the code in my app as-is, because I didn't fancy changing it
all, and the response didn't indicate (to me, at least) that I was
doing anything unsafe, but after some testing I'm rethinking that.
Is the reason that the setView: approach is preferred that, despite
what the docs and comments in the files say, the superclass'
didReceiveMemoryWarning might /not/ actually release the view, even if
it doesn't have a superview? This would lead to the situation in
which, when the UIViewController is next used, loadView is not called
(because the view is not nil), but my resources /are/ nil, because I
released them in didReceiveMemoryWarning when I saw that the view had
no superview.
That's what my playing around seems to suggest, in the simulator,
calling didReceiveMemoryWarning directly, at least:
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
NSLog(@Released);
}
[super didReceiveMemoryWarning];
// accessing the ivar directly to avoid loadView - very much just
for testing purposes!
NSLog(@View: %p, %@, self-_view, self-_view);
}
produces, when I call didReceiveMemoryWarning directly, with the view
not visible:
2009-02-19 19:56:00.625 MyApp[76455:20b] Released
2009-02-19 19:56:00.626 MyApp[76455:20b] View: 0x43b24c0, UIView:
0x43b24c0
Jamie.
For those who didn't follow the original thread, the setView:
approach is, by the way:
On Nov 18, 2008, at 1:19 PM, Greg Titus wrote:
The way to handle this is to _not_ respond to memory warnings in
subclasses (at least not for the purposes of view outlet handling -
there may be other non-view memory you want to free up in response
to a memory warning). Instead, implement -setView: in your
UIViewController subclass, and release outlets when the argument is
nil. For example:
- (void)setView:(UIView *)aView;
{
if (!aView) {
self.anOutlet = nil;
self.anotherOutlet = nil;
self.thirdOutlet = nil;
}
[super setView:aView];
}
This will correctly clean up all of your outlets whenever the
UIViewController unloads its view, and not otherwise.
___
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 12:18 PM, James Montgomerie wrote: Is the reason that the setView: approach is preferred that, despite what the docs and comments in the files say, the superclass' didReceiveMemoryWarning might /not/ actually release the view, even if it doesn't have a superview It's what, for various reasons, engineering said is the best solution... See also updated: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
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. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 1:41 PM, Ricky Sharp wrote: Perhaps this is just how I've coded things, but I've seen views get unloaded and reloaded perfectly without any leaks. This isn't the issue. The issue is how much memory can you free up in response to a memory warning. If you don't follow this pattern, then you won't be freeing up as much as you could to. If your app isn't getting memory warnings, you won't encounter this at all. mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 3:52 PM, mmalc Crawford wrote: On Feb 19, 2009, at 1:41 PM, Ricky Sharp wrote: Perhaps this is just how I've coded things, but I've seen views get unloaded and reloaded perfectly without any leaks. This isn't the issue. The issue is how much memory can you free up in response to a memory warning. If you don't follow this pattern, then you won't be freeing up as much as you could to. If your app isn't getting memory warnings, you won't encounter this at all. OK, things have finally clicked :) Yes, I have never had memory warnings. Just unused objects at this moment unloaded to make room for more. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 1:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. I think Ricky just closed it -- thanks. mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 3:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. Nope; my fault. All this time I had misread the whole point of the threads. My app has never received low-memory warnings. So my observations in turn have nothing to do with it. I will re-add the proper refactor to my to-do list. There's a chance my particular apps will continue to never receive the warnings. But, I want them to be good citizens should they ever occur. ___ Ricky A. Sharp mailto:rsh...@instantinteractive.com Instant Interactive(tm) http://www.instantinteractive.com ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 2:01 PM, mmalc Crawford wrote: On Feb 19, 2009, at 1:57 PM, James Montgomerie wrote: I feel like I may have opened a can of worms here. I think Ricky just closed it -- thanks. And your post afforded a good opportunity to point to the updated documentation, so thanks for that too. mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Feb 19, 2009, at 12:34 PM, mmalc Crawford wrote: See also updated: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Articles/mmNibObjects.html Just to try to forestall what will probably otherwise be a flood of feedback; yes, there's a typo: [super release]; should be [super dealloc]; mmalc ___ 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
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Nov 22, 2008, at 8:29 AM, mmalcolm crawford wrote: Let me check on this one. It seems that, for various reasons, the setView: approach is still preferred. mmalc ___ 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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On 22 Nov 2008, at 00:53, mmalcolm crawford wrote:
Context:
UIViewController provides a method, didReceiveMemoryWarning, which
is invoked on view controllers when the amount of memory available
to the application is severely constrained. The goal of the method
is to allow view controllers to dispose of resources that are
currently not needed and that can be recreated later if required.
One such resource is the view controller's view itself. Assuming
that it does not have a superview, the view is disposed of ([self
setView:nil];).
A issue arises in that outlets to elements within the nib file are
typically declared as follows:
@property (nonatomic, retain) IBOutlet ElementClass *element;
Thus even though the main view is disposed of, absent any further
action the outlets are still retained. This is not in and of itself
a problem -- if and when the main view is reloaded, they will simply
be replaced -- but it does mean that the beneficial effect of the
didReceiveMemoryWarning is reduced.
There are, currently, a couple of possible remedies...
Maybe I'm missing something (I stopped following the previous thread),
but, presuming that super's -didreceiveMemoryWarning does indeed
Release[] the view if it doesn't have a superview, as documented,
couldn't these contortions be avoided (in a future-proof way) by doing
something like this in -didReceiveMemoryWarning, and not touching -
setView:?
- (void)didReceiveMemoryWarning
{
if(self.anOutlet !self.view.superview) {
// Will not call loadView if the view is not loaded, because
// we can assume that if we get past the check for anOutlet
// the view must already be loaded.
self.anOutlet = nil;
}
[super didReceiveMemoryWarning]; // Releases the view if it doesn't
have a superview
}
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 [EMAIL PROTECTED]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Nov 22, 2008, at 7:58 AM, James Montgomerie wrote:
if(self.anOutlet !self.view.superview) {
On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote:
You could invoke 'view':
- (void)didReceiveMemoryWarning {
if ([self.view superview] == nil) {
// set outlets to nil
}
[super didReceiveMemoryWarning];
}
but this has the disadvantages that (a) in some situations it will
cause the view to be loaded before it is subsequently unloaded, and
(b) it isn't future proof.
mmalc
___
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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. mmalc ___ 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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
But I'm assuming that self.anOutlet will be valid if and only if
self.view is already valid (in which case the call to
self.view.superview should be safe, no?).
Under this assumption, if self.anOutlet is nil, the be short-
circuited and self.view never called; if it is valid, it's safe to
call self.view.
It seems like, for this assumption not to hold, the outlets must not
be being set up at the same time as the view (which I guess could be
true if the programmer of the subclass we're talking about is doing
something strange, but is not what I would expect).
Jamie.
On 22 Nov 2008, at 16:16, mmalcolm crawford wrote:
On Nov 22, 2008, at 7:58 AM, James Montgomerie wrote:
if(self.anOutlet !self.view.superview) {
On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote:
You could invoke 'view':
- (void)didReceiveMemoryWarning {
if ([self.view superview] == nil) {
// set outlets to nil
}
[super didReceiveMemoryWarning];
}
but this has the disadvantages that (a) in some situations it will
cause the view to be loaded before it is subsequently unloaded, and
(b) it isn't future proof.
mmalc
___
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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On 22 Nov 2008, at 16:29, mmalcolm crawford wrote: On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. Oops, sorry, looks like we're mailing around each other now... 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 [EMAIL PROTECTED]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
Am 22.11.2008 um 01:53 schrieb mmalcolm crawford:
- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}
[super dealloc] ?
;)
atze
___
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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Nov 21, 2008, at 6:53 PM, mmalcolm crawford wrote:
This leaves us for now with two solutions:
(a) Greg's (override setView:) which is more future-proof but is in
many respects academically unsatisfying.
- (void)setView:(UIView *)aView;
{
if (!aView) {
// set outlets to nil, e.g.
self.anOutlet = nil;
}
// Invoke super's implementation last
[super setView:aView];
}
Unfortunately, although in principle this is correct, in practice it
may fall foul of another issue.
Because UIViewController currently implements its dealloc method
using the setView: accessor method (rather than simply releasing the
variable directly...), self.anOutlet = nil will be called in dealloc
as well as in response to a memory warning... This will lead to a
crash in dealloc.
But, that's only if dealloc releases objects directly and doesn't use
accessors or use the workaround shown below.
I'm now really curious as to why UIViewController uses an accessor in
dealloc since that's supposed to be bad practice. Has a bug been
filed against that too?
The remedy is to ensure that outlet variables are also set to nil in
dealloc:
- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}
That is indeed a workaround, but one of the reasons I moved towards
using accessors instead (i.e. I didn't have to think about all the
edge cases where clearing out the ivar was absolutely necessary; the
accessor always does the right thing).
Now then, two things...
(1) In my personal code, I'm the only developer and do not integrate
with any third party code (I only use Apple's SDKs directly). Having
said that, I do have full control over my own objects and thus don't
have any pitfalls in using accessors in inits and/or deallocs.
(2) But, I can see where in the general case, this is becoming quite
problematic for folks. After all, it's always dangerous to base your
code on implementation details such as these.
___
Ricky A. Sharp mailto:[EMAIL PROTECTED]
Instant Interactive(tm) http://www.instantinteractive.com
___
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]
Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)
On Nov 21, 2008, at 5:21 PM, Ricky Sharp wrote:
But, that's only if dealloc releases objects directly and doesn't
use accessors or use the workaround shown below.
Yes, although following best practice is assumed... :-)
I'm now really curious as to why UIViewController uses an accessor
in dealloc since that's supposed to be bad practice. Has a bug been
filed against that too?
Yes.
The remedy is to ensure that outlet variables are also set to nil
in dealloc:
- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}
That is indeed a workaround, but one of the reasons I moved towards
using accessors instead (i.e. I didn't have to think about all the
edge cases where clearing out the ivar was absolutely necessary; the
accessor always does the right thing).
I would suggest that releasing then setting the variable to nil is a
better strategy than using the accessor.
Now then, two things...
(1) In my personal code, I'm the only developer and do not integrate
with any third party code (I only use Apple's SDKs directly).
Having said that, I do have full control over my own objects and
thus don't have any pitfalls in using accessors in inits and/or
deallocs.
That's fine; if you're *sure* you'll never run into a problem such as
this...
(2) But, I can see where in the general case, this is becoming quite
problematic for folks. After all, it's always dangerous to base
your code on implementation details such as these.
... indeed, this is why best practice is given as such.
mmalc
___
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]
