Documentation is not clear on how to use NSUbiquitousKeyValueStore with edge cases.
If I want to set a value, I understand that I should set a value to both NSUserDefaults and NSUbiquitousKeyValueStore since iCloud could be disabled. However in my tests [NSUbiquitousKeyValueStore defaultStore] return a valid object even if iCloud is disabled (tested on Mac OS).
Also, to my understanding is that if iCloud is enabled, NSUbiquitousKeyValueStore's values are stored to disk (and available offline). What are the reason to use NSUserDefaults if you are sure that you have less than 64KB of data?
I am using
http://blog.mugunthkumar.com/coding/ios-code-mkicloudsync-sync-your-nsuserdefaults-to-icloud-with-a-single-line-of-code/
It is a simple class written by Mugunth Kumar (thanx !) that does the work for you... Unless you have special needs, add one line of code and it will do all the reading and writing to iCloud... all you need to do is read and write to NSUserDefaults as usual...
Edit:
Carful, if you remove an item from NSUserDefaults the code I linked to above will not remove the item from the cloud. Whenever you remove an item from NSUSerDefaults please do the same to NSUbiquitousKeyValueStore as So:
NSUbiquitousKeyValueStore* keyValueStore=[NSUbiquitousKeyValueStore defaultStore];
[keyValueStore removeObjectForKey: yourKey];
The Mugunth Kumar answer provided above works beautifully if you want to sync all of your NSUserDefaults!
However, it is an ALL or NOTHING approach. You can not pick or choose the defaults you wish to sync.
I found this Tutorial that may be of assistance if you are looking to be more picky.
I wrote a simple iOS category that can be used to save a value also into NSUbiquitousKeyValueStore while storing into NSUserDefalt.
hope this help:
https://github.com/RiccardoPaolillo/NSUserDefault-iCloud
Related
I'm working on a little SDK which has a configFile.plist file to store things like secret key.
Developer who implement this SDK in his app, and other users will download the app, they will be able to go into the app binary and change anything in the .plist file.
Is there any way to store this info without letting users modifing the parameters easily? I don't want users to have the ability to change the parametes in the .plist file.
Thanks in advance for any help!
When it comes to plist storage, it's easily accessible either way. Your best option is to provide a class file for configuration, and not a plist. Example below..
//Config.h
#define SHARED_SECRET #"2390849028349829384"
#define SOME_OTHER_VALUE 1
..and so on, this way, the class file is compiled with the App, and not visible to the user but accessible by the developer. Once you #import "Config.h", you can use SHARED_SECRET and SOME_OTHER_VALUE in place of the value itself within the code. If this suffices as a solution to your question, mark it as the answer. Hope it helps..
Keeping in mind that people are going to be able to see/change almost anything with the right tools, you can't prevent people from hacking this.
If the key is going to be different for each user of the SDK, then you might want to make it the Developer's responsibility and have them provide the private key to you using a delegate method. That will make it their problem, and it will make it easier for them to compile the key directly into code, which is going to be less obvious for the end-user to access.
I use iCloud to sync an user xml file between devices in my apps, with a UIDocument subclass, similar to the code from the question:http://stackoverflow.com/questions/7795629/icloud-basics-and-code-sample. but I am not sure when and how should I detect a conflict. I read the sdk doc and searched the internet but didn't seem to find any information with detailed information. it seems we can use some code like
NSNumber* conflicted ;
[url getResourceValue:&conflicted forKey:NSURLUbiquitousItemHasUnresolvedConflictsKey error:nil];
but in my app, it seems always give a true value for "conflicted"?
also I am not sure when should I detect the conflict, my guess is before the contentsForType method of the UIDocument subclass is called. if anyone can give any hint that would be great.
You should observe the UIDocumentStateChangedNotification. If the documentState property of your document has the UIDocumentStateInConflict flag set, there is a conflict. Note that a document can be in multiple states simultaneously, so don't check with ==, instead use something like if (document.state & UIDocumentStateInConflict) {....
You can then get the conflicting versions with the otherVersionsOfItemAtURL: class method of NSFileVersion.
You can find more detailed information in the chapter on resolving document conflicts in the Document-Based App Programming Guide for iOS.
I have been trying very unsuccessfully to create a simple UIManagedDocument library style application (separate documents saved to iCloud).
I am confused with the following:
Do I subclass UIManagedDocument and set up the persistentStoreCoordinator, ManagedObjectModel & ManagedObjectContext within this subclass, or are these supposed to be configured within the AppDelegate (and if so, how do I go about refreshing the persistentStoreCoordinator to look at the new file - it seems that once that has read a persistentStore that I can't get it to read a new persistent store)?
Richard's example is an excellent example. I used it and the PragmaProg book on core data http://pragprog.com/book/mzcd2/core-data as a guide for creating my managed document module on github.
See: https://github.com/dtrotzjr/APManagedDocument
My code makes use of iOS 7 iCloud Core Data behavior which I cannot comment on publicly until the NDA is lifted. Feel free to ping me directly if you have any questions.
I've just posted a project based on Rick Warren's example: MultiDocumentPlusUUID. In his "Syncing Multiple Core Data Documents Using iCloud" post, Rick writes:
Another bug often shows up when I start trying to pass changes back and forth between devices that both have the same file open. The first sync always seems to work--and it seems to work pretty well as long as each subsequent sync is in the same direction.
MultiDocumentPlusUUID compiles and runs on iOS 7.1b4, and can ping-pong updates to a given document successfully.
I have an iPhone app that stores some settings using NSUserDefault standardUserDefaults.
When I add new features to the app I need to add new default settings and so I have to migrate/upgrade the NSUserDefaults. For now, I just store the version number and check this when the app is launched. It has quickly become very messy as I have to add lots of if statements. I cannot assume that the user is just upgrading from the previous version but perhaps even a couple of versions before.
I like the way that CoreData seems to handle migrating table changes but I want to provide 2.2.1 SDK compatibility and of course CoreData is not the same thing as NSUserDefaults.
Any suggestions or best practices?
Hmm… I wouldn't "upgrade" the user defaults in this way, but instead query NSUserDefaults as usual, only if the default isn't set (objectForKey will return nil in that case), use a default value (which may then be written back to the user defaults to save time the next time). Since you'll have to do this every time a "new" default (i.e. one that didn't exist in 1.0) is read, I advise doing a wrapper class/file that does this, this way the code is written only once for each "new" default.
Also, while the question/problem is different, this answer works just as well in your case.
I'm working on a localized app and everything is working fine. The problem is I want to allow the user to specifically select the lenguage for the specific app, in the app settings folder. This should users that their phone is set to one language (e.g. french) to set the app to work in English.
I'm currently using NSLocalizedString to get localized string but looking through all variation of the macro I can't find one that will let me specify the language.
Any ideas on how to do it?
There are three issues here:
Strings
Other resources (including NIBs)
System messages
The last is almost certainly not fixable, so we will leave it be. They're going to show up in the device language.
The other two are solvable, but you will need to do more things by hand. For strings, instead of creating a single Localizable.strings and then localizing it, create completely separate tables (English.strings, French.strings, etc.) Then, use NSLocalizedStringFromTable(), passing the language as the table.
For NIBs, there are two approaches. You can put each set of localized NIBs into its own Bundle and then pass that Bundle rather than nil to -initWithNibName:bundle:. Alternately, you can hand-load the NIBs after finding them with [NSBundle -pathForResource:ofType:inDirectory:forLocalization:].
There is a better way to do this. You can force the language like so:
[[NSUserDefaults standardUserDefaults] setObject: [NSArray arrayWithObjects:#"en", nil] forKey:#"AppleLanguages"];
And undo this setting by:
[[NSUserDefaults standardUserDefaults] removeObjectForKey:#"AppleLanguages"];
NB. you will normally have to restart the app for this to take affect.
Consider if you need to call [[NSUserDefaults standardUserDefaults] synchronize];
I agree there is little need to allow the user to specify a language. However the one exception is being able to override the language and set it to the developer's native language. If the user can speak the developer's language (e.g. English for me) then they may wish to use the App in that language, if the translations are incorrect.
I reference this answer: How to force NSLocalizedString to use a specific language (the answer doesn't actually work for me, but following the ideas in the comments did. The undo stuff I worked out.
The trick to use specific language by selecting it from the app is to force the NSLocalizedString to use specific bundle depending on the selected language ,
here is the post i have written for this http://learning-ios.blogspot.com/2011/04/advance-localization-in-ios-apps.html
and here is the code of one sample app https://github.com/object2dot0/Advance-Localization-in-ios-apps
The correct "User experience" is for the user to select their language via the system preference panel; not your app (or your app's settings panel, etc.). There is no way to override this per-app and we wouldn't want any app changing the system wide setting.