Re: observeValueForKeyPath called twice when changing NSUserDefaults value
Re: observeValueForKeyPath called twice when changing NSUserDefaults value
- Subject: Re: observeValueForKeyPath called twice when changing NSUserDefaults value
- From: Quincey Morris <email@hidden>
- Date: Sun, 13 Nov 2016 15:43:06 -0800
- Feedback-id: 167118m:167118agrif8a:167118sYHtXHasMg:SMTPCORP
On Nov 13, 2016, at 14:44 , Steve Mills <email@hidden> 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 (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