The two main options, as you said (and as mentioning in that OS question), sane:
- Save the file to disk and save the path to the image in Core Data.
- Save image file binary to Core Data.
I must say I agree with Dave Delong and I think the option #1 is best by allow to do lazy loading
of the image.
An interesting use example is to save the URL to the image in Core Data and the first time this image is requested it is cached locally and this URL is replaced by the image path.
Another solution I’ve seen implemented when there’s a business rule of how long the image should remain curly is to save the URL to it and include a field lastUsed
, it is downloaded and saved locally and after this preset time must be downloaded again. This solution minimizes the space used and at the same time keeps the most used images available.
If you choose the option #2 take a look at Core Data Programming Guide and in the question Core Data iPad/iPhone BLOBS vs File system for 20k Pdfs.
Give more details about what you already have.
– Lollipop
I have already implemented all the interface and navigation, and chose the core data to store the data. However I was only a doubt about the storage of the images. What would be these details?
– Tiago Amaral
When you say several, you refer to more or less how many products? If there are many I advise you directory.
– Gian
52 products at the moment and possibly will not get much more than that. Maybe it will reach 70 at most.
– Tiago Amaral
Blz, another thing, these pictures of the products, you’ll want to be backed up with the app for iCloud?
– Gian
No. It is a simple app, just to serve as a catalog, the user will not need to do anything. Just open the app and look. You won’t get images uploaded by the app.
– Tiago Amaral