views:

60

answers:

2

I would like to begin work on an iPhone app that does little more than display a books content for reading. The book content is available online, and is fully open source, but I would like to make the content available locally. With apps that I have worked on previously, namely with iPhone OS 2.X, creating (or finding) an .sql database and then just making queries for data from within the app worked really well. With the advent of Core Data (which I am not that familiar with) the older sql method may not be ideal. So my question is: What is the best way for me to go from online web content to locally stored iPhone readable content? Regardless of which approach I take, I am going to need a db (right?), so should I get the brunt of it out of the way and start with importing the web content into a db with all of the correct tables and columns? I guess with this question, I am just looking for a point in the right direction. If there were any suggestions about the best method for me to get rolling on this, it would be greatly appreciated. Thanks!

+1  A: 

Core Data is good if you have "objects" that you want to make persistent. In the case of having just a lot of data to read/write, plain old SQLite may be simpler.

Sorry that I can't give any more specific advice, but it comes down to how complicated your app's data model and object models are. I'd recommend looking at Core Data, but don't use it just because everybody tells you how cool it is.

If you go with Core Data, you won't define your own SQL database schema, so don't start down that path until you've made the decision.

Kristopher Johnson
Hey thanks for your answer, it was very helpful. I think that I am going to go the SQL route.
Steve
Core Data is just an hight level API for persistence data. It makes an abstraction of the DBMS behind. (It can be SQLite, a file management, or other...)
Yannick L.
I also suggest going with Core Data. Not only can it cut out a lot of code in your application, it can also provide performance advantages in terms of speed and memory usage over bare SQLite.
Brad Larson
A prominent iPhone developer wrote a blog post today about his analysis of Core Data performance relative to SQLite: http://inessential.com/2010/02/26/on_switching_away_from_core_data
Kristopher Johnson
The article mentions very specific instances where doing the database yourself is better. It is unlikely that this book application will be doing continuous adds, deletes, or updates. It is more likely it will do periodic inserts of new books, and then mostly reads, which Core Data is good at. From the article "My warning: you probably don’t need to switch away from Core Data. It’s the right answer almost every time."
Brandon Bodnár
I don't understand why anybody can tell the questioner that Core Data is probably the right thing to use. He's told us very little about what his app is going to do, how much data it will be managing, and so forth."Persistent objects" are not the answer for every application that makes use of stored data. I'm not recommending against using Core Data, but think it's silly for people to push it without knowing whether it is a good fit.
Kristopher Johnson
A: 

I actually would go with the Core Data route. Core Data is just an API provided by Apple to manage persistent data no matter the data backend (wether it is a flat plist file, an XML file, or a full sqlite database file).

In the case of a book, you can break down the entities as follows.

Book Entity

  • Title which is a String Attribute
  • Author which is a String Attribute
  • chapters which is a has many relationship of Chapter Entities

Chapter Entity

  • Title which is a String Attribute
  • pages which is a has many relationship of Page Entities

Page Entity

  • PageText which is a String Attribute

Then you can access all the values as if they are objects using Core Data without having to worry about the SQL backend code, and writing all the code to translate the SQLite datatypes to Cocoa objects that your view controllers can display.

Brandon Bodnár