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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
