When I'm setting up the default preferences for my app, I'm doing the following:
1) Reading Root.plist from inside Settings.bundle into a dictionary.
2) I test if a preference is set, and if not I'm registering my defaults dictionary via [NSUserDefaults standardUserDefaults] registerDefaults:]
Problem is, defaults registered with registerDefaults: do not go to the persistent store, so if the user never changes their preferences I am reading my default preferences and registering them with NSUserDefaults every time the app launches.
Instead of using registerDefaults: I could use setValue:forKey: and have my default setting go to the persistent store, bypassing the need to build & register a dictionary on each launch. However, Apple's documentation and sample code both point to registerDefaults:.
So I'm trying to figure out when and why I should use registerDefaults: and when/why I should use setValue:forKey: instead?
Problem is, defaults registered with registerDefaults: do not go to the persistent store, so if the user never changes their preferences I am reading my default preferences and registering them with NSUserDefaults every time the app launches.
Yes. Why is that a problem? Why write to disk things you have in the code already?
Instead of using registerDefaults: I could use setValue:forKey: and have my default setting go to the persistent store, bypassing the need to build & register a dictionary on each launch. However, Apple's documentation and sample code both point to registerDefaults:.
Only if you first checked "is this value set? No? OK, now set it." That's more code and cost than just using registerDefaults:.
You should use registerDefaults: to set the defaults. You should use setValue:forKey: to save values that are actively set.
Remember also that NSUserDefaults exists on Mac as well. There, the user can directly access the settings with the defaults command, so the program is not the only entity that can modify this store.
Related
I'm using NSUserDefaults in my iOS app to record some specific info about the user's receipt state.
I'd like to confirm:
If the user quits the app, will those defaults remain?
Are they global, for example I'm currently using the following line to either get or set them and across different methods. I just want to be certain the data within it persists - so if I set in method1 then later method2 I use the same line to get, it will have whatever I set in method1:
NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
If the user quits the app, will those defaults remain?
Yes, they are persistent.
Are they global?
Global in the sense of your whole app: Yes.
Global in the sense of across apps: No. They are in the app's sandbox.
From the NSUserDefaults documentation (see https://developer.apple.com/documentation/foundation/nsuserdefaults?language=objc)
With the exception of managed devices in educational institutions, a user’s defaults are stored locally on a single device, and persisted for backup and restore. To synchronize preferences and other data across a user’s connected devices, use NSUbiquitousKeyValueStore instead.
So for your first question the answer is yes.
Accordind to your second question, doc says:
At runtime, you use NSUserDefaults objects to read the defaults that your app uses from a user’s defaults database. NSUserDefaults caches the information to avoid having to open the user’s defaults database each time you need a default value. When you set a default value, it’s changed synchronously within your process, and asynchronously to persistent storage and other processes.
And even so, it declares that the class is thread safe, so you can be sure about persistent results (for your second answer).
Additionally with #Nikolai Ruhe answer.
if I set in method1 then later method2 I use the same line to get, it will have whatever I set in method1: NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
The UserDefaults class is thread-safe.
Two further points.
The uselessness of synchronize has grown up gradually through versions of iOS. It used to be essential; then advisable; then unnecessary. I can’t give you an exact timeline but a lot of it depends on how far back in iOS you want your app to work.
If you try to test some of these things in Xcode, beware. Up to and including iOS 11, synchronize does not write all the way to disk, but only puts data in a “lazy write” queue. Pressing the Stop button in Xcode (or pressing Run and allowing Xcode to stop the previous running app automatically) shuts everything down abruptly, more abruptly than anything a user can do, and the lazy writes are not written out, but lost. This is confusing while you are resting!! I filed a report on it and was told by Apple that (as Microfot would put it) “This behaviour is by design”.
But just to be clear: that second point does not present a problem for real apps in a real environment, only when you are trying to test “save and restart” scenarios. Waiting 5-10 seconds seems to be long enough for the flushed data to make it all the way to disk.
I want to check whether or not my application was previously installed on a particular device. Is there any programmatic way to do so?
You can use keychain. but when user reset his/her phone this value will be lost .
I think there is no option is available to such case except you have to use iAd in your app. apple provide unique id for that that will remain constant after reinstall application.
OPTION #1:
You can use NSUserDefaults or save the flag to keychain, in order to not lose it after app uninstall, and check in application:didFinishLaunchingWithOptions: method:
BOOL installFlag = get it from user defaults or keychain;
if (installFlag)
{
//App was installed
}
else
{
//This is the first install ever
installFlag = YES;
//Here save the YES value to user defaults or keychain
}
If you will save the flag to keychain, then use a Keychain Wrapper, like this
one.
The weak part of this option is that even if keeping the flag in keychain, the value could be lost, after reseting device settings, that's why I would prefer the following option:
OPTION #2:
Keep the flag remotely on a server database, as a key you can use device identifier:
NSString *uniqueIdentifier = [[[UIDevice currentDevice] identifierForVendor] UUIDString];
And you will have to check, if there is a record in your database with current device identifier, then app was already installed, if no then add the flag and the identifier to the database. (But you will need internet connection every time).
You can use keychain to keep log of your app previously installed or not.
I use [NSUserDefaults standardDefaults] to store a boolean to see if it is the first time that application is being launched ... If so, the app should show a registration window.
It was working fine till last week, but now, sometimes when I switch to other apps and come back after a little while, I see that registration page loads while it shouldn't.
I used NSLog to see what is stored in [NSUserDefaults standardDefaults] and I see that the values I stored has been set to nil (null) while I haven't done that anywhere in my code.
Does anyone know why the values do reset ?
P.S: Actually the values are not permanently lost , because if I don't do anything in registration page and quit the app instead, It will launch normally the next time I enter the app !!!
A long time ago I encountered this issue, turns out a third party library that I was using uses the same key when storing values to NSUserDefaults. Try searching your project for this key, maybe something else is resetting it.
Here are the ways I know about to lose values in NSUserDefaults, in order of likelihood:
The key was never saved in the first place
Your app deletes it later on
The app is deleted and reinstalled
Another app overwrites or removes the key
The phone or simulator is reset
During the night, the phone is replaced by an identical-looking, different phone
It sounds like, from the discussion here, that you've ruled out 1,2,4, and probably 3 & 5. The only next debug step I can think of is to store the test phone in a locked drawer at all times.
But I'd leave my money on an intermittent problem causing #1. For that, we'd need posted code to investigate.
EDIT -
A high % of NSUserDefaults problems posted here are about storing BOOLs and other scalar types. It looks like the OP knows about wrapping in NSNumbers, but BOOLS in particular are fraught because it's easy to confuse false-y values like NO no and nil, and NSNull instance.
Let's throw that on the list for this question at #2.5. There again, would need code to confirm.
If this is happening while testing, it's normal. The fact that the program is even making this decision (should I show the registration page?) suggests that the app has been forcibly quit and is starting from scratch. When testing, this can result in clearing out the app sandbox as the app is reloaded from Xcode. In the real life of a real user, however, that won't happen (unless the user deletes the app from the device).
Make sure you are calling [[NSUserDefaults standardUserDefaults] synchronize] just after setting preferences and you are not overwriting you preferences.
I would like the determine if I have access to files that have been saved with the attribute NSFileProtectionKey = NSFileProtectionCompleteUntilFirstUserAuthentication.
I have tried [UIApplication sharedApplication].protectedDataAvailable, however from my tests it will return NO whenever the device is locked (if a pin code is set) even if the user has unlocked the device at least once since last starting the phone.
It says quite clearly in the docs: The value of this property is NO if data protection is enabled and the device is currently locked, and in this case files that were assigned the NSFileProtectionComplete or NSFileProtectionCompleteUnlessOpen protection key cannot be read or written by your app. i.e. this is not the correct property.
You need use one of the multi-tasking keys that causes the launch the app on boot - e.g. the voip key for UIBackgroundModes.
Mind you, you're pretty much testing the OS at that point - if you set the keys appropriately when creating the files it should work as advertised. If it doesn't then log a radar.
In iOS4, when I save NSUserDefaults, the information gets saved. But then, if the application becomes inactive, and I kill the application (by double clicking the home button and then terminating the app), and launch the application again, the NSUserDefaults are not read.
Now, is this the default behaviour of NSUserDefaults that if the app is terminated due to any of the issues, the next launch will not store the information?
The call I am using to persist the info is:-
[[NSUserDefaults standardUserDefaults] registerDefaults:
[NSDictionary dictionaryWithObjectsAndKeys:
"Some date", #"Validity",
nil]];
after you register defaults add this
[[NSUserDefaults standardUserDefaults] synchronize];
until you synchoronize, the standardUserDefaults gives current/correct values as long as the app is alive.
once the app is terminated, since you didn't sync the standardUserDefaults, the app will read the unsynced values on the next launch.
Example: Think of it like a google doc that you are editing.
the AutoSave feature of google document is equivalent to the nsuserdefaults synchornize. If you close the browser before the changes you made to the document has been autosaved, the next time you load it up, you'll see the old content.
The call you mention to persist the user defaults, registerDefaults, does not actually persist anything to disk. What registerDefaults does is initialize the defaults to use for the application if it can't find any on the disk. You should do this on each application launch, typically in the initialize method for the app delegate.
Once your application is running it will typically modify the user defaults. Whenever you want to save these modified defaults to the disk you should call:
[[NSUserDefaults standardUserDefaults] synchronize];
After the defaults have been saved they will be loaded automatically on any subsequent application launches.