views:

124

answers:

6

I have been thinking of saving data using dictionaries and arrays etc. Would it not be more efficient to use a database and just read and write to it rather than running through arrays, getting keys and values, blah blah? It will need to hold a lot of text that is it.

How is the database setup and used on the iphone?

Also , if one writes to a database during app runtime does it store? What I mean is that there is no serialization needed etc.?

+1  A: 

Look into Core Data.

If you want to go lower level, there is SQLite.

Kalle
+5  A: 

There is a lot of information on the Apple iPhone developer site about implementing Core Data, the framework for storing stuff in a relational database. Like this introduction.

In fact, there's also a ton of information on stack overflow about it. I suggest that you read through questions tagged with core data if you're having a specific problem.

However, I'm not certain that your assumption that core data is faster than serializing NSObjects is correct. There is a lot of overhead in learning how core data works which takes time. Serialization of dictionaries and arrays only requires you to learn a couple methods. It really depends on the needs of your application, I suppose. More information would be useful.

Some more links: Serialization to plist files (NSArray and NSDictionary only) or keyed archiving (for custom NSObject subclasses).

Nick
I want to have a lot of text which I will write before hand, and then also allow users to add their own info, which will need to added and saved. I am aware of creating databases using java. I was thinking that it would be similar on the iphone. Creating tables, adding removing tuples etc. Using queries to retrieve certain data. I havent read much on how it is done on the iphone, will do that soon. regards
alJaree
It doesn't sound very relational from your description. I would go with serialization of NSObjects into plists or, if you have custom objects, archive files. See my additional links above.
Nick
I didnt want to use it as a relational database, I want to access data faster and have it more organized. But I will look at the links you posted thanks. regards
alJaree
"Access data faster" and "have it more organized" are many times mutually exclusive. I would heavily suggest you look into serialization of NSObjects into plists. I use SQLite3 and serialize data when the SQLite3 tables have not changed (say, in `applicationDidBecomeActive` event). It is a much easier method than going into the SQLite3 tables and rebuilding my objects.
Jann
+4  A: 

You can use core data which by default uses an sqlite store (you can change this easily).

Core Data

If you load up xcode there is a sample project and you can check off use core data so that all the plumbing will be in place. You then open up the .xcdatamodel file and you can use it to design the objects you want to persist.

Codezy
+1  A: 

If you have a lot of data to work with, look at Core Data for all your relational object storage and retrieval needs. NSPredicate makes it a snap to search through and find what you're looking for.

You can use SQlite, but Apple put a lot of work into integrating Core Data with the iPhone UI kit, which can save you a fair amount of development time.

Alex Reynolds
+1  A: 

You can use their database, SQLite. The doc is pretty good for that.

But I like better using web services and an external database. It depends on your application. But if the user change his phone and you were using the phone database SQLite, no more data... Like I said, it's just something to think about, and it depends on your app!

Dachmt
That idea is good, will have that when I know a little more about iphone dev. thanks. :)
alJaree
+1  A: 

There are two main approaches to Data persistence in iPhone. One is CoreData, which is a persistence layer that does the most of serialization for you, the other is SQLite a database, for which you need to do more serialization for yourself.

Look at this question and the linked questions for pros and cons of both techniques.

tonklon