We don’t use NSUserDefaults in the app. Instead we have an NSMutableDictionary
that holds the settings, and we write them to a file when they change. We read
them in at app startup.
That allows us to actually have different settings for various items (these are
USB devices like mice and keyboard
And if you want a nice simple HMAC256 encoding class to make the results
securer if you want, I’ll happily toss one your way.
> On Apr 4, 2021, at 2:22 PM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
>
>>
>> It appears you are trying to get NSUserDefaults to do something that Apple
>> doesn?t
>
> It appears you are trying to get NSUserDefaults to do something that Apple
> doesn?t want it to do these days. Why not create your own defaults,
> writing the data to a dictionary that is then written to a file that you save
> in the ~/Library/Preferences folder, with a name of your choice?
> On Apr 4, 2021, at 10:11, Richard Charles via Cocoa-dev
> wrote:
>
> Why does Apple cache the defaults, what are the positive benefits? I have
> only ever been infuriated with this process during development.
For the same reason as any cache; speed and efficiency.
Steve via iPad
__
> On Apr 4, 2021, at 12:15 AM, Jack Brindle via Cocoa-dev
> wrote:
>
> This does work in Big Sur, we use it ourselves. The down side is that you
> don’t have the nice (and infuriating) caching of defaults that the system
> provides.
Why does Apple cache the defaults, what are the positive b
> On Apr 4, 2021, at 4:50 AM, Mike Abdullah wrote:
>
>> From the docs - init returns an initialized NSUserDefaults object whose
>> argument and registration domains are already set up. This method does not
>> put anything in the search list. Invoke it only if you’ve allocated your own
>> NSUs
> On 3 Apr 2021, at 16:34, Richard Charles via Cocoa-dev
> wrote:
>
>>
>> On Apr 3, 2021, at 8:59 AM, Gabriel Zachmann wrote:
>>
>> Thanks a lot for your response!
>>
>>> How about something like this?
>>>
>>> NSUserDefaults *monitor1 = [[NSUserDefaults alloc] init];
>>> [monitor1 set
