I was taking a look at WWDC 2013 sessions concerning iCloud and Core Data. I was really hoping to see there any new videos for UIManagedDocument or UIDocument. You might remember that those classes theoretically offer a great and simple approach to save data with (UIManagedDocument) or without CoreData (UIDocument) locally and in iCloud. But there have been or still are some really annoying system-based bugs coming along with those concepts, especially when syncing data between devices, see for example here.
However, there was NO video covering the UIManagedDocument/UIDocument and iCloud topic. The video "What's new in Core Data and iCloud?" just covers the classic approach for using Core Data persistent stores which is extended by new API to automatically cover fallback stores and syncing. Has anyone information what happened to UIManagedDocument/UIDocument? Did they give it up and see the classical approach as the better way to have apps with Core Data and iCloud sync?
My understanding is that UIManagedDocument is a lightweight wrapper over core-data to abstract away some of the common core data setup and interactions. It is also a way to package other 'document' elements but managing the iCloud syncing of those items is left as an exercise for the developer.
If you are using iCloud, UIManagedDocument does not support “additional content” in the document directory (see additionalContentForURL:error: and related methods)
That's referenced from: UIManagedDocument
See Also: additionalContentForURL:error:
Pretty much anything that applies to core data applies to UIManagedDocument where it uses core data under the hood. For example I make use of the new fallback stores in my APManagedDocument project.
What kinds of things were you hoping to see added in iOS 7?
Related
I'm working on an iOS app that will need to save data onto files. I chose to go for a Document Based app, precisely an app based on a UIDocumentBrowserViewController so that I can easily save and load files from the system's Files app.
Since the data I need to save/load on a file is quite complex: big hierarchy of different objects, with meta-data, image files, etc. I'm wondering what is the best technology to use going forward.
I came across NSFileWrapperand its ability to save different files as one. And I could definitely use that. But I also saw UIManagedDocument and the ability to use Core Data in my project while maybe saving the content of the Core Data database (I know it's not quite a database, but you know what I mean) into a file that I could write somewhere in the File App.
Is this a behavior I can expect?
To reformulate: I'm wondering if I can read/write files through a UIDocumentBrowserViewController, with data described by a UIManagedDocument that works with Core Data.
Thank you in advance. 🙂
As you have discovered, UIManagedDocument is there for your kind of application. And it does feature methods to write and read additional content like the metadata or image files you have, within the document package.
That being said, I have never used UIManagedDocument, and have never seen it used by others. A quick search of GitHub finds only this one project with two contributors who wrote a wrapper around it in 2013. Also, there does not seem to be any sample code from Apple, and the remark in the the writeAdditionalContent(_:to:originalContentsURL:) documentation that Additional content is not supported on iCloud leaves me a little concerned, but maybe it's a good sign that the Core Data team knows where to draw the line.
I have used the macOS counterpart of UIManagedDocument, NSPersistentDocument. It is in a similar situation of not being used very much, but with many more known technical issues. So a few years ago I switched to BSManagedDocument, which purportedly mimics UIManagedDocument to support Core Data in all its modern glory. I have been happy with BSManagedDocument.
In summary, if I was in your situation, yes I would give UIManagedDocument a try. But don't be surprised if you need to use a DTS support incident or two during your development.
I am developing an iOS notes app where a user can add image, text, audio and drawing notes. I want to implement iCloud synchronization between multiple devices. Out of the 3 options (key value, document storage, CloudKit) which one should I choose? I would like to implement the sharing of notes (collaboration) among users as well. I am using core data as my DB currently.
Key-value storage is out of question due do being too limited for your goal, document storage is only recommended when you need to handle and store the document as a whole. Since you are already using CoreData for local storage, it only makes sense to use regular CloudKit with it for cloud storage and sharing.
Synchronisation of CoreData and CloudKit can be tough. I am personally using a combo of RxCoreData and RxCloudKit libraries which provide some relief in synchronisation and some syntax sugar too.
A word in advance about uniqueness constraints: for CoreData, you define them based on key(s) or hash of all values, for CloudKit it is only possible (and also required) for the CKRecord key, to the best of my knowledge. So it is best to take care of it from the very start.
IMHO, CloudKit is the only opinion :)
I have a note app named marknote. And at the beginning I used iCloud document storage. It worked sometime, but not stable. The worst thing is, when and whether your documents can be synced is out of your control, instead it relies on Apple's daemon service. It becomes even worse when your documents are a little big, for instance several mega bytes.
So after fighting for some time, I changed to CloudKit. As #maxim-volgin has already pointed out, the implementation of CloudKit sync is tough, but it is reliable. And all headache just gone after switching to CloudKit.
Hey at the moment I'm learning Swift and started to create an App for that. Everything is fine and I think I know the basics now. In that App, I use CoreData to save my Data but I would like to Sync that across Devices
Is there a way with Icloud to do that, I found there is something called "Core Data Ensembles" But is there a better way, or should I use the IcloudKit, if I can do the same things in IcloudKit with the relations like in coreData.
I just found old posts about that, so maybe there is a better way to do this.
Thanks in advance
Such synchronization works without any libraries involved. The main trick here is to place SQL file (or whatever you use for storing data) into a special folder that is going to be synced, so-called ubiquity container, and specify path to it for your persistent store coordinator. Here you can check high-level description of how it works, and there are a lot of step-by-step tutorials about it, e.g. here.
I am planning to develop a quiz app in iOS and doing it offline. I need to store 100s of questions and options in that app. How to store? How does core data comes in handy here? Is there any other good methods for this problem?
The app is meant to be offline.
You can also use SQLite database for saving Questions and Answers offline for your Quiz app. You can create tables in SQLite and save and fetch data from that using SQLite queries.
I would recommend you to use realm.io. It measures better than core data, its fast and simple to use. On https://realm.io there is lots of documentation.
I find realm much easier to set up and in generally to comprehend. It works nicely with SwiftJSON and hence in my view much easier to connect to backend.
Preloading core data can be quite cumbersome and to me it seems that core data still relies heavily on objective c.
On the other Core Data is made by Apple so it could be more stable solution on longer run (parse.com)
when I develop an iPhone App (Time Tracker, ToDoList etc) I never know whats the best way to deal with the data. Once I used a plist, next time sqlite or CoreData.
How do you decide whats the best for your project?
(Only talking about data management)
For Example if you want to develop:
Time Tracker App > Is PList your choice?
RSS Reader App > CoreData?
Photo App > sqlite?
EMail Client > ?
For a beginner can you point me roughly to proper directions?
(I know it depends a lot on the App and what you like to do with
it but any thought will help)
I'm far away from developing complicated apps, they are still pretty simple.
Thanks for help,
Marc
You can use these rules of thumb to decide what storage model will work for your app.
If the data fits in memory entirely and is relatively unstructured, use plist
If the data fits in memory entirely and has tree-like structure, use XML
If the data does not fit in memory and has a structure of a graph, and the app does not need extraordinary query capabilities, use Core Data
If the data does not fit in memory, has a complex structure, or the app benefits from powerful query capabilities provided by relational databases, use sqlite
If the data must be secret (e.g. a password), use keychain.
Note that these choices often overlap, because multiple storage models will fit the same app. Your final decision depends on your personal preferences - you pick a technology that you understand better.
There was a very good question about sqlite vs. Core Data on Stack Overflow, you may want to read through the answers to that question.
My rule of thumb for each of those would be:
Time Tracker App > Core Data
RSS Reader App > Core Data
Photo App > Core Data
EMail Client > Core Data
Though in each case there would be things you would store on the file system. For instance, the photo app would obviously put the actual photos on the file system. The text of the emails would be on the file system etc. The actual RSS messages might be text files too, but with meta data in Core Data objects.
At some point, you might find that the data you are storing is outgrowing the scalability of Core Data. At that point you would consider moving to SQLite.
The point is that Core Data is so easy to use and so superior to the alleged lighter weight alternatives, why wouldn't you use it?