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 theobserved objects are guaranteed to exist. awakeFromNib is a perfect place ifyou 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- loadedsituation, 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 anavenue 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]
