Re: KVO: when to stop observing?
On 2009 Aug 29, at 23:59, Michel Schinz wrote:
I'm therefore looking for better solutions, and would be interested
to know what people have come up with.
I believe the best answer to the question of "when to stop observing"
is "as soon as possible".
I was having trouble with a Core Data document (NSPersistentDocument)
observing too long, until I started cleaning things like this up in -
[NSDocumentController removeDocument:]. See typical code below.
You should also scroll down in your mailbox and read the thread which
was still active yesterday, "Re: Get error message about registered
observers when Object receives dealloc message". There is a good
discussion of this issue.
In the implementation of my subclassed NSDocumentController
- (void)removeDocument:(NSDocument *)document {
// Remove observations by document's window controller
[[MAKVONotificationCenter defaultCenter] removeObserver:
[(Bkmslf*)document bkmslfWinCon]] ;
[[NSNotificationCenter defaultCenter] removeObserver:
[(Bkmslf*)document bkmslfWinCon]] ;
// Remove observations by document itself
[[NSNotificationCenter defaultCenter] removeObserver:document] ;
[[MAKVONotificationCenter defaultCenter] removeObserver:document] ;
[SSYMOCManager removeManagedObjectContext:[(Bkmslf*)document
managedObjectContext]] ;
[super removeDocument:document] ;
}
___
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: KVO: when to stop observing?
If you're targeting 10.6 only, this is taken care of you automatically according to the Foundation release notes. Any KVO observers will be automagically removed as observers by the runtime, and thus you won't have to do it at all. The release notes hint that the appropriate solution for 10.5 is to perform this inside your -finalize method. (Obviously this whole reply pertains only to garbage-collected environments). -- Steven Degutis http://www.thoughtfultree.com/ http://www.degutis.org/ On Sun, Aug 30, 2009 at 1:59 AM, Michel Schinz < michel.schinz.li...@gmail.com> wrote: > Hi, > > In my program, I rely heavily on key-value observing (KVO), which I find > really useful. However, I haven't found a good way to know when I should > stop observing, i.e. call "removeObserver:forKeyPath:". > > Until now, my solution has been to start observing in the designated > initialiser, and to stop observing in the "dealloc" method. This solution > kind of works, but has several drawbacks: > > 1. It doesn't work with GC, first because GC doesn't call "dealloc" and > second because the simple fact that my object is registered as an observer > probably prevents it from being collected in the first place (I haven't > checked, but that's what I gather from messages found in this list's > archive). Even if it didn't, stopping the observation in "finalize" wouldn't > be ideal, as object would keep getting notifications for some time after > becoming unreachable. > > 2. I have to be careful when I use this technique on CoreAnimation layers, > since CA uses the "initWithLayer:" method to create presentation layers > during animations. If "initWithLayer:" doesn't invoke the designated > initialiser, then the presentation layer doesn't observe anything, and the > program crashes when its "dealloc" method tries to call > "removeObserver:forKeyPath:". The "solution" I have found for this is to > keep track of whether a layer is a presentation layer or not, and only call > "removeObserver:forKeyPath:" for non-presentation layers. That's ugly. > > Overall, I have something that works but isn't elegant at all. I'm > therefore looking for better solutions, and would be interested to know what > people have come up with. > > It seems to me that the only clean solution would be to detect when an > object is "dead" and then call a method to make it stop all its > observations, but this is equivalent to solving the memory management > problem by hand, which is painful. > > Thanks, > Michel. > > ___ > > 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/steven.degutis%40gmail.com > > This email sent to steven.degu...@gmail.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
KVO: when to stop observing?
Hi, In my program, I rely heavily on key-value observing (KVO), which I find really useful. However, I haven't found a good way to know when I should stop observing, i.e. call "removeObserver:forKeyPath:". Until now, my solution has been to start observing in the designated initialiser, and to stop observing in the "dealloc" method. This solution kind of works, but has several drawbacks: 1. It doesn't work with GC, first because GC doesn't call "dealloc" and second because the simple fact that my object is registered as an observer probably prevents it from being collected in the first place (I haven't checked, but that's what I gather from messages found in this list's archive). Even if it didn't, stopping the observation in "finalize" wouldn't be ideal, as object would keep getting notifications for some time after becoming unreachable. 2. I have to be careful when I use this technique on CoreAnimation layers, since CA uses the "initWithLayer:" method to create presentation layers during animations. If "initWithLayer:" doesn't invoke the designated initialiser, then the presentation layer doesn't observe anything, and the program crashes when its "dealloc" method tries to call "removeObserver:forKeyPath:". The "solution" I have found for this is to keep track of whether a layer is a presentation layer or not, and only call "removeObserver:forKeyPath:" for non- presentation layers. That's ugly. Overall, I have something that works but isn't elegant at all. I'm therefore looking for better solutions, and would be interested to know what people have come up with. It seems to me that the only clean solution would be to detect when an object is "dead" and then call a method to make it stop all its observations, but this is equivalent to solving the memory management problem by hand, which is painful. Thanks, Michel. ___ 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
