Reputation: 1218
I'm going to write recipe application. What's the best way to store configuration (list of recipes) in iOS4? XML, JSON files, Core Data or something other?
Upvotes: 2
Views: 150
Reputation: 1398
I'd use SQLite. Although CoreData has a few advantages in retrieval it is a bit difficult to actually load your data into the data store. You can even use something like FMDB to wrap SQLite, if that makes things easier for you.
Since the recipes will be HTML, I'd just store them in a single column, with additional columns for the category, keywords, image BLOB, etc. I'd also include a column for storing the user's personal notes about each recipe.
If your recipes were more structured, I'd store them within the database as JSON, because I find XML a nuisance to deal with on iOS.
Upvotes: 2
Reputation: 12366
First of all this depends on where the data is initially stored. Will your recipe app be self-consistent, that is will it contain all receipts bundled in the app or will it download them from the network based on user interactions? (e.g. searching for regional receipts, or seasonal receipts, and so on).
In such case you will download the receipts from the network by request. The best way to store them is leave them dynamically in memory while the app is running (memory cache). You will purge the memory cache as soon as there is some low memory pressure. Receipts loading will be lazy as if the receipt is in the memory cache it will be retrieved from it, if missing (because never loaded or purged) it will be retrieved from the network again. A great improvement can be achieved by setting up a network disk cache (using standard Cocoa caching system or some open source framework such as MKNetworkKit or ASIHTTPRequest). In such case the receipt will be retrieved in this order: memory cache, disk cache, network. The app will then work offline (only for receipts that have been loaded yet), and you will never need to worry about receipts storage as the disk cache will take care of this.
Typically a receipts memory graph could be slightly more complex than a simple "array" of receipts. You can have a receipts table ("entity"), an ingredients table, a restaurants table if you link this receipt to restaurants that offer it, a photography table and so on. In such case the complexity of the object graph is such that CoreData is the better solution. You will not care of the persistent store (typically SQLite and managed by CoreData framework). You may need to pre-load the CoreData store at start-up, this can be done using a "dev app" that reads the original data source (xml, json, csv), creates the managed objects and save them in the CoreData storage. Then you will get the resulting file and you will save it in your bundle. An extra complexity may arrive if you want to keep your app up to date with new receipts taken from the network, without releasing an app update each time. In such case the best flow is: - put the CoreData storage in the app bundle - at first start up, copy it in the app sandboxed documents area (or app Library/Caches if you don't want to add extra backup space to the user; then protect this area against OS cache automatic cleaning) - each time your app retrieves new receipts from the network (automatically or from In App Purchase) parse the received data (xml, json, csv, ...) and save it in your CoreData storage.
This suggestion is not coming from guesses but real experience. I have developed several receipt apps, especially online ones.
Upvotes: 2
Reputation: 4159
IMHO I'd use SQLITE, cause it is easy to use and you always have access to well organized data.
Upvotes: 1