Progress
I have not been able to solve the problem I was dealing this last week getting this error while syncing:
CoreData: Ubiquity: Librarian returned a serious error for starting downloads Error Domain=BRCloudDocsErrorDomain Code=5 "The operation couldn’t be completed. (BRCloudDocsErrorDomain error 5 - No document at URL)"
What I did find out though was that when I deployed my test app on two devices using the same iCloud account MOST of the changes would sync. But a few never did. If I deleted them while connected to iCloud, then migrated to my local store, then migrated that store back to iCloud they (and the errors) would reappear.
I’m suspecting that the problem is with this error I am seeing. I’ve seen one post recently on the developer forums that asked questions like “Is your store read only, do you have the correct permissions to the store, etc”. But since I have followed the Apple examples and the Core Data + iCloud API is so opaque I have no idea on where to look or how to fix it. The bottom line is I am becoming more and more suspect that Core Data with iCloud still isn’t reliable for production work. It has been improved, in the past it would just fail to sync altogether, but now it “mostly” works. But that’s not good enough for me. I found this post from late year and I think the blogger nails it on the head about the issues:
But I haven’t totally given up yet. I picked up the Ensembles book and my current direction is to see if I can use Core Data on the local device using a local store and hook into the Ensembles framework to do the syncing with the cloud. That feels like a happy medium and meets my original persistence requirements. If that doesn’t work then I am left with going down the path the post I just mentioned, goes. I think in the end I would like to go with my own REST service, but in the interest of getting my app out the door I’m willing to spend a couple of more weeks exploring Core Data with Ensembles. So that is my current direction.
I did solve the lockup problem I was having with my deduplication algorithm. It turned out to be a threading issue with the callback method on my save routine (which I posted last week). To switch it I had to change the call to the callback method to be an async operation instead of sync. I did update the code in that post. I guess the sync was locking up the async call it was in and since the callback needed to access the store and the async it was being called from also wanted to operate on the store the two were contending for the same resource and locked everything up.
Sorry no code to post this week. Hopefully, I will make progress with Ensembles and be able to post code next week. My goal is to post as much working code as I can so that others can either learn from my mistakes, tell me what I am doing wrong, or use it as a springboard to bettering their code.
Reading
I’m halfway through reading Spring in Action from Manning Publishing. I was able to get the test app deployed this week. Can now login, can’t successfully log out but that will come.
News That Caught My Eye
WWDC tickets went out this week. I can’t imagine what Apple will announce this year. Last year was so astounding with WatchKit and Swift.
Quick Looks
I briefly looked at FMDB. I don’t think I need to go to that extreme to solve my persistent issues. I think before I went that direction I would switch over to the Parse framework. Come to think of it that is still a possibility. I also did some work with Unity 5. That is such a joy of an API and IDE to work with.
No comments:
Post a Comment