So I am working on an app that uses core data to store attributes of objects that the user can set. I have primarily been focusing on the first part, which was setting everything up on the core data side, and now I am ready to move on to the next part which deals with the camera. I want to be able to add a city, or other geographical location (this is the object) and then be able to take pictures within my application that would accordingly store these pictures (or attributes) under the object. When I click on New York on my uitableview for example, I'd be able to view any number of pics that I took in NY. When I click on Florida, I'd be able to view any pics I took in Florida. So, my question is about whether or not that is a possibility? Sorry, that was a vague question. If I were to take pictures from within my app, would I be able to save them there as well? And make a list of them in my app? I guess I am envisioning a seperate core data-esque looking uitableview withing the place object letting you manage pictures so that they are directly viewable in like a slide show mode where I'd be able to see all the pictures I took at that location. Is that a possibility or would they save in the default picture location in the pictures app? Would there conceivably be any memory restrictions? Or would I be able to pull from the media memory (8gb, 16gb, etc)? I guess my questions aren't for specific code examples as much as they are for directional purposes. If anyone has any insights/ideas to help me out it would be greatly appreciated. Thanks!
The design you describe is definitely possible.
You can give users the opportunity to select a picture (and/or video) from their photo library and/or take a new one with the camera and then use/edit/store it in your application. Check out the UIImagePickerController and the UIImagePickerControllerDelegate protocol.
You can store images directly in Core Data as a transformable attribute by converting them to NSData using UIImagePNGRepresentation() or UIImageJPEGRepresentation(). If you do this, it is recommended that you create a separate entity with the image data attribute so that you can load your other attributes quickly (and only pull in the image data across the relationship as needed). Alternatively, you can store the images in files in your app's Documents directory and save the filename as an attribute in your entity.
Check out the TTThumbsViewController in the Three20 library for a nice way to show a grid of photo thumbnails.
I would really recommend storing the files to the application Documents directory, and storing paths to them in the database. You can do it the other way but storing them in files keeps the database smaller and gives you more flexibility to upload them somewhere without having to load the whole image in memory.
Related
I am just learning core data and already I have the following task.
I have an app which syncs core data with iCloud.
Now I should provide feature according which user should be able to link images
from camera roll with some entity. And as a result, that images also should be synced
with iCloud.
I know that I can create "image" entities, "connect" my existing entities with that and sync.
But I know that images storing to core data is not preferable.
Therefore, I think the another option is to store images to some directory and sync that it.
I'd like to know is the second option is possible to implement and integrate with already existing code.
Also if it is possible please provide some examples.
Thanks.
I planning on building an app whose main content are images. Basically, it is going to have multiple menus using UITableViews, whose cells are going to have only an image. When you click the cell, you'll be pushed to a simple view with that image and another one, wich has the rest of the detailed content.
This is all quite easy to do, my questions is about optimization. It's gonna have LOTs of content (Maybe 1k rows) and It's gonna display images in the UITableView, so Core Data is a must (given it's lazy loading and several other optimizations)
My question is: What's best, to store the image in the Core Data db (as NSData) or to just store the name of the image? What I'm imagining is if I store the name of the resource, For each row in the UITableView the device must go fetch that image, process it finally display it. When scrolling trough them (wich is expected to happen A LOT) we would have lots of fetching images. If I store them in Core Data, it would be as simple as taking that info and using it as if it where an image.
The benefits of storing the images in Core Data comes with the normal withdraws of storing blobs in a db. I don't know how much of a problem this would be in Core Data (My experience in dbs comes mainly from MySQL)
On the other hand, tough my "common sense" dictates saving just the name and fetching the images as they're needed its gonna take more time if they're requested more, I'm not sure how much of a performance hit would this be. Is there a "best way" to store them? Just the name and then call pathForResourse:ofType:or (if it's faster) pathForResourse:ofType:inDirectory: on the mainBundle, store the URI, or other form of pointing to it.
edit: The application will have static content shipped with the application and the user won't be able to modify this content in any way. (at least in version 1.0)
From the Core Data Release Notes for iOS v5.0:
Small data values like image thumbnails may be efficiently stored in a database, but large photos or other media are best handled directly by the file system. You can now specify that the value of a managed object attribute may be stored as an external record—see setAllowsExternalBinaryDataStorage:. When enabled, Core Data heuristically decides on a per-value basis if it should save the data directly in the database or store a URI to a separate file which it manages for you. You cannot query based on the contents of a binary data property if you use this option.
The setAllowsExternalBinaryDataStorage: essentially does what you described "...just store the name of the image..."
Also refer to these other questions:
CoreData : store images to DB or not?
Core data images from desktop to iphone
Provide example for why it is not advisable to store images in CoreData?
you will get a great optimization from just using the name of the file...
if you re-use a file ... you wont have to store it in the database twice, or alternately have a model object just to represent that file as a relationship.
You could do some profiling and check... but I assume that just a name would be ideal.
also you could do a little work to make something similar to -imageNamed that caches the images for you, and you will only have to make one UIImage for each file, wherever it exists in your program.
Don't save the images in core data. You can save the information pertaining the images in an organized matter in core data, but keep the images ordered in a supporting files section in your project. Or if you are downloading the images, you can cache them in your images section of the app and simply update the information for the images in core data.
I'm developing a reference iPhone app that will contain many photos (ball park estimate of 75-100 photos). All of the photos will be stored locally along with at least one or two other versions of these photos in different image sizes representing the same image.
As a newbie to iPhone (and C) development, I'm unsure as to the best way to store these images for reference in the application. Is it possible to create folders/packages/bundles for them to live in?
FWIW, the app is run from an XML file, although I am considering a SQLite database as it is becoming harder to maintain with XML.
The most obvious solution is to write the image files to your applications' documents folder. You come up with a name for each file (or obtain it from XML), and then you use methods for dealing with image classes to obtain jpgs/pngs and save the files. You maintain references to the filenames strings elsewhere, persisting those in a .plist or archiving them in a dictionary (again, storing that archive in your documents folder).
CoreData now allows you to store files externally (which is better than storing larger images directly in SQLite) but it will manage and track them for you. That'slightly more sophisticated, but since XCode bundles CoreData templates, you can put those together very quickly and easily.
Use The concept of Lazy Loading to download all images and save them in to root directory...All The best!!!
I want to create an iPad application that is pretty much just a catalog of products(say for example, cars) I will have around 500 products total, and each product is pretty much an image that will load up when the user requests it.
example:
Product_ID: 124
Name: 'myImage.png'
User types a product id, the image will show up on a UIImage.
I was wondering what would be the smartest approach to this problem? I was thinking about SQLite or NSArray. Where the id would be the product id, and the value would just be the location or name of the image to load. Creating a cache document folder? Any suggestions from people that have already experimented and created similar apps?
I'd add the meta information like ID and the name of the image to a sqlite DB and manage it via CoreData, which has some very powerful ways to access the information.
The images themselves should be stored outside the database as I assume that they are not just thumbnails.
Best way would probably be Core Data. It has built in caching, so you won't have to worry about that. Here's a get started documentation: Introduction to Core Data Programming Guide. There are also a lot of tutorials online, but Apple has really good start up samples.
I have a Core Data based application that stores hierarchal data displayed using a series of UITableViews. To illustrate my app functionality to the user I would like to pre-populate my database/app with some dummy values. This data would be available upon installation on the user's iPhone/iPod Touch.
What is the best way to achieve this?
Create the data and include it in the app bundle. On first launch, copy that sqlite file to the documents directory and then stand up the core data stack afterwards.
Personally i would create a desktop app using the same model to do the initial data entry to make it easier on you. From there take the sqlite file that is generated and include it in your appilcation.