plists vs Core Data for holding parameters

Question

I am writing an iPad app that will be expandable with new items via in-app purchasing. For example, my current plan is to have a jpg pattern and a matching plist file with the parameters I need to expand that pattern into a full picture.

The user will select one jpg/png from a list of small thumbnails - the list is held in Core Data - and the app will find the matching plist for displaying the jpg/png correctly. I'll only have about 10 of these open at one time. But I could end up with storing 1000s of jpgs and plists.

Does storage of lots of small files cause app problems?

I'm going the plist way, rather than storing the parameters in Core Data, so that if I need to add parameters later, I don't have to migrate the database, just change the access in code. (And when I'm creating the patterns, it's easier to concentrate on a plist file rather than a Core Data row.)

The app seems to work really well at the moment, but I'm worried about futures...

My app does also use Core Data for other things, so I could change over if the app will get bogged down with number of files.

Thanks.

Answer 1

Saving a large number of small files is not a problem as long as you have a well thought out means of naming and tracking the files.

Remember that the user does not have the same flexibility and ease of file management on a mobile as they do on non-mobile platforms. Designs that work on non-mobiles are unworkable on a device used on the move with one finger.

However, when you say:

And when I'm creating the patterns, it's easier to concentrate on a plist file rather than a Core Data row.

... the use of "row" suggest that you haven't fully grasped Core Data's utility. Core Data doesn't use rows, columns, tables or joins. It's an object graph management system that sometimes uses SQL way behind the scenes.

Core Data is designed to handle data in a way that meshes seamlessly with the rest of the object oriented API for the UI and other services. When you use other data management systems like plist, you will most likely end up manually duplicating a lot of Core Data's functionality anyway.