I'm starting a new project (and very new to Core Data) and was curious about how to manage images within Core Data and an Asset Library. I've done some reading and am just unclear on how everything works together.
Is it possible for each Managed Object to have an "asset library" of images? ie. can the asset library be populated with Core Data data.
What is the best way to handle having a large array of images attached to a managed object?
If anyone can point me in a direction of an article/tutorial or provide further guidance, that would be greatly appreciated.
Thanks!
Yes Core Data can handle storing an image asset database as well as the images themselves. Core Data has an option that will let it store large binary objects as files, rather than in the sqlite database itself. Core Data would be effective for storing details about the images and for categorising them into albums, projects etc.. It would also be useful for searching on these attributes.
Typically you would not attach a large array of images to a managed object. An image would be represented by a managed object and one of the attributes of the managed object would be the image (which Core Data might decide to store as a file somewhere).
I think you might be out of luck if you want to use iCloud for replicating this image library because I don't think Core Data will sync these externally stored image files.
https://developer.apple.com/library/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS5.html
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 URI to a separate file that it manages for you.
if you store your images in image assets and Managed Object have the "asset library" of images, then you will have the problem on updating the images.
and even if you do not want to ever update the images then why to store it in core data ?
solution is : have the images in image assets and also store the binary data of images in core data in launching the app.
by checking a date of modified coming from a web server you can check whether to update the images or not.
this link is helping you to import anything to core data easily done.
Related
In my app, the user has a collection of leaves (and a leaf is a core data entity in my XCode project). I'd like to create a note-taking feature so that they can write/save notes for each leaf in their collection. I would imagine this would require saving text for each item as an attribute of the the core data entity or storing it in the documents directory
Is it better memory management/app efficiency to save text with core data or documents directory? I know that its not good to save images in core data and I was wondering if there are other best practices I should be aware of/can implement!
Since you're talking about written notes, there's no need to worry about efficiency at all. We're talking about a few hundred bytes per note. That's at least a factor 1000 away from where performance might become an issue.
Just do what's the easiest. As you already seem to suggest that would be storing the note texts directly in CoreData objects.
I have several big plists in my app. I use them to get necessary input data to my app. While app is running, this data used in various random visual representations. Also, I have favorites feature, where I save some favorite pieces of data. For favorites feature I use CoreData. I transfer some object from my "runtime" data to CoreData and save it.
But should I transfer all data from plists to CoreData, when I launch app for the first time? Or is it ok, to use plists to get data from them every launch?
For example, if we'd talking about reading app. We have some text file on disk. Should I transfer all file to CoreData, when launch first time? Or is it ok, just to save user bookmarks to CoreData?
Core data and plist both are used for store the data. so, if you get data from plist or core data at every launch, there is no problem at all. But if you want to manage complex relational database then you should use core data or sqlite. so, choose storing system as per your requirement like if you want to store user's default credential then you can use nsuserdefault and if you use it to store complex data then also it will work fine but you will possible to face trouble to face some kind of functional operation. So, main concern and your answer there is no difference you get in performance whatever database system you used.
Hoe this will help :)
If you have to only read the data or update all data from plist allmost all the time plist may be ok, also it will be more easy to access then Core Data
Both plist and Core data can be used as persistant storage, but Core Data will have some addtional benifit like i have listed below:
Data stored in the Core Data is pretty secure, so if you can store some sesitive information in the Core Data, data store in plist can be seen directly in some ways.
If you have to perform some insert,update,delete or search on the data it will be better on the Core Data instead of plist.
If you want something like relation or mapping between data it will be possible with Core Data only
So based on the requirement you can choose your storage options
I have an iOS app that makes use of an sqlite database. I need to persist several pictures I enable the user to take and save, what should be the most appropiate way to handle that? To store them into Documents as jpeg image files? To store them into the database? I've found some posts dealing with both that options, but I'd like to know which one is the most correct or the most recommended...
Thanks in advance
You can use either approach. Like neilco, I would lean more towards storing the images as files in your documents directory and saving paths to them in your database.
You can also store them as BLOBs in your database. If you do that, make sure to make the image BLOBs separate entities, and only load them when needed. That way you don't bog down reading of your "normal" database entities with image data.
I would be inclined to store the images in Documents and create a record in the database with the path to the image.
I have a working drawing app that uses a Core Data database to store drawings. It allows the user to creates multiple documents but I'm using only one database with multiple drawing entities.
Now I'm making some big improvements in the app and I'm trying to do things right. I think the way to do this kind of app is using UIManagedDocument.
My guess is that I should use one UIManagedDocument for every drawing so they'll be saved as independent documents on disk, but I haven't been able to find any examples of this anywhere.
If that's the correct approach (which I'm not sure), I need to know:
How do I retrieve a list of all the documents (drawings) created?
How do I save a preview image of the drawing? Do I save it inside the UIManagedDocument or somewhere else?
Thanks.
Maybe you can use this article as starting point:
http://www.informit.com/articles/article.aspx?p=1842295&seqNum=10
The main idea of UIManagedDocument is that each document has it's own managedObjectContext that is persisted in the document's bundle.
How do I retrieve a list of all the documents (drawings) created?
To display a list of local drawings you could just display your storage directory contents in a collection view.
When dealing with documents stored in iCloud, Apple suggests to use NSMetadataQuery.
How do I save a preview image of the drawing? Do I save it inside the
UIManagedDocument or somewhere else?
To store additional information (like your doc preview) in the bundle, UIManagedDocument provides writeAdditionalContent:toURL:originalContentsURL:error:
Please also keep in mind, that NSDocument/UIDocument are controller classes (and not model classes).
I'm developing an app that uses core data (with UIManagedDocument) for storing user-generated data that I would like to sync with iCloud. I also would like to sync photos that the user takes with the camera within the app.
I read that it's not a good idea to store the actual photos within core data; rather it's better to store the photos in the file system and put the fileURL in core data.
Using this method, what is the recommended approach when using UIDocument to store the photos in the file system (under the Documents folder)?
I've thought about:
For each individual photo, use a NSFileWrapper(containing the
actual image and thumbnail image), or
Use a top-level NSFileWrapper, and put all NSFileWrappers in it for each photo
Similar to #2, but just put all photos/thumbnails directly in the top-level NSFileWrapper
Which approach is better for syncing photos with iCloud? and are there better approaches?
The best approach in this case is to let Core Data decide where to put it.
Open your Core Data model GUI -- click on your attribute that will hold your binary data -- look to the right -- there is a check box that indicates if Core Data should use external storage if it wants. Select it.
That's all. If Core Data needs to use external storage, it will do so -- you wil neither know nor care what it decides.