I followed the same steps as in "Using Core Data With CloudKit":
New project
Enable Core Data + Cloud Kit
Add iCloud/CloudKit entitlement + Background mode/remote notifications entitlement.
In the iPhone Xr simulator I signed into an iCloud account I created (and then verified on icloud.com!) and ran the app, creating multiple entries.
I then signed into the same iCloud account in the iPhone Xs simulator. I ran the app but no entries were merged. Creating entries in this simulator also does not merge back over to the Xr simulator.
What am I missing?
To see the changes with Simulators you have to quit the app, and reload it (or build & run).
Simulators have never been able to receive Remote Notifications to trigger an iCloud sync so you need to manually force a sync, but I've found that syncing cannot be triggered manually from the menu in my Xcode 11 beta (gives an error).
There is a good post by Andrew Bancroft about some other things such as setting the automaticallyMergesChangesFromParent property to true, but this doesn't make a difference when using Simulators (EDIT: It does, but I didn't realise as I was just building & running each time).
Andrew's Post: https://www.andrewcbancroft.com/blog/ios-development/data-persistence/getting-started-with-nspersistentcloudkitcontainer/#where-s-my-data
I'm in the same boat as I can't afford to install any beta software (except Xcode) so I'm going to have to stick with the simulators. But my experience of converting an existing App to CloudKit has been very, very positive. I just had to do three things to my existing project:
Add Background Notification & CloudKit capabilities
Make sure all Core Data attributes & relationships are optional (or have a default value if nil)
Rename NSPersistentContainer to NSPersistentCloudKitContainer
...and that's it! Mind blown.
All my nested many-to-many relationships appear to work perfectly.
I still need to work out how to sync images currently stored as JPGs in the users Documents directory but I suspect they'll need to be stored in Core Data as BLOBs to enable conversion to CKAssets in the background.
Apple now have example code called CoreDataCloudKitDemo.
This includes all the basic stuff and also has additional code which processes the changes when they arrive from the other device.
You need to have the lines
description.cloudKitContainerOptions =
NSPersistentCloudKitContainerOptions(
containerIdentifier: "iCloud.com.developerid.databasename")
to get your local database going to iCloud and creating the schema.
You need to use the Cloudkit Dashboard on the web to see the schema etc.
Related
What technology is available for me to save app data (Core Data) so that when a user switched phones and has a fresh phone they still have my app information?
I have heard people say cloudKit, however that seems overkill, I don't want the functionality to handoff between devices. I simply want the app data to be backed up when the user has iCloud backup enabled for the app.
If the answer is iCloud, what steps must I follow to enable such behavior? I have seen links to cloudKit tutorials, however all of them cover an extensive amount of material and work, and what I want to achieve seems simple enough. (As stated before I do not want handoff between devices, I have no need for it.).
Thank you for the suggestions
Edit: I have gone into "capabilities" and switched on iCloud. Now in my iPhone settings under iCloud backup my app appears. However does simply switching on iCloud capabilities persist your app data to iCloud Drive or backup?
Ex: Go to Settings -> Account -> iCloud -> Scroll down to iCloud Drive and ensure it is checked. My app shows there, but I haven't included any code to implement this (I simply flipped the switch in capabilities)
So from my current understanding I create Core Data as normal, however I add a listener for an changes/updates/deletes/creation of the persistentStore and upload/update iCloud via document storage when this happens? I was under the impression that iCloud was being depreciated and that only cloudKit will remain?
Edit 3:
iCloud = Depreciated, therefore the one and only solution available is cloudKit.
How does one implement cloudKit to interact correctly with Core Data?
What comes to mind is the following:
- Enable cloudKit
Listen to all changes to persistent Store and reflect these changes in CloudKit (somehow)
On app start check to see if CloudKit matches core data (somehow)
if they are not the same then download cloudKit data and save to core data (somehow)
Please clarify if this is not the correct route to proceed down
What technology is available for me to save app data (Core Data) so that when a user switched phones and has a fresh phone they still have my app information?
There isn't any such problem. I've upgraded devices many times and nothing has ever been lost. When I got a new iPhone last year, and when I got a new iPad this year, all my apps on the new device simply showed up with the same settings and data as before on the old device.
That's the because the user who gets a new device backs up from the old device and restores to the new device. That's what I always do and it just works. You cannot reliably work around a user who is too stupid to know to do that, so I recommend not even thinking about it.
I am using the source code from https://github.com/jab5990/TestCDiCloud.git. Apparently this source code is the sample code from the WWDC 2012 Session #227 called Using iCloud with Core Data. The original source code does not seem to be available on Apple's website any longer.
I am new to Core Data and I struggle quite a bit with these concepts. The situation is that the data does not get refreshed while both apps are running:
I add data to my mac app (2 first rows)
I start the iPhone 7 app in the simulator (after signing in to iCloud)
The entries from the mac show up
I add more data to the mac app
The data does not show up after several minutes
So on in DetailViewController.m:204 on the iPhone App the Notification NSPersistentStoreDidImportUbiquitousContentChangesNotification is registered, which should mean that changes from the Mac app should be incorporated.
How do I ensure that the data stays in sync.
In the simulator sometimes you need to use the Debug -> Trigger iCloud Sync menu to trigger the sync. It is not automatic like on iOS devices.
If you keep having issues then try these sample apps which include code for handling iCloud account switches, moving from local to iCloud, making backups, storing and fetching backup files in iCloud, etc...
http://ossh.com.au/design-and-technology/software-development/sample-library-style-ios-core-data-app-with-icloud-integration/
BTW that wwdc2012 session is old so I would look at the more recent wwdc2013 session 207 video for things that have changed in iOS7, OSX 10.9
iCloud can take quite some time to transfer files, and then the Core Data framework has to get around to actually importing the files. So several minutes or even longer is not unheard of for a delay.
You can use Xcode to trigger a sync with the Debug menu. That may help. Otherwise, you probably just have to wait, or perhaps quit and relaunch the app.
Welcome to the wonderful world of iCloud debugging.
I have a development distribution of an app out on a couple of devices.
Turns out my export functionality causes a memory leak - meaning I can't get that screen to open without reinstalling the distribution of the app.
Is that data totally lost? I'd really like to be able to save it.
Some ideas:
Write a second helper app that could grab the data
Write some sort of shell script that could retrieve the data plugged into a comptuer
Plug in the devices to a computer... do something in Xcode... no lost data?
Is there any hope?
UPDATE
There was hope!
First - Your data is accessible via Organizer in XCode.
Second - New versions in iTunes do not overwrite core data. BUT you're going to want to make sure the version # increases as iTunes was somewhat finicky about sending over the new version. Your testers might be tempted to delete the app - replacing it in iTunes and re-syncing is all they need to do.
If you update the app without deleting it first, the data is not removed by the OS. So the new version of your app has the opportunity to read the old data.
We need to test our app in the context of an iOS upgrade (e.g., 5.1 -> 6.0). Unfortunately, Apple doesn't allow downgrading devices. We thought of doing it in the simulator, but different versions of the simulator are different environments in themselves. I think we can copy the bundle from one simulator to the other, but that won't migrate the keychain (will it?).
Thanks!
To test a transition from one state (before) to another (after), you need a way to put the app in the before state.
Your app surely won't be running while the OS is being updated, so you really only need to worry about the app starting up and discovering that the OS has been updated. There are a couple options:
Copy all your app's data files from a device running the "old" iOS version (5.1 according to your question) to a device running the new (6.0) version. The organizer in Xcode will let you easily copy your app's "container" from a device to your Mac or vice versa.
Make your app write it's data in the "old" format. It's not uncommon for an app to have methods for reading and writing data in different formats depending on the environment, so it's often easier to get your app to write data out in the old format than to actually copy from an old device.
Whichever path you choose, think about any other places (like user defaults) where you might made OS version-dependent changes and set those back to values that correspond to the previous OS. This applies especially to keychain items, which aren't stored in your app's sandbox.
Unit testing frameworks (like Apple's XCTest framework) generally have a setup mechanism that you could use to reset your app to the before state, including copying files, adding and removing keychain items, setting defaults items, etc. You can then add unit tests that run whatever code might be involved in an update and test the results. With a set of easily repeatable tests you'll be able to debug any problems more easily.
However you approach it, the goal is to put the app in the same state that it would be in if it were running for the first time after an OS update occurred. You don't have to worry about simulating the actual OS update, you only need to trick the app into thinking that the update has just happened.
For now, you can still install iOS 8.2. When a new version is released, Apple leaves both versions open for installation for a short time. While that "signing window" is open you can upgrade a device, test, and then restore it from an image of the older version. So you could do some intensive testing while the window is open, but obviously that's not a long-term solution (it typically lasts only a few days).
If you have the budget for it, you could install 8.2 on a device, put a big sticker on it saying "do not upgrade", and keep it on 8.2 for as long as it's relevant. Install your app on that device and take a backup (with backup encryption enabled so that keychain entries will be included), then restore that backup to another device that's on 8.3 - this is basically the same procedure you'll go through when doing an upgrade/restore through iTunes so it should be pretty close. It won't be exactly the same as an OTA update on-device of course, but for that, see option 1 above (and see it soon).
I have an app on the app store, that uses coredata as storage. I wan't to update the app with iCloud synchronization as new feature. Following apple`s sample code, I managed to have my core data storage synchronize between devices.
However, I'm experiencing problems when either iCloud synchronization is turned off/on in the app on only one of the devices, or when the app is deleted from the device and the reinstalled. In both cases, data is not synchronized back to the device, although it is available just fine on a second device (which was not disabled/reinstalled).
I also found that all storage is effectively erased completely, when I delete the app from all devices, and then reinstall. Althrough I get a couple of merge notifications in the console (even some without errors), I can't see no data in the local storage of the device.
Browsing the mobile documents folders on my mac still reveals lots of transaction logs in the icloud storage of my app.
Even deleting the app from all devices and starting from scratch wont sort things out. I will end up in a situation where data is either only synced to one device, or not synced at all.
I wonder if there is anything I can do about this inconsistent state that is created when only one device is temporarily iCloud disabled, or the app is deleted from ONE device?
As for my code, its an 1:1 copy of the recipces example from apple.
Daniel Pasco talked about using Core Data and iCloud together at NSConference 2012. Some notes from that blog post:
launching with -com.apple.coredata.ubiquity.logLevel 3 to get a spamfest in the message log saying what Core Data and iCloud are doing.
The conclusion from this talk appears to be that using Core Data and iCloud are really not ready for each other at this stage.
He posted an updated Core Data Recipes project on Github which may or may not fix your problem.
Apple makes it seem easy, but there are a number of nuances with regard to correctly seeding iCloud with data, and what happens afterwards when iCloud support is toggled on and off on different devices.
I implemented a sample project that demonstrates a straightforward way to add iCloud support to Library-style CoreData apps. It's called iCloudStoreManager and it's available on github.
I'm still testing it before I add iCloud support to one of my own production apps. It's working, but I see unexpected errors and delays when an iPad 3 is in the mix. It works, but with long delays.
I've also tested with iPhone 4, iPhone 4S, and the original iPad, and any mix of those devices works well in my experience.