NSNotification addObserver: someOtherClass

Question

I need to pass the message to the control class (which creates an instance of the class that will send the message). Thus, I cannot directly refer to the class name in my file without making it global (which is ridiculous to do if NSNotification advertises the ability to send all kinds of messages no matter where / who they are.

So, without further ado ...

(call from Say ClassB)

ClassA instantiates class B

Now in ClassB I need to send messages regarding button presses to ClassA

 (insdie ClassB) - (void)viewDidLoad { [[NSNotificationCenter defaultCenter] addObserver:ClassA selector:@selector(doLoginAction) name:@"SomeButton" object:nil]; [super viewDidLoad]; } 

This will NOT compile even if I include, sorry, "#import "ClassA.h" Now, if I do something stupid,

 ClassA *classa = [[ClassA alloc]init]; 

and then use this newly created class instance in addObserver:classa , it will compile, but I thought it won’t do anything ... (I knew this, but, surprisingly, such code is common in Iphone programming books ...) So I tried anyway.

But if I put this function in ClassA and use addObserver:ClassB it will be called, but it will lead to a dump of the stack unrecognized selector sent to instance or use addObserver:self .

I am tempted to remove Xcode and return to vim and use the good old "C" answer ...

Answer 1

So, if I understood correctly, you have a ClassA that creates instances of ClassB . These instances, in turn, must send notifications directly to ClassA without knowing it.

If this is correct, then NSNotificationCenter is exactly what you need.

In the ClassA implementation, add an initialialize method, for example:

 @implementation ClassA + (void)initialize { [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(YourSelector:) name:@"YourNotificationName" object:nil]; } + (void)YourSelector:(NSNotification *)notification { NSDictionary *userInfo = [notification userInfo]; // ... } // ... @end 

Then ClassB instances should post their notifications using only its name:

 @implementation ClassB - (void)postNotification { NSDictionary *userInfo = ...; // may be nil [[NSNotificationCenter defaultCenter] postNotificationName:@"YourNotificationName" // the same name is used in the `addObserver` call // in the previous code snippet object:nil userInfo:userInfo]; } // ... @end 

To summarize, you don’t need to know anything about the notification recipient if you are using NSNotificationCenter. In fact, you can sign as many objects as you want to receive the same notification, and each of them will call the corresponding method (specified in addObserver ) after receiving the notification object.

Remember that in the case when you add an instance of the class as an observer, and not the class object itself, you must call the [[NSNotificationCenter defaultCenter] removeObserver:self] method on this dealloc instance.

Answer 2

I see a couple of problems here.

First you need to stop trying to use classes and instances interchangeably. As long as you do not have a reasonable mental model of what your classes and instances are, and for which they are responsible for the fact that you will have all sorts of confusion when you use this and OOP in general.

NSNotificationCenter allows NSNotificationCenter to register a specific instance of a class, a single object, as an observer of certain notifications. You must know and refer to the monitored object in order to register it as an observer.

Secondly, you need to think about what each of your classes is, and for this their created objects are responsible. What they need to know, what they do not need to know, and how they can communicate.

Suppose you create an ObjectA as an instance of ClassA and create an ObjectB that is an instance of ClassB . Now ObjectA knows ObjectB , after all A has just been created by B, so for A it's easy to get a reference to B. ObjectB doesn't know ObjectA ; B, but he doesn’t need to know by what object or even class this object was an instance. If you want ObjectB to ObjectB able to communicate with ObjectA , you have several options.

• Delegation: ObjectA sets the property to ObjectB to return to ObjectA , now B can directly send messages to A. Now your two objects are connected together, which can be useful and problematic.
• Notifications: ObjectB can send notifications, ObjectA can watch notifications. B does not need to know that A is watching these notifications, and A does not need to know that notifications originated with B (although this could). These objects are very loosely coupled, and you can change a lot about your application without realizing it.

It is important to note that if ObjectA is to listen to notifications, then it is the responsibility to add yourself as an observer. Since B does not know A, no way B can make A an observer. The creator could, since this object would have a reference to A, but children cannot, if they are not given some reference to A.

Looks like Alex jumped up with a great answer, so hopefully all of this will be helpful.