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).
Related
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.
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'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.
I'm developing an app which needs to show some logos. These logos are just 8kb PNG files, and I'm just going to handle a little amount of them (10-20 at most). However, these are downloaded from the Internet because they might change. So, what I'm trying to achieve is, making the app to download them (done), storing them into the file system, and only downloading again whenever they change (might be months).
Everyone seems to use Core Data, which in my opinion is something designed for bigger and more complex things, because my files will always have the same name plus don't have relations between them.
Is the file system the way to go? Any good tutorial?
Yes, the file system is probably your best option for this. You say that you've already implemented the downloading. How have you done so? With NSURLConnection? If so, then at some point, you have an NSData object. This has a couple of write... methods you can use to save the data to a file on the filesystem. Be sure to save the files in the right place, as your app is sandboxed and you can't write anywhere you like.
The advantage Core Data brings is efficiency. Using NSFetchedResultsController to display your logos in a tableview gets you optimized object loading and memory management. It will automatically load only the items which can be displayed on one screen, and as the user flicks through the table it will handle releasing items which move offscreen. Implementing that on your own is not a simple task.
If you want to build and display your data without Core Data, you'll probably want to use NSKeyValueCoder, which will allow you to easily write an array or dictionary of objects (including nested arrays, dictionaries, and images).
I am writing an iPad app that will be expandable with new items via in-app purchasing. For example, my current plan is to have a jpg pattern and a matching plist file with the parameters I need to expand that pattern into a full picture.
The user will select one jpg/png from a list of small thumbnails - the list is held in Core Data - and the app will find the matching plist for displaying the jpg/png correctly. I'll only have about 10 of these open at one time. But I could end up with storing 1000s of jpgs and plists.
Does storage of lots of small files cause app problems?
I'm going the plist way, rather than storing the parameters in Core Data, so that if I need to add parameters later, I don't have to migrate the database, just change the access in code. (And when I'm creating the patterns, it's easier to concentrate on a plist file rather than a Core Data row.)
The app seems to work really well at the moment, but I'm worried about futures...
My app does also use Core Data for other things, so I could change over if the app will get bogged down with number of files.
Thanks.
Saving a large number of small files is not a problem as long as you have a well thought out means of naming and tracking the files.
Remember that the user does not have the same flexibility and ease of file management on a mobile as they do on non-mobile platforms. Designs that work on non-mobiles are unworkable on a device used on the move with one finger.
However, when you say:
And when I'm creating the patterns,
it's easier to concentrate on a plist
file rather than a Core Data row.
... the use of "row" suggest that you haven't fully grasped Core Data's utility. Core Data doesn't use rows, columns, tables or joins. It's an object graph management system that sometimes uses SQL way behind the scenes.
Core Data is designed to handle data in a way that meshes seamlessly with the rest of the object oriented API for the UI and other services. When you use other data management systems like plist, you will most likely end up manually duplicating a lot of Core Data's functionality anyway.