Re: Notifications or singletons?
Re: Notifications or singletons?
- Subject: Re: Notifications or singletons?
- From: Alexander Reichstadt <email@hidden>
- Date: Sun, 6 Apr 2003 18:43:10 -0700
Hi, I had this idea too, but ran into problems soon afterwards. That
doesn't need to happen, but in either case there are two concepts you
can deploy for messaging between objects,. notifications and nil
delegates. I'll show you both.
1st as to notifications it's obvious that you have a sender and a
receiver, and some notification-center, which works like a telephone
call center taking and passing on messages.
In detail you do this...
on receiving end:
Preferable at initialization, so in the init method of your class you
do something like this
//Register with the default notification center
//That's like telling your boss that you are now ready to take new
assignments
NSDistributedNotificationCenter *center =
[NSDistributedNotificationCenter defaultCenter];
//Now tell your boss what type f assignments you are able to do
[center addObserver:self
selector:@selector(someIBActionAndImplementInMyClassToExecuteUponReceive
OfNotification:)
name: @"SomeNotifiationNameiImagined"
object: nil];
//Now tell your boss what type of assignments you are ready to take
on
[center addObserver: self
selector:@selector(doSomethingElse:)
name: @"AnotherOneIThoughtOf"
object: nil];
What you do there is in some sense logging in to the system facilities
provided to handle messaging namely the notification center, and then
say that upon receive of some notification "abc" you will execute some
method "xyz". Furthermore addObserver determines who will receive and
deal with the notification, thus you can also have your friend tell
your boss that you are ready to take on some specific assignments.
Now, on the sending end:
From where ever you want to fire a notification you go about it like
this:
[[NSDistributedNotificationCenter defaultCenter]
postNotificationName:@"SomeNotifiationNameiImagined" object:nil];
First you initialize the notification center and get a hold of some
shared instance using the defaultCenter method, then you post a
notification to it.
As you will notice I drag around some object:nil all the time, you can
put stuff in there, you don't have to though.
Last, as one example for the methods you execute that before you have
said to run in response to receiving a notification:
-(IBAction)
someIBActionAndImplementInMyClassToExecuteUponReceiveOfNotification:(id)
sender
{
NSLog(@"Yay, signal arrived");
}
So much about notifications.
2nd as to nil-delegates do this:
Go to InterfaceBuilder and double-click on the instance "First
Responder" that you will see in your nib's document-window. Then the
inspector should come up with the actions-outlets-tab.
Add an action there and give it the name that from the
notification-descriptions above would otherwise have executed in
response to a notification.
Now, from your menu item ctrl-drag to the "First Responder" icon in the
nib's document window. You can now connect it to the IBAction that you
have previously added. What that does for you is say
[nil sendMyMessage:(id)anObject];
What's so cool is that this way any message will be passed on down the
chain until the point where it is intercepted by some object and dealt
with. If after that point the message is supposed to be dealt with by
someone else, you must resend it, just like one of these silly "send me
to ten of your friends emails or you get bad luck"; and here you really
get bad luck if you don't.
So, if in the nib where you have done all this you have some MyClass
defined, you can have MyClass respond to this method; but you could
also have some other class respond to it, as far as it is part of the
responder chain which should be the case if things are setup fine.
You see that you have two case again, one, in which to the receiver
there is the direct user action, something like a mouse-up event that
you want the receiver to deal with directly, and then you have cases in
which your receiver doesn't deal with the user-action directly but has
some other object put between, so a button that receives the actual
mouse-up event and does its own standard-mojo to get things moving to
the receiver. In this latter case nil-delegates are preferable over
notifications. It doesn't matter what the nitty gritty is but for
discrimination this is an easy way to differ between what's applicable.
Have a look at the reference, this code may not apply to your needs as
the optimum you could have and you don't wanna waste anything.
Hope that helped
Alex
On Sunday, April 6, 2003, at 04:12 PM, Andrew Merenbach wrote:
>
I'm working upon a small address-book-like application that maintains
>
a list of contacts and associated data. When a contact's name is
>
double-clicked in the main list, a new window opens with more detailed
>
information. I currently do this via a singleton: the detail window
>
has a shared instance that my master list calls, with the
>
currently-selected contact as an argument, and the contact window
>
controller loads the contact's information. Would this be better done
>
through notifications?
>
>
Take care,
>
Andrew
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.