On Nov 13, 2016, at 14:44 , Steve Mills <sjmi...@mac.com> wrote: > > NSUserDefaults can be observed using Key-Value Observing for any key stored > in it.
OK, it’s documented in the header file. > Suggesting that the old/new values in the change dict shouldn't be used is > kinda silly. Why waste the bandwidth sending them if they're never going to > be used? In fact, the bandwidth isn’t always wasted by sending them. There are known cases where incomplete information is sent. That’s one reason why you might avoid relying on those values. Another reason is that religiously tracking the old and new values (and updating a UI that reflects the information, presumably) is itself wasteful, because the “new” value may well be older than the current value, and the “old” value may well be newer than the last time the UI was updated. Sending multiple updates to the UI — in typical cases — is more wasteful and more disruptive than coalescing changes. There *are* some use-cases for the old and new values: — When accessing the provider of the new value is expensive, or keeping a copy of the old value is undesirable. — When it’s actually important to track the sequence of changes, although for larger reasons you really need to be in control of both ends of the notification for this to be reliable. — When you want to track element-by-element changes to a collection, so that you can localize UI updates to specific elements, without disturbing elements that haven’t changed (e.g. to avoid having to save and restore the selection status of unchanged elements in a table view). but none of them seem to apply in the scenario you described. > I'm writing up a bug. To restate the obvious, there’s no API contract anywhere (that I can recall seeing) about uniqueness of notifications. It’s not a violation of any API contract for you to get redundant or multiple notifications. It just seems … unlikely to be intentional. Submitting a bug report is like the right way to find out. _______________________________________________ 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
