iPhone - different ways to store data, advantages and disadvantages

Could you explain me which are the different ways to store datas on the iPhone, and for each way of doig this, which are the advantages and disadvantages.

I've read many things about UserDefaults, CoreData, XML, plist, ... and I'm a little bit lost.

For now, I understand that :

• UserDefault is for preferences, and is not intended for anything else even if it can be done (small ammount of datas). It generates a plist file that can be easily humanly read/checked later into XCode.

• XML is good for structured text, but not for binary datas. And it's easy to write, but not to read.It generates an XM开发者_如何转开发L file that can be easily humanly read/checked later into XCode.

• CoreData is powerfull, can save anything of any size, but is a little bit hard/long to include. And humanly read coredatas already written is "hard" (possible ?)

SQLite DB - DB Used by iOS development, you can interact with this directly depending on your preferences (e.g. you want to use SQL statements).

CoreData - Abstraction to SQLite DB so you can remove SQL statements and use the API instead. Advantage of this is its compatibility with the Cocoa API. In our production applications we use CoreData over SQLite.

File System - You can store files directly here and use a convention. You might also want to read about using the cache folder iOS development for temporary data.

XML - Case to case. In commercial application, we only use XML for interfacing between systems. E.g. iPad to Cloud server.

UserDefault - only for parameters

Plist files are another option if you want to manage your own storage on the file system. NSArray and NSDictionary provide methods for writing and reading those collections to and from plist files as long as you can store all of your data in one of the supported plist data types. See the Property List Programming Guide for details. It might be a good option if you can easily break up your data into distinct files and always want to load an entire file at once.

CoreData is a powerful tool, especially if you want to store a graph of objects. It might be an appropriate choice when you want to be able to store and load model objects easily.

SQLite is great if you want to store relational data and run queries against it. It might be a good choice if you want fast and efficient queries but don't need to convert the results into model objects (or have some reason for writing your own ORM layer).

As you mentioned NSUserDefaults is a convenient tool for storing user credentials but is not intended for larger volumes of data. It also allows you to expose settings in the settings app so that a user can set application behavior in one common location without launching your app.

Any form of file based storage may have additional value if you want to expose those files to the user through the File Sharing settings, allowing application data to appear in the iTunes Documents directory when synching to a PC.

Regardless of the storage mechanism you use every one of these options requires that you manage some sort of schema for your data.

You need track of the format your data is stored in in every version of your application. Any time you change your expectation of the format of saved data you need to support old versions. I see too many apps crash after an update because they do not handle data saved by old versions of the app or assume that users will have installed and run every version of the app instead of skipping some updates.

CoreData has some support for migrating data from one schema to another but it is something that requires developer work, awareness, and testing in all cases.