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!!!
Related
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 am writing an iPhone app which would download articles (UTF8 text files) from my server. The app is then supposed to produce a listing of the filenames. Upon clicking the filename, the file contents would be displayed. It is very similar to an email program or RSS reader.
My question is, what is the best way of saving / retrieving the content on the device? One option is to put it all into a sqlite db. The other option could be to download the contents and save it in a new file. Any other solutions?
Any advantages/disadvantages for these approaches?
Thanks in advance
For some rather small amount of data in a simple structure you could store it in an NSMutableDictionary and use its methods for writing the content to file and for reading from a file.
Your data structure seems to be simple enough for that. If the amount of data is small enough I cannot say. If your list may grow endless then you shoud go for sqlite or for core data rather than a simple dictionay. A dictionary will be stored completely in RAM. With sqlite ore core data you can utilize RAM more efficiently by loading not much more records as are curently displayed.
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.
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.
I want to create and manage a database with images and or audio clips. I know it's not the best idea and I know there are better options, but it's the easiest way to have the data separate from the programming and I'm not the one writing the code. So I need an application that will allow me to edit the database that the application is calling, and the application needs to call random audio or image file. I JUST NEED TO KNOW OF AN SQL EDITOR.
Super bad idea to put large files in a database, it will kill performance and could well blow away the memory limits an application has. You also cannot stream them out of the database the way you can from the file system.
Instead, consider this approach - as Alex suggested, work with separate files and strings that represent file names. You could put both the database and the files into a single directory, that your coder keeps as a folder reference in XCode - so all content in the folder you change is added to the coding project automatically. Note that if you change any existing file, due to a bug in XCode he'll be required to do a Clean BUild before building again or it will not copy changed assets (mostly a problem for the DB).
Then you can easily use any SQLLite client to maintain the database of filenames and other data. "Base" is a nice standalone app.
I would highly recommend you use some source control system like Git so that you could check in changes and the programmer could get his project updated right away without the confusion of emailing files around.
You could use Core Data instead. It uses a SQLite backend, by default. Instead of using BLOBs, you can simply store an NSString* that is a path to the object in the application's Documents folder. When you want to retrieve a stored image or other large binary data object, you can load an NSData* instance from the path value directly. Keeping large files outside the database will give you much better performance.