Re: NSNotificationCenter
Re: NSNotificationCenter
- Subject: Re: NSNotificationCenter
- From: Graham Cox <email@hidden>
- Date: Sat, 27 Sep 2008 10:08:56 +1000
On 27 Sep 2008, at 3:28 am, John Love wrote:
In almost all cases, whenever you call the -postNotificationName:
method of NSNotificationCenter, the object you pass is 'self'. If
it's any other, chances are you've done something weird.
So, short answer: your design is a bit whiffy. ;)
I love that word "whiffy" .. so bloody English, so Rex Harrison.
Well, I am English, FWIW....
I moved all -postNotificationName:object: to the receiver and so
that's done; not only that, it makes sense. I am the observer, so
it's the receiver that is responsible for posting or sending
changes to the defaultCenter.
First off, let's be clear about terms. I used the terms 'receiver' and
'transmitter' as an analogy for 'observer' and 'observed'
respectively. Of course the term 'receiver' also is used frequently
when talking about Objective-C to mean 'the object that receives a
message' - in other words the instance of a class implementing a
particular method. I wasn't using it in that sense so perhaps my
choice of terms was misleading.
So let's stick to 'observer' (the one responding to the notification)
and the 'sender' (the object I want to know about).
I said originally:
Shouldn't my call to -addObserver automatically monitor
"StatusChanged" rather than my having to -postNotificationName??
It does, but only when the receiver posts.
Having said that, let me restate it, perhaps a little more accurately:
I would like to some how "bind" the observer to the receiver so that
every time the receiver changes a parameter, it automatically
"posts" that a change has occurred, without having to explicitly post.
So now I'm confused about how you're using the term 'receiver'. Do you
mean it in the Objective-C sense or as receiver of a notification?
You need to ensure that the posting of the notifications is done
solely by the sender.
Here's how notifications work, in a nutshell:
Object A (the sender) changes state. It posts a notification to say
so. By some mechanism, Object B (the observer) receives that
notification and acts upon it. Maybe another object, C, wants to find
out about that same state change, so it can also register itself as an
observer of A. When A changes state, both B and C get the
notification, etc. "By some mechanism" is the role of
NSNotificationCenter. It just acts as a channel through which these
notifications get passed around - otherwise object A would have to
know about B and C and every other Tom, Dick or Harry that wanted the
info. Instead, using NSNotificationCenter, it only has to know about
that, and there is but one global instance, so there is a minimum of
coupling between objects.
Now, in your case, you were forcing object B to ask object A to tell
it about the status change. This is somewhat crazy on a number of
levels. First off, if Object B already has a reference to Object A, it
can just ask it directly for its status - it doesn't need to say "hey,
transmit your state to me using a notification please!" That's just
adding a layer of message wrapping that just isn't needed. But worse,
it's polling. Object B is polling Object A for a status change.
Polling is bad, so don't do it. The very point of notifications is to
eliminate polling.
What I said before about passing 'self' is a vital clue. If you're not
passing 'self' to -postNotificationName:, you're doing it wrong.
Object A is fully and exclusively responsible for posting
notifications when it deems that something notifiably important has
occurred. Then B, C, Tom, Dick, etc all get the notification and do
with it what they will. At no point should B or anyone else be telling
A to send a notification. Doing so is wrong, plain and simple.
I believe that "KVO" stands for key-value-order .. so obviously I've
got a lot of digging to do, starting with Chapter #1, where ever
that is.
KVO stands for Key-Value Observation. Personally my advice would be to
get ordinary common-or-garden notifications straight before diving
into KVO. Ordinary notifications are very simple, straightforward and
have no hidden magic. As far as I can tell they will serve your needs
for the situation so far described, so I think you're on the right
track.
While KVO may also fit the bill, it's far, far trickier to get right,
and is very unforgiving of not using it exactly properly. I didn't
touch KVO until I'd been bashing away with Cocoa for about four years,
and even then it took me several false starts before it started
working for me instead of the other way around. Unlike ordinary
notifications, at first a lot of what KVO does does indeed seem like
magic - which in turn implies that you really have to know what you're
doing because debugging magic is very hard indeed.
KVO builds on KVC, so learn that first. Bindings builds on KVO.
Bindings is not for beginners - you really need to have at least the
theoretical side of KVC/KVO down pat before bindings will become clear.
hth,
Graham
_______________________________________________
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