Re: Crashing Problem calling postNotificationName
Re: Crashing Problem calling postNotificationName
- Subject: Re: Crashing Problem calling postNotificationName
- From: Etienne Samson <email@hidden>
- Date: Thu, 12 Sep 2013 11:17:26 +0200
Le 12 sept. 2013 à 10:54, Graham Cox <email@hidden> a écrit :
> On 11/09/2013, at 5:33 PM, Etienne Samson <email@hidden> wrote:
>
>> I think the best way for what you're trying to do is to subclass NSNotificationCenter (or at least provide your own framework-wide singleton that quacks like it), wrap -postNotification: with some dictionary-munging code that keeps tracks of the last notification send by notification name, and have -addObserver:… (you'll have to find the one that actually is the designated call, the one all the others expect) check that cache and issue a -postNotification: call for that object only (you don't want to notify all old objects, only the one that just registered).
>
>
> I'd disagree with this - subclassing something like NSNotificationCenter is a sledgehammer to crack a nut, and don't forget about the potential side effects where it is used for lots of other unrelated notifications.
>
> Why not just have a class method on the sender of the notification that stores the most recent data sent by an instance of that class? Then when a new instance of the notification receiver is inited, it can grab the latest data from the class method to set itself up? No hacks required.
If there's 26 different objects that need that "cache" capacity, that's 26 class methods — less if they happen to have a common ancestor, but I don't think the OP was having one. Also, IMHO that looses the loose coupling that exists when using notifications : your new receiver has to know which object(s) send which notifications to query for them (and if there are actually more than one, you now have to remember which is the "latest" one).
I might be wrong, but having that cache code centralized in one place with a well-known interface also allows the caller to either choose the caching notification center or the normal one (provided the caching one manages it's own singleton), and the rest of the code can change on-the-fly. If subclassing the NSNotificationCenter feels too heavyweight, create a Notification Cache object that observes all the wanted notifications in the framework and that the objects can call to get the latest value from.
Personally, I'd go the subclass route, because of the code-swappable capacity. But you're right that you better debug it well ;-).
Regards,
Etienne Samson
--
email@hidden
_______________________________________________
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