0

I am developing an iOS app that will have a number of images. These images are associated with Show object and Band objects. I am fairly new to iOS development

On the server, the Shows and Bands are associated with a list of images. Currently I am storing the images with the following info:

height:integer width:integer imageType:string imageData:binary

First question is: should there be more?

Secondly, I am persisting the Show and Band objects using Core Data. I do not want to persist the images because I would quickly run out of memory. I will store them in the cache directory. My second question is: how should the Show and Band objects keep track of the images? Should I have a Image objects in the model with a to many relationship with Shows and Bands. But these Image objects would perhaps only contain height, width, imageType and a path to where the cached image should be. My idea is that if it is not found in the cache directory, it gets the imageData from the server.

What is the right way to do this?

UPDATE

I also plan on pinging the server with HEAD to check if the imageData has been updated before getting the cached version.

JonathanC
  • 967
  • 11
  • 30

1 Answers1

1

you can actually just store the images directly with Core Data and not have to mess with documents at all.

This has been answered in other places but I'll put the code here anyway:

To save:

NSData *imageData = UIImagePNGRepresentation(yourUIImage);
[newManagedObject setValue:imageData forKey:@"image"];

and to load:

NSManagedObject *selectedObject = [[self fetchedResultsController] objectAtIndexPath:indexPath];
UIImage *image = [UIImage imageWithData:[selectedObject valueForKey:@"image"]];
[[newCustomer yourImageView] setImage:image];

The way you should model your data depends on what kind of relationship the images will have with bands/shows.

Do shows and bands each relate to multiple images? Can a show have images that are related to multiple bands?

Ultimately you may want to have an Image Core Data entity that will have a one-one or one-many relationship with bands/shows depending on your answers to these questions. You will also want to add the inverse relationship so that for example when you look up a show, you can also access the set of images associated with it.

It might be easier to help you if you provide more detail about the relationships between your objects.

Dima
  • 23,484
  • 6
  • 56
  • 83
  • Thanks for the info. I thought of doing that, however, my fear is that I don't want to persist so much data. I expect that the user will be perusing through a number of bands and shows which will cause an accumulation of these images. If I use your approach, how do you suggest I deal with an accumulation of too much data? – JonathanC Jun 23 '12 at 22:34
  • I'm not sure how the other approach gets around that problem. Either way, the images are getting saved and taking up memory. If you want the images to be accessible locally then there isn't a way around that. You could create a temporary cache and just hang onto the images each time without persisting them, but then you would have to fetch them every time. That may be the best solution if you expect to have a huge number of images (like a social networking app) – Dima Jun 23 '12 at 22:44
  • I believe that the approach I describe allows the OS to clear the cache if it gets a bit heavy. I do have a large enough number of photos that I don't want to persist them. Still, I don't have enough to justify loading them up each time. I am expecting to have some offline functionality. – JonathanC Jun 23 '12 at 23:07
  • 1
    You can actually clear the cache in both cases but there do seem to be advantages and disadvantages for both. I actually found [this](http://biasedbit.com/filesystem-vs-coredata-image-cache/) blog post which provides a performance comparison between the two. – Dima Jun 25 '12 at 13:26