Re: Where's the best place for addObserver and removeObserver
Re: Where's the best place for addObserver and removeObserver
- Subject: Re: Where's the best place for addObserver and removeObserver
- From: "Joan Lluch (casa)" <email@hidden>
- Date: Fri, 18 Jul 2008 00:12:33 +0200
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 (email@hidden)
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:
This email sent to email@hidden