addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwchatcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-crosscrosseditemptyheartfacebookfolderfullheartglobegmailgoogleimagesinstagramlinklocation-pinmagnifying-glassmailminusmoremuplabelShape 3 + Rectangle 1outlookpersonplusprice-ribbonImported LayersImported LayersImported Layersshieldstartrashtriangle-downtriangle-uptwitteruseryahoo

Denver iOS Developer User Group Message Board › NSUserDefaults Search List Anomaly

NSUserDefaults Search List Anomaly

Kevin W.
user 3005027
Lafayette, CO
Post #: 6
I have what may seem like an esoteric question, but I'm writing about NSUserDefaults, so it's important that I get the right answer. The Apple documentation states that using -init or -initWithUser: initializes an instance with an *empty* search list, whereas using the shared instance obtained with +standardUserDefaults populates the search list on the first call.

So what are the actual consequences of having an NSUserDefaults instance with an empty search list? In all my experimentation so far, it makes no difference. Looking up a default using -objectForKey: (or any other value access method) behaves as if the search list *is* populated, even when the instance was initialized with -init*. The same is true when using -dictionaryRepresentation. The documentation for both methods says they only report defaults in the domain search list. See example below:

NSUserDefaults *defaults = [[NSUserDefaults alloc] init];
// NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
NSLog(@"%@", [defaults dictionaryRepresentation]);

NSLog(@"%@", [defaults objectForKey:@"­ing"]);
[defaults setObject:@1 forKey:@""­]; // should set the value in the app domain
NSLog(@"%@", [defaults objectForKey:@"­ing"]);

This produces a full dictionary representation of defaults (but it shouldn't find any since they are not supposed to be in the search list), followed by:


So the value in the NSGlobalDomain is overridden by the value in the application domain, which is exactly what you would expect if there is a search list. Without one, I I would imagine I should just get back a nil value on both -objectForKey: calls, but of course that's not what happens. On top of all this, Apple seems to have removed the searchList and setSearchList: methods that were available on the original OpenStep spec, so I can't even verify the contents of the search list directly. *sigh*

So what's really going on here?

- Kevin
Matt R.
user 11460722
Denver, CO
Post #: 1
Hey Kevin,
I can post up some more info later today or tomorrow but I had a similar issue recently, this article helped. I know this seems a little off topic but in my case part of the issue was I was not syncing the defaults.

[default synchronize];

In theory you will take a slight performance hit by forcing the sync but its very slight.
Good luck!
Kevin W.
user 3005027
Lafayette, CO
Post #: 8
Thanks Matt. Calling synchronize doesn't seem to make a difference either. Technically speaking there is no "problem", except that a custom-initialized defaults object actually works *better* than expected, contrary to the documentation. :-)
Powered by mvnForum

Our Sponsors

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy