Re: Crashing Problem calling postNotificationName
Re: Crashing Problem calling postNotificationName
- Subject: Re: Crashing Problem calling postNotificationName
- From: Kyle Sluder <email@hidden>
- Date: Thu, 12 Sep 2013 10:45:55 -0700
On Thu, Sep 12, 2013, at 10:18 AM, Dave wrote:
>
> On 12 Sep 2013, at 17:58, Kyle Sluder <email@hidden> wrote:
>
> > Whenever I see a suggestion like “subclass NSNotificationCenter”, I recoil in horror.
> >
> > First, NSNotificationCenter is a singleton. If you subclass it, you now must have two notification centers.
>
> It has the facility to have different Centers (default etc.), so it's not
> a true singleton, although I see what you mean. It doesn't have to be a
> subclass, just a class, but I think that either subclassing
> NSNotificationCenter or have a Category on it is better than having an
> anonymous object that calls [NSNotificationCenter defaultCenter], since
> at least it keeps all the notification code in one place.
I'm not really sure what you're talking about with "anonymous object
that calls +defaultCenter." Every NSNotificationCenter call site gets a
reference to the notification center by calling the class method.
>
> > Which one is the right one to subscribe to? Do you only move notifications over to it that need to be cached? Or all related notifications as well?
>
>
> That problem exists anyway, you have to know it's the default center for
> instance. This is just using related ones by virtue of the fact that the
> rest of the code doesn't use the subclass, only those that need to.
If you only ever use the default center, you never have to worry about
which notification center to listen to.
There is a very large gulf in software design between "one" and "many."
Every time you want to cross that gulf you have to make decisions. More
decisions lead to more bugs.
>
> > This decision needs to be made on both ends of the notification.
>
> No, just at the receiver, the sender need do nothing, in fact its
> unchanged.
How? You need to update the sender to send to the correct notification
center.
>
> > Congratulations, you have taken an object whose purpose is to promote loose coupling, and successfully turned it into a tool that tightly couples the sender and the listener.
> >
> > The correct approach does not put the cache in the notification center, but rather in the sender or the userInfo dictionary.
> >
> > --Kyle Sluder
>
> This is just not true! It's the opposite as far as I can see. If I hold
> the the data at the sender then from the receiver I have to "know" who
> sent the Notification in order to retrieve it,
You already know that information. It's in the object property of the
NSNotification object.
> also, there is more than
> one sender for the notification, so I would have add more code specific
> to a number of objects.
Then put it in the userInfo. That's what it's there for.
> This way the receiver is coupled to the subclass
No it's not.
> which is not a lot different that the base class, and it could be coupled
> to that anyway, so I don't see the problem.
>
> it works like a treat and is really easy to adapt so I'd say the proof is
> in the pudding!
And when you're scratching your head wondering why you're not getting
notifications delivered to your objects, because they're being sent to a
different notification center than the one you're listening to…
Either that or I'm sorely misunderstand how you propose to use
subclasses of NSNotificationCenter.
--Kyle Sluder
_______________________________________________
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