Question

I'm fairly new to iOS programming and am struggling to decide on what is the best way to encode memory intensive objects using the NSCoding protocol.

I have a large number of Item objects. Each Item has numerous hi-res images associated with it. Additionally, each Item belongs to an ItemCategory, which may contain 100 Items.

As far as I can tell, I have a couple different encoding options:

  1. Encode the entire ItemCategory object
  2. Eliminate the ItemCategory class, create just an itemCategory property for each Item, and just encode the individual Item objects.

It seems to me that #1 would be wastefully expensive. In order to add a new Item to the ItemCategory, I'd have to decode the entire ItemCategory (which means decoding those hundreds of images tied to the Items it contains as well), add the Item, and then re-encode the whole thing (again, along with all those images).

But, #1 does seem to be the correct way to do it from a code-structure point of view. #2 forces me to come up with a less intuitive way for storing Items and associating them with their respective ItemCategories.

If I were to go with #1, is there a way to decode only certain parts of objects, so that I don't end up with all those images getting initialized when I don't actually need to display them? One thought that occurred to me is to not actually encode the Item's UIImages along with the Item itself, but rather just the image name. That way, the image would only get initialized when necessary, and could be released without releasing the entire Item if so desired. I suppose this is kind of a relational database type of approach.

I feel like there must be a standard way for handling a situation like this, no?

Or is my fear over memory consumption unfounded? Perhaps this could be seen as an example of "premature optimization", but the decision I make now will deeply affect the data structure of the application. Changing from option #1 to #2 down the road wouldnt be pretty :)

Was it helpful?

Solution

Perhaps you can use CoreData, and a persistentStore. CoreData makes it easy to manage relationships. You can create entities that have relationships that are managed by the system. So in your case, perhaps you can have an 3 entities: Category, Item, and Images, and a one to many relationship between Category and items, and a one to many relationship between Item and images, meaning that each category can have multiple items, and each item has multiple images, then when you need yo you can create new images and add them to a particular item, or search for all the images within an item.

I hope that this was clear, but CoreData is great for managing relationships and the data model is very easy to work with.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top