Re: Where's the best place for addObserver and removeObserver
7/17/08 8:59 AM, also sprach [EMAIL PROTECTED]: However, the way I am doing it makes me wonder where the best place should be for adding and removing the observers. What I am currently doing is adding the observers in the awakeFromNib methods of each viewController, and removing them in the dealloc method of the same controller. I think that adding the observers in awakeFromNib methods is fine, but the fact that I retain the view controllers implies that such controllers are still observing the application delegate even if they are not currently showing. Is this a good coding/design pattern?. Furthermore, if I eventually switch to Garbage Collection in the future, those observers will not ever be removed. Or worse, in case I decided not to keep a reference in my window controller, and the GC eventually claims an unused view controller, then what will happen to the observers. Would someone bring a light to this.? Basically what i am asking is, where is the recommended place to add and to remove observers set up in views (or view controllers)? I don't think it matters when you *start* observing, as long the the observed objects are guaranteed to exist. awakeFromNib is a perfect place if you expect the observation to last the lifetime of the nib objects. I will say that removing observation in dealloc is a dangerous endeavor. It works if you can guarantee that the observer will be deallocated *before* the observed. This guarantee is difficult if not impossible in a nib-loaded situation, AFAIK. I believe that the bindings mechanism, however, has ways to deal with these issues in a nib-loaded situation (and generally as well). That might be an avenue to pursue. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business ___ 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: Where's the best place for addObserver and removeObserver
Hi Joan, As Keary says, removing in -dealloc is probably not the best thing to do as there are a few cases that this can bite you, like if your window controller retains the view controllers, and -dealloc is called on the window controller, which would proceed to release its collection of view controllers. In this case you get console logs a- plenty informing you that the window controller is being deallocated while observers are still registered with it. What I do is get all the view controllers to conform to a formal protocol called DetailViewController. The protocol has two methods that the conforming parties must implement, - becomeDetailViewController: and -resignDetailViewController: (the names are a result of my master/detail view setup in my app). In these methods the receiver can setup and tear-down both bindings and observations. So when I swap a view in or out I have a single - swapDetailViewWithView: method in my windowController that wraps the call to the window's content view -replaceSubview:withView (I think that's the name) with calls to the current and potential detail view controllers -resign... and -become..., respectively. HTH, Jonathan www.espresso-served-here.com On 17 Jul 2008, at 16:34, Keary Suska wrote: I don't think it matters when you *start* observing, as long the the observed objects are guaranteed to exist. awakeFromNib is a perfect place if you expect the observation to last the lifetime of the nib objects. I will say that removing observation in dealloc is a dangerous endeavor. It works if you can guarantee that the observer will be deallocated *before* the observed. This guarantee is difficult if not impossible in a nib- loaded situation, AFAIK. I believe that the bindings mechanism, however, has ways to deal with these issues in a nib-loaded situation (and generally as well). That might be an avenue to pursue. When bindings are set up in nib, Apple takes care of it (with private stuff), but programmatic bindings have to be unboud manually. HTH, Keary Suska Esoteritech, Inc. Demystifying technology for your home or business smime.p7s Description: S/MIME cryptographic signature ___ 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: Where's the best place for addObserver and removeObserver
El 17/07/2008, a las 18:13, Jonathan Dann escribió: Hi Joan, As Keary says, removing in -dealloc is probably not the best thing to do as there are a few cases that this can bite you, like if your window controller retains the view controllers, and -dealloc is called on the window controller, which would proceed to release its collection of view controllers. In this case you get console logs a- plenty informing you that the window controller is being deallocated while observers are still registered with it. Well, it does not happen in my case because the observed property is in the Application delegate, but you are right that I would get into this if I was observing something in the window controller What I do is get all the view controllers to conform to a formal protocol called DetailViewController. The protocol has two methods that the conforming parties must implement, - becomeDetailViewController: and -resignDetailViewController: (the names are a result of my master/detail view setup in my app). In these methods the receiver can setup and tear-down both bindings and observations. Thanks, I understand this approach and it is much safer than mine. Furthermore, I can easily find the right place in my window controller to send these messages because I already have implemented insertion and removal of my view controllers to/from the responder chain so they can pick up menu actions So when I swap a view in or out I have a single - swapDetailViewWithView: method in my windowController that wraps the call to the window's content view -replaceSubview:withView (I think that's the name) with calls to the current and potential detail view controllers -resign... and -become..., respectively. Exactly! Thanks again Joan Lluch___ 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]
