Since calling [[NSUserDefaults standardUserDefaults] synchronize] doesn't cause
bindings to be triggered, I took a brute force approach and used a privately
created NSUserDefaultsController, made it a property of my app delegate, and
let my bindings use it as part of the key path. When my client app receives the
signal that preferences have been edited, it creates a new
NSUserDefaultsController and overwrites the old one:
DebugLog( @"goosing defaults bindings" );
self.defaultsController = [[[NSUserDefaultsController alloc]
initWithDefaults:[NSUserDefaults standardUserDefaults] initialValues:
self.initialDefaults] autorelease];
This works, but it seems really primitive. Is it really the case that there's
NO way to tell NSUserDefaultsController that the underlying NSUserDefaults
store has changed? Really? Seems like a serious oversight to me.
Anyway, problem (sort of, and in an ugly manner) solved for anybody searching
the list.
--
shamyl zakariya
- so much for pathos
On Jul 15, 2010, at 8:19 AM, Shamyl Zakariya wrote:
> I have written a dummy app which uses the CFPreferences API to write
> to the headless app's domain, and uses NSDistributedNotificationCenter
> to broadcast an update message. The headless app receives that update
> message, and calls synchronize on its standardUserDefaults instance.
>
> However, this doesn't trigger the NSUserDefaultsController's bindings to
> update.
>
> If I manually examine the defaults values, I see the newly set values,
> which is great. But I can't figure out how to get the
> NSUserDefaultsController to notice that the defaults have changed and
> to accordingly cause bound values to update.
>
> Any ideas?
>
> On Wed, Jul 14, 2010 at 3:21 PM, Shamyl Zakariya <sha...@gmail.com> wrote:
>>> Yes. The app that writes the pref should call synchronize and send its
>>> signal, then the app that reads calls synchronize when it receives it. I
>>> have a pair of apps that do that; I use NSDistributedNotificationCenter and
>>> the CF equivalent CFNotificationCenterGetDistributedCenter for the signals.
>>
>> That sounds quite elegant, thanks!
>>
>>
>> --
>>
>> shamyl zakariya
>> - so much for pathos
>>
>>
>>
>> On Jul 14, 2010, at 3:03 PM, Lee Ann Rucker wrote:
>>
>>>
>>> On Jul 14, 2010, at 9:20 AM, Greg Guerin wrote:
>>>
>>>> Shamyl Zakariya wrote:
>>>>
>>>>
>>>>> If not, what's the best practice here? And if I were to use some
>>>>> sort of apple event fired from the prefpane or some other technique
>>>>> to let the app know its defaults have changed, how do I get the
>>>>> user defaults controller in the headless app to apply the updates?
>>>>
>>>>
>>>> If I understand the question correctly, then when the signal is
>>>> received, your headless app calls -synchronize on the
>>>> NSUserDefaults. This assumes you don't have any shared-access
>>>> contention issues.
>>>
>>> Yes. The app that writes the pref should call synchronize and send its
>>> signal, then the app that reads calls synchronize when it receives it. I
>>> have a pair of apps that do that; I use NSDistributedNotificationCenter and
>>> the CF equivalent CFNotificationCenterGetDistributedCenter for the signals.
>>> _______________________________________________
>>>
>>> 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:
>>> http://lists.apple.com/mailman/options/cocoa-dev/shamyl%40gmail.com
>>>
>>> This email sent to sha...@gmail.com
>>
>>
>
>
>
> --
> so much for pathos
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
