Re: NSNotification coalescing - which one gets through?
Re: NSNotification coalescing - which one gets through?
- Subject: Re: NSNotification coalescing - which one gets through?
- From: Jonathan Taylor <email@hidden>
- Date: Fri, 08 May 2015 10:07:41 +0100
Thanks for your replies Seth:
>> I am trying to work out whether there are any rules that define which of multiple NSNotifications combined using coalescing actually get through to the receivers, and preferably a way of controlling that behaviour. This becomes relevant if for example there is different UserInfo associated with each object. I can’t find any specific statement about what the behaviour is under these circumstances.
>
> My interpretation of the API is that user info should either be consistent or not used in coalescing scenarios, though the documentation never discusses this.
Hmm, that's a good point.
>> Actually I think I may have answered my own question: calling dequeueNotificationsMatching immediately before posting a new notification seems to do the trick. This seems like a reasonable and logical way of achieving what I want. Can anyone see any problem with doing that?
>
> Nope. Seems fine to me.
On further consideration I do wonder, in a case where some notifications were treated in this way and other different notifications weren't, whether the ones I did treat this way would end up effectively being treated as *even* lower priority than the ones that weren't (by constantly being relegated to the back of the event queue). Shouldn't be a problem in my case though, as I am going to treat all coalesced+postWhenIdle events the same way.
> The other way to accomplish is this is to have the data stored outside of the notification and accessible to the receivers, and just let the notifications coalesce as normal. Instead of looking in userInfo, the receivers would go pull the data from the other source. But whether that's a better fit is questionable based on circumstances.
Yes, in fact that's basically the setup I had previously, and wanted to move away from. Rightly or wrongly, I decided I would prefer to avoid having a whole load of state and properties whose sole purpose (as it turned out) was to be queried in response to notifications. That also felt like a slightly awkward compromise between a tightly coupled scenario using KVO and a weakly coupled scenario using notifications to classes that don't need to know anything about the originating class - I liked the idea of things being as decoupled as possible.
_______________________________________________
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