On Feb 4, 2012, at 7:40 PM, Martin Hewitson wrote: > Dear list, > > I'm wondering about whether or not an app that uses iCloud to sync a > core-data store (shoe-box app) should have a user preference to disable > syncing. Suppose the user doesn't want to sync across machines? I don't think > they get a check-box in the iCloud system prefs pane, right? > > And if it would be good practice to offer should a check-box to the user in > the app's preferences, how would one go about enabling/disabling iCloud at > run-time for an app using core data? Would it be enough to ignore the > notifications? I guess not, since when the app relaunches it will see the > transactions produced on other machines. So I guess the correct way is to > create a new persistent store coordinator with/without the *Ubiquitous* keys > and swap it in. > > And suppose the user has iCloud enabled in the app on one machine, but > disabled on another machine, then the transaction logs would be generated. So > how to ignore them on the machine where iCloud is disabled for the app? Would > it be correct to create an NSPersistentStoreCoordinator where > NSPersistentStoreUbiquitousContentNameKey and > NSPersistentStoreUbiquitousContentURLKey are not set? Would that mean that > that copy of the app would not get the > NSPersistentStoreDidImportUbiquitousContentChangesNotification notifications > and would it ignore the transaction logs? And what should one do when/if the > user re-enables iCloud sync? Will the app catch up with the transactions? > > Has anybody thought about, or even better, solved these issues? > > Best wishes, > > Martin >
I'm finishing up a shoebox app now and I do have the option to store things in iCloud or not. My eventual solution to this was to have a preference screen in the app with a single "enable iCloud' switch. If you flip it from off to on, or on to off, you get a section of buttons to hit asking how you want to perform the transition (eg when transitioning to the cloud you can merge local to cloud, use cloud or use local), it then gives you a confirmation box before you do it. I failed to find a really good way to do this in preferences, so I put it in the app itself, there are just too many questions about how you want to perform the migration which I think need to be asked then. Not quite sure about your question about iCloud on one device and not the other. If iCloud is enabled then the files are in the iCloud URL sandbox, else they are in the Documents subdirectory of your normal app sandbox. I don't know what happens if you work in the sandbox without an NSPersistentStoreUbiquitousContentNameKey and .. the other one .. I guess you don't generate the logfiles and that may mean it's hard to later sync to the cloud (unless makeUbiquitous is very smart). So I would personally probably just use the same keys whether I was in iCloud or not and let the framework sort it out. Yes I know that means if you stay local you might end up with lots of useless logfiles you don't really need, I've seen no guidance in the docs nor the forums about this. I'm not sure about the last question. I've been operating on the principle that if you enable iCloud, anything which is there is there, and anything local is either copied to a new URL and left there, or just overwritten, in the general case it would seem hard to apply the transaction logs to a database which might have moved forwards in time. I have found that writing a monitoring app which just shows the changes in iCloud on the device has been the most useful debugging tool I have. I change them in one place and can see on say an iPad what has happened in the cloud. It continues to be unfortunate that the simulator doesn't work with iCloud and you have to do it on the device as you just don't have the sandbox access to really see what you have. > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org > > This email sent to r...@rols.org _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
