What type of data storage should I use if I have a list of data that contains 100 objects and each object has its own data?

Question

My plan is to display a list of items alphabetically in a table view that has about 100 items. Each item has an image, a list of times and a description that the tableview will drill down to. What I am struggling with is the correct way to store and load this data. Some have told me that a plist will be too data heavy and that core data is too new. Should I just create arrays?

Answer 1

Serialize it into an Archive using NSCoding Protocol. See Guide. I'd use an NSArray of business objects implementing NSCoding and then just archive them.

Answer 2

You're not clear about what you intend to do with this data. Plists and Core Data are both persistence formats (on disk). Arrays are an in-memory format (and can also be slapped onto disk, I suppose, if that's what you want to do, but inventing your own binary disk format is only something you should consider very rarely, and certainly not in the case you probably have).

In memory, you can probably just use an array (NSArray) and have each element perhaps be an NSDictionary of the other properties relative to that entry. That sounds like the model of your MVC design, which you can then hook up to the table view.

As far as persisting this to disk, it depends on whether 100 items is a fixed amount, a ballpark, or a minimum, etc. Plists (see NSKeyedArchiver) are great for all the data except possibly the raw image data-- you might want to keep those "to the side" as separate image files with filenames in the plist.

I don't know much about Core Data, but it's not that new, and it's not untested, so if it does what you want without much hassle, go for it.

Answer 3

I usually default to Core Data unless I have a compelling reason not to. (Of course, I have learned Core Data so that makes it easy for me to this.)

Core Data has the following advantages:

1. It has an editor in which you can create complex object graphs easily
2. It can generate custom classes for you data model objects.
3. The generated classes are easily modified.
4. Core Data manages the complexity of adding, deleting and saving objects.
5. Core Data makes persisting an object graph almost invisible.
6. NSFetchedResultsController is custom designed to provide data for tables.

100 objects is a small graph that Core Data can handle easily. It's a lot easier to use Core Data than it is to write custom coders to archive custom objects. For exmaple, at present, I have an app with over a dozen major entities each with two or three relationships to other entities. Hand coding all that would be a nightmare.

Core Data has something of a steep learning curve especially if you've never worked with object graphs before but if you're planning on writing a lot of Apple platform software, learning it is well worth the time.