My [NSUserDefaults standardUserDefaults] are not being saved. Everytime I close the app and start it again, it reverts back. I don't have my iOS device handy so I am not sure if this will happen on device, but none of the other apps are doing this in simulator which leads me to believe there's something wrong with my code. I don't know what part of code I should include here, it's just simple add/modify keys in NSUserDefaults and as I said it runs fine during the app, but not after i restart it...
I know I can call synchronize but Apple advices against it and says I should only call it if it's a must... so.
What could be going wrong?
Your process is possibly terminated improperly so that NSUserDefaults do not have a chance to be stored. See also this and mostly this.
The suggestion in the second post I link to is to call synchronize in applicationDidEnterBackground:
Keep also in mind that terminating your app by stopping it in Xcode most often does not save user defaults.
Are you restarting from Xcode / debugger? Try sending the app to background with the Home button first. I think the framework synchronizes automatically then.
I could not understand about the way, you are accessing the NSUserDefault, The static function you used sharedDefaults with NSUserDefault does'nt exist in Apple Documentation
Use As below to access NSUserDefault
[NSUserDefaults standardUserDefaults];
For more read the blog post for using of NSUserDefault.
iPhone Programming Tutorial – Saving/Retrieving Data Using NSUserDefaults
Related
I am using NSUserDefaults in my app and I am unclear about how NSUserDefaults behave with regard to multi-tasking. Currently I create my NSUserDefaults from a settings.plist file in my project the first time the app is installed and launched. Successive app launches rely solely on NSUserDefaults.
Question: do NSUserDefaults persist even if the user discards the app icon from the multi-tasking dock. Note here I do not mean they have de-installed the app. Just removed it from multi-tasking.
Thanks,
Doug
NSUserDefaults will persist in that case as long as they have been synchronized using the synchronize method.
NSUserDefaults data does persist after the app has been removed from multitasking.
See link
https://stackoverflow.com/a/4771560/716216
Is the application domain in [NSUserDefaults standardUserDefaults] backed up when the user synchs their device? If not, can you suggest a close correct alternative?
Apple makes reference to "Application Preferences" in its documentation, such as regards in-app purchasing. I understand, perhaps incorrectly, that they're making reference to NSUserDefaults here although the terminology doesn't appear to match perfectly.
In-app purchases, which I plan to record in [NSUserDefaults standardUserDefaults], need to be backed up in my project.
Thanking you kindly in advance.
Yes. NSUserDefaults uses a PLIST file as a backing store, which is backed up on each sync. See http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/UserDefaults/Concepts/DefaultsDomains.html for more information.
If you wanted to see for yourself, you could check out ~/Library/Application Support/MobileSync/Backup/. Create an unencrypted backup of a device with just your app on it, and view the files in the PLIST editor.
My application uses NSUserDefaults to store some values so that it can restore them on application update or if backgrounding is quit. Backgrounding automatically saves my integer values, but if the user quits the application from the launcher, the numbers are lost too, and the ViewDidUnload method I guess doesn't evoke when entering backgrounding. Is there a way that I can save the NSUserDefaults any time the application unloads. Also, the ViewDidLoad method had the same problem, it doesn't evoke from backgrounding. What's a way around this?
P.S. So far the only data my application needs to save is an int for an on-screen count.
UPDATE: UIApplicationDidEnterBackgroundingNotification works great with your suggestions!
You can't save data right before it eventually gets killed, but you can save state 'just in case' in your applicationDidEnterBackground: app delegate.
There's also applicationDidBecomeActive:, but there's no reason to load your save data from there, since when it's invoked from an app that was in the background, the data will have been preserved any way.
You can't tell if your app was launched from the background or not, at least how it's currently set up, since your app delegate will get the same sequence of events if it's launched from springboard.
As Joost says, you should save anything you need to restore state inside the applicationDidEnterBackground callback; essentially, you should assume this is the last message your app will get before it gets killed mercilessly by an evil process reaper.
You should check out the WWDC 2010 Session Videos, specifically, Session 105 - Adopting Multitasking on iPhone OS, Part 1 for a thorough explanation.
I'm using [NSUserDefaults standardUserDefaults] for storing application settings.
My questions are:
do those settings are removed on app deletion?
are they kept after an application update (through the
AppStore)?
Because I'm using it to store a password and don't want my users to reset them at each update. Also, I'd like that the only way to reset the password would be to remove the app and re-install it.
Is NSUserDefault the right choice?
Thanks,
Jérémy
Yes, they are removed on app deletion and yes they are kept when an application is updated.
However, you're not advised to store sensitive data in the NSUserDefaults, instead I would look at using the Keychain.
I use NSUserDefaults in my app to allow additional access to my app for my colleagues. They just have to enter the code word in settings and the app is fully opened.
to the point each time I update the app they have to re-enter the code word, so I would say from experience that they are not kept after updates. The values need to be re-entered.
Is this the case? Do NSUserDefaults get reset when you submit an update to an app on the App Store, or are they reset?
My app is crashing when updated but not crashing when downloaded fully - so I'm trying to determine what could possibly be different in the updated session to the freshly downloaded session.
Cheers,
Nick.
They are usually not reset unless the user deletes the app. For basic data, NSUserDefaults is the best way to save data such as preferences, dates, strings etc. If you are looking to save images and files, the file system is a better bet.
I beleive the answer is YES, it will persist. This also fully documented under the Application Directory chapter in the Apple iPhone OS Programming Guide.
Direct answer to the posted question: YES.
Your problem:
Your app gets crashed due to logic issues. Suppose you store an object in defaults and the app checks it's value on launch (or elsewhere). In you update you could change the way it is checked or used, e.g. you expect a value, but the object is nil, or vice versa. This may cause a SIGABRT or EXC_BAD_ACCESS.
If you had CoreData model and you changed something in your model and update, without managing migration, thats probably reason why your app crashes on update...
I have a similar experience. Our app stores a version number in Settings.Bundle/Root.Plist. This gets displayed through the iPhone Settings app. What we find is that on an Install the version number gets loaded from the app bundle - therefore the version number is correct. On an update however the version number doesn't change. This gives the impression the user is running a previous version of the app. We don't have any logic linked to the version number, it's just for display (it could be used by contact centre staff when diagnosing faults).
Our experience is NSUserDefaults doesn't get cleared when a user updates our app, but the Settings display doesn't get updated either.
Be aware of this case, when your app is running in background and you cannot access your stored values in NSUserDefaults:
Eric:
There have been many threads and bugs about this, but it's happening to me again in ios 9. I have an app that launches in the background in response to NSURLSession tasks and content-available pushes. Reproducibly, if I reboot my phone and wait for a background launch of my app to happen, then when I open the app I find that [[NSUserDefaults standardUserDefaults] dictionaryRepresentation] contains all the system values, e.g. AppleITunesStoreItemKinds, etc. but does not contain any of the values I have set. If I force-quit and relaunch the app all of my values come back. Is there any way to avoid it caching the "empty" standardUserDefaults from before the phone is unlocked, or at least to determine when they are messed up and fix them without having to force-quit the app?
Eskimo (eskimo1#apple.com):
The problem here is that NSUserDefaults is ultimately backed by a file in your app’s container and your app’s container is subject to data protection. If you do nothing special then, on iOS 7 and later, your container uses NSFileProtectionCompleteUntilFirstUserAuthentication, a value that’s inherited by the NSUserDefaults backing store, and so you can’t access it prior to first unlock.
IMO the best way around this is to avoid NSUserDefaults for stuff that you rely on in code paths that can execute in the background. Instead store those settings in your own preferences file, one whose data protection you can explicitly manage (in this case that means ‘set to NSFileProtectionNone’).
There are two problems with NSUserDefaults in a data protection context:
Its a fully abstract API: the presence and location of its backing store is not considered part of that API, so you can’t explicitly manage its data protection.
Note On recent versions of OS X NSUserDefaults is managed by a daemon and folks who try to manipulate its backing store directly have run into problems. It’s easy to imagine the same sort of thing coming to iOS at some point.
Even if changing the data protection were possible, NSUserDefaults has no mechanism to classify data based on the context in which you’re using it; it’s an ‘all or nothing’ API. In your case you don’t want to remove protection from all of your user defaults, just those that you need to access in the background before first unlock.
Finally, if any of this data is truly sensitive, you should put it in the keychain. Notably, the keychain does have the ability to set data protection on an item-by-item basis.
Source:
https://webcache.googleusercontent.com/search?q=cache:sR9eZNHpZtwJ:https://forums.developer.apple.com/thread/15685