BebopSong asks:
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.
Categories: Q&A
SQLiteBooks makes the hair on the back of my neck stand up. When I want to file/store a book, I give the book to a librarian (or send the book to a library) — I don’t tell the book to store itself! Heck, it would be slightly better if I did tell the book to store itself, if I at least told it how/where to store itself.
Depends on the sample you are looking at, there are now two SQLite Books, one for pre-3.0 and one for Core Data with 3.0.
You ARE telling the book where it’s going to be stored by passing the “opaque DB reference” to it. But you are right, somehow we are telling the book to walk the rest of the way itself. And it does.
Interesting, SQLiteBooks that uses core data! I *never* would have looked for core data use in something called “SQLite” … I’ll have to check this out. Thanks for the heads up. I think the whole hydrate/dehydrate stuff might work better with the core data model.
Regarding the opaque reference — right — but again, why does the book have to be tied to a (single) library? I guess what I’m saying is: To me, a library could have the capability of storing more than one type of thing — say books, magazines, movies, cd/dvds/etc. So, now if we want to change how the library stores things — seems to me that we’d change the library — instead, now we have to update the book, the magazine, the movie, the cd/dvd, etc. I do understand the model and the concept, I just personally don’t like it.
Even on a low memory device, I think if you’re that worried about memory use, there are probably even better ways to organize the data.
So, to me, that leaves this method stuck in between use-cases and has the undesirable baggage to boot.