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.
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 build an iOS app which works with base. User can work with it everywhere, that is cool. When application starts for the first time, obviously, base will be empty. For now, user's base stores data locally with Core Data. But there is a case, when user may have his own base with a lot of data and he do not want to start work from scratch. For this reason I want to create simple Cocoa App for macOS, which will allow user to import some data from, for example - CSV file.
Both Core Data models (iOS app and macOS app) will be the same. I just want to make sync between two platforms.
I think it's possible with cloudKit, but which way is the best? Core Data Sync or smth like supporting MySQL database on server, etc...
Thanks in advance!
Asking which method is "best" is a matter of opinion, but in mine, Apple has made working with iCloud fairly simple. If all you want to do is sync between platforms, I would use cloudKit. There seems to be no reason to spin up your own MYSQL database instance and introduce another level of complexity, when the functionality you're looking for is free and easily accessible.
See this WWDC16 video for some cloudKit tips: https://developer.apple.com/videos/play/wwdc2016/226/
I'm creating an iOS application that has a Twitter-like feed of data. I'm currently planning on storing the data on Parse. However, what is the most efficient way to store retrieved objects locally for use when there does not exist a network connection? It sounds like using Core Data is overkill since I'm storing the data on Parse anyway. Can the Parse caching system do this for me or is there something else more appropriate? On a similar note, is there a simple way to check if this locally saved data is up-to-date?
I recommend you have a look at SQLite, especially with the FMDB Objective-C wrapper classes.
Parse has the capability to cache objects locally. If your app can tolerate the characteristics of caching, then just use that.
My own app will not, so I am using CoreData as my local store. My app has to be able to operate fully when disconnected from Parse, so I have to have something more than cached data. I looked at FTASync and found the concept very useful. When I got into the code though I realized I needed something much more robust, so I have ended up doing a completely new utility to sync Parse with CoreData. This is a huge job, so don't take it on unless your need is commensurate.
-Bob
I'm trying to build a flashcard app that requires words and definitions to be stored somewhere on the device. What is the correct/best way to store this information? I have read about ways to prepopulate Core Data but the solutions I've read seem like hacks. This seems like a basic feature needed by many apps so am I missing something here?
Core Data is the way to go here. There is nothing hacky about pre-populating a persistent store and including it in your app bundle.
Core Data seems like overkill for a flashcard app. I'd probably just save the contents to a plist. Is this content read-only, or do you need to update it at runtime?
If you need to updated it you could copy check for a plist in the documents directory at launch, and if it doesn't exist, copy it from the bundle into the documents directory. You can also use the same approach with a Core Data database, but unless you're familiar with Core Data the learning curve to learning it probably isn't worth it for something as simple as a flashcard app.
First time asking a question on here, so please go easy if I don't provide enough info. Basically part of my iOS app allows users to take a picture which will be stored in a Core Data store. The attribute is a Transformable type, and I have created an NSManagedObject subclass which I simply use to set its image attribute to the new image provided by the user.
I know storing large files in Core Data is a bad idea, which is why I was excited when I saw the "Store in External Record File" option under the image attribute in the Core Data entity. However, my app performance says otherwise, taking several seconds on an iPhone 5 to load only a few images (which I know doesn't sound like much time, but considering how powerful the iPhone 5 is, older devices would likely take much longer with the same data).
I've looked around, and some people say that the Store in External Record File option is only applicable to the OS X environment, even though it is available in an iOS app. However, I also saw this under Apple's "What's New in iOS 5" doc (it's the next to last item under Core Data, near the end):
Managed objects support two significant new features: ordered relationships, and external storage for attribute values. If you specify that the value of a managed object attribute may be stored as an external record, Core Data heuristically decides on a per-value basis whether it should save the data directly in the database or store a URL to a separate file that it manages for you.
So my question is, who's right? Is it true that Apple made a mistake in giving this option for iOS apps, and that it actually does nothing unless you're on the Mac, or does it actually do something and I'm not configuring it the right way, or is it doing what it's supposed to do and the performance is bad anyway?
I've seen some guides explaining how to store large files (like images) as files, and save the URL to them in the Core Data store instead, but since this is essentially what this new option is doing, or maybe should be doing, I'm not sure if following these guides would even help.
I'm really sorry if this has been asked before. Normally I'd be fine with figuring this out on my own, but Core Data is totally new to me, and I'm still not sure how I managed to squeak by the initial setup. Thank you for any help you can offer!
who's right ?
the iOSÂ docset for the NSAttributeDescription class does mention the allowsExternalBinaryDataStorage and the setAllowsExternalBinaryDataStorage: methods so there is little chance that there is a mistake from Apple.
are you doing something wrong or is slow anyway ?
You said that
The attribute is a Transformable type
But Core Data has a Binary data type. Maybe only this one is linked to the external storage capability.
if that's not it, we don't have enough info here:
How many pictures do you store ?
What are their sizes ?Â
Do you automatically fetch all the images ?
Also, the Apple doc states that:
Core Data heuristically decides on a per-value basis…
Did you use a migration or are you starting from scratch ?
You could have a look in your app's sandbox to see if your pictures are really saved outside of CoreData.
Hope this helps.
Good question!
Check this post:
Storing blobs in external location using built-in CoreData option
Apparently it should work. You should also try it in the simulator and inspect the application data folder to see if the folders are created as described (~/Library/Application Support/iPhone Simulator/... - you will figure out the rest of the path). Also you could inspect the sqlite file with the sqlite3 command to see if the binary data is in the database.
I haven't personally used this option as I would prefer to go for manually saving the images in a folder and store a reference to them in the database instead. This way it will be easier to create UIImage object from the file to be displayed, would have better control on what goes where and so on and so forth. Will take some extra labour though!
Hope that helps you out.