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.
Related
I am really confused on what the Core Data actually is. Or I guess my question is, when dealing with a database, would you use Core Data? Like if I wanted access values from a database would I be using Core Data to access those values? How would I approach this problem?
Thank you so much for the help.
Core Data is an framework that does the work of "object persistence". In other words, it's code you can use that takes care of saving a collection of objects to disk and loading them again later. It does a lot of work to allow you to store lots of data and load only the objects you need at a time, and unload ones when memory is tight.
Core Data can use a database to accomplish this, but that's it's business, not yours. When you use Core Data, it is a black box. You tell it to save the data and then step out of the way.
If you want to interact with an existing database, such as a MySQL database on a web server, that's a completely different matter. You might use Core Data to store local copies of objects on your device, but in that case Core Data won't care that the objects are copies from some other database. It doesn't care.
It is a convenient, native means of storing data in your iOS applications. Don't think of it as sqlite although you can view the files it creates with various sqlite tools. Instead think of it as a tool for manipulating an object graph of information important to your app.
I've used it in two main ways. First to store a bunch of static data that is important to an app, in one case that was a large amount of location data for an indoor mapping application. What arrived as a massive CSV file of waypoints was converted to core data. Core Data was incredibly useful for this because it allowed preparing a sqlite file which was shipped with the application containing all the infomation. Updates from a web service arrive as more CSV that is added to the Core Data to keep information current. At runtime the location information object (the waypoint a user is at) is retrieved with a predicate (i.e. the point they tapped on) and that object, through its Core Data relationships, indicates where it is possible to go from that point. Core Data provided the information necessary to perform A* routing through the indoor map.
Second it is great when you have a bunch of objects arriving as JSON and you want to be able to store and access those objects later. Let's say you have a typical app where you have a User and some information about the User, let's call it Thing. Users have Things. When you want to know something about a User you retrieve the Core Data record using a predicate - typically "name" or similar - and you get all the information you stored about the User back. Again you can make use of relationships to explore the user's connections and make displaying information easy. Perhaps the User has many Things, then you can say "user.things" and you get a NSSet of NSManagedObjects representing those Things.
You use it like a database. Its utility is that it is easy to access from anywhere in your iOS code, it is easy to store and easy to retrieve information also. Faulting lets you retrieve one object and navigate to any object connected through relationships by following the relationships. Because you define the attributes and relationships yourself in the data model editor it is easily customized for what you need to store. To me it is one of the most used and most useful parts of iOS.
When you want to automate display of information from Core Data you can use a NSFetchedResultsController to initiate a fetch and to respond through delegate methods to changes to the underlying data. If you set up a UITableView to use a NSFetchedResultsController as data source, you can have the table automatically update whenever the objects displayed in the cells changed. Very useful for apps where you periodically update information and want what is displayed to be kept current.
When your object model changes it is possible to maintain all of your existing information and migrate it to the new model. Core Data manages automatic (lightweight migration) when it can, or if you have made more radical changes you can supply rules to handle the migration.
The limitation of Core Data is that it is not great for storing binaries. If you have images that you need to store, far better to store a path to the location of the image than trying to store the actual data.
Yes, if you want a local database on your device, Core Data is the appropriate technology. It probably makes sense to start your research with the Core Data Programming Guide.
You can alternatively use SQLite (which Core Data uses in the backend), but Core Data offers some material advantages and is the preferred database interface for iOS. If you decide to pursue SQLite for any reason, though, I'd suggest you contemplate using the FMDB Objective-C SQLite wrapper.
But Core Data is generally the way to go.
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'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!!!
So I have a question about the ideal setup for an app I am getting ready to build. The app is basically going to be a memorization tool and I already have an sqlite database full of content that I will be using for the app.
The user will navigate through the contents of the database(using the uipickerview), and select something for memorization. If that row or cell of data is selected, it is put into a pool or a uitableview that is dedicated to showing which items you have in your "need to memorize" pool. When you go to that tableview, you can select the row, and the actual data would be populated. All information in the tableview would be deletable, in the event that they don't want it there anymore...
Thats it.
I know that with database interfacing, there are a few different options out there, in this particular setup, is core data the easiest approach? Is there any other way that would be better? I am just kind of looking for a point in the right direction, any help is greatly appreciated!!
Core Data is going to be the easiest. You will want to migrate your data from your raw SQLite file to a Core Data generated SQLite file as Core Data is designed to manage its own file 100%. Fortunately you can do this with a quick command line app on the desktop and then copy the resulting Core Data Sqlite file into your application bundle for later use on iOS.
Doing raw SQLite on iOS is possible but a real headache to get right compared to the ease of use that Core Data offers.
Update
Core Data on iOS produces identical files to Core Data on the Desktop. Therefore you can develop a quick and easy app for the desktop that say for example takes the following inputs:
Table/Entity Name
CSV of a row of data
Then it would create a Core Data entity based on the entity name and insert the data into that row.
With that in place it would be trivial to do a bash script to loop through the all of the tables and the rows in those tables to create your new SQLite file.
Hmmm, might have to do a blog post some time on CIMGF about this :)
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.