CODEWITHSUNDEEP
cocoa-touchcocoansnotificationcenter
benzado
benzado

Reputation: 84388

Is there any harm in creating a "private" instance of NSNotificationCenter?

I'm using notifications to provide two-way communication between a pair of objects, where object A makes a request but may get deallocated before object B responds.

NSNotificationCenter is perfect for this, as object A can simply add itself as an observer. When object B responds, it posts a notification, and if object A has disappeared, the notification is merely ignored.

Since the notification is only intended for object A, it would be practical to set up a private instance of NSNotificationCenter for these notifications, instead of posting them on the defaultCenter. The only disadvantage would be additional memory for the NSNotificationCenter instance, but a time savings when notifications are posted on either.

Am I missing anything?

Upvotes: 3

Views: 209

Answers (3)

Peter Hosey
Peter Hosey

Reputation: 96393

Nope. In Cocoa, AppKit's NSWorkspace does exactly this.

Upvotes: 3

futureelite7
futureelite7

Reputation: 11502

It does not matter, you can just use the default notification center, and have only object A / object B listen to each other. Just ask object A to remove itself from the notification center before deallocation to prevent EXC_BAD_ACCESS.

Upvotes: 0

zoul
zoul

Reputation: 104135

I think you can go both ways, there are no real (dis)advantages that I could think of. I usually have the notification center as an explicit dependency initialized to the shared center. That way you can isolate the notifications if you want to, but the object works out of the box:

@interface Observable : NSObject
@property(retain) NSNotificationCenter *radio;
@end

@implementation Observable
@synthesize radio;
- (id) init {
    [super init];
    [self setRadio:[NSNotificationCenter defaultCenter]];
    return self;
}
@end

The short answer is do as you please.

Upvotes: 2

Related Questions