Can anyone tell me the best way to create and store data on the iPhone so that the app can read the data but also write to it?
Having tried out all the possibilities that the iPhone platform holds in stock, here’s my opinion.
Property Lists (aka PLISTs) are fine for small amounts of data, but the drawback is that you don’t have random access, you always need to read/write the whole file.
For iWoman I used encodeers/decoders because at that time I thought that SQLite was too difficult. This method basically has you specify in each object how each member variable will be written or read. You also don’t have random access.
But for GeoCorder I tryied out SQLite and now I would not do anything else. I learned the most from the SQLite Books example, copyied most of my data code from there. SQLite driven apps follow the same structure:
- copy a default DB from the app dir to the doc dir if none is present
- initialize the DB by loading all primary keys of your main entity
- load enough data from your main entity to display
- if you load all data the entity will be called “hydrated”, otherwise “dehydrated”
- memory conservation works by releasing all member data that you currently don’t need
- as soon as you create a new entity it is inserted into the DB and the resulting new primary key stored
With OS 3.0 comes Core Data and this will most likely be the standard way to do it beginning in June. I played a little with it and it is very cool, although you lose the ability to customize your table structure. The structure is “subject to change” and Apple wants you to leave all caring for the internal workings of your table structure to them. You only draw the connections in meta-descriptions and XCode does the rest. This will fit 99% of devs.
So my advice is to look into SQLite for data storage and manipulation. This will also work on OS 3.0. If you target OS 3.0 only then Core Data will be the way of the future.