views:

1246

answers:

7

I've been doing iPhone development for the last 5 months or so, and have been using Gus Mueller's FMDB for database interaction. My next project will have both a Mac and an iPhone application, and they will share data between them, although in the end, the iPhone will be mostly a viewer app, with some minor editing capabilities.

My question is this: Will Core Data make my life easy enough on the Mac side, that it would be worth it to write my data model twice, using Core Data on the Mac, and FMDB on the iPhone? Or should I just use FMDB for both so that I can reuse the same code for both the Mac and iPhone?

I've poked at Core Data a little, but not much (mostly just the examples in the Hillegas book), so any specific examples in favor of Core Data would be greatly appreciated. For the record, I really like FMDB, I'm just wondering if Core Data would make my life that much easier in this situation.

Edit: I understand the core differences between FMDB and Core Data, I'm mostly looking to find out if what Core Data provides "for free" makes it worth coding my data model twice.

+12  A: 

The main difference is that FMDB is an Obj-C wrapper for SQLite, whereas CoreData is an object model that happens to store data in SQLite (you're not editing a database but instead editing objects). This means that it's a bit higher level and provides more abstraction, but if you know what you're doing with databases then you should be fine with either. Personally I'd err on the side of sharing code as it results in less bugs, easier development and faster releases.

Martin Pilkington
+1  A: 

I agree with Martin. If you were only writing a desktop app, I'd say go with Core Data. Since you're doing both, the possibility of problems when trying to convert between storage models really points to using FMDB for both desktop and phone.

August
+1  A: 

Code sharing is good, but depending on how similar your model and model controller classes are, you may not want to totally discount Core Data. For example, in addition to object persistence you also get really good undo/redo support "for free". You may want to do a quick prototype to judge how much code you might end up rewriting between the two applications.

Marc Charbonneau
+4  A: 

You may also want to investigate the OmniDataObjects framework from the OmniGroup. It implements a subset of the CoreData functionality on top of SQLite on both OS X and iPhone OS. I believe they used it in both the OS X and iPhone versions of OmniFocus.

Barry Wark
+1  A: 

The advantages of Core Data are that it is an object graph management framework that happens to persist to an SQLite (or binary or XML or custom) data store. As such, it manages faulting of individual object instances and bidirectional (including to-many) relationships between objects (including several options for propagating or denying deletions based on those relationships) as well as verifying constraints on individual object properties and relationships (including required/optional, cardinality, range, etc.). In OS X 10.5, it also includes tools for semi-automatically migrating data stores between model schema.

The downside, of course, is that it's not available on the iPhone. If FMDB meets your needs, you may have a much easier time managing a single code base rather than two.

One final option, if you can require Leopard for your desktop app is to write an NSAtomicStore subclass using FMDB. An NSAtomicStore would have to read the entire store into memory—thus you would loose some of the benefits of SQLite on the desktop client—but since the data will be shared on an iPhone, I'd guess you won't have that much data anyways. With this approach, you can use Core Data on the client side and FMDB on the iPhone with a common data model/data store across both.

Barry Wark
A: 

I do not know what type of data your project involves, but if it deals with records of people in any way, and if the number of records is reasonably small, you also have the possibility of using the built in address book (ABAddressBook class) as a database.

It let's you add properties that are unique to your app (which are not visible in other apps that don't use them) and you get syncing between the iPhone and mac absoutely for free.

Gregor
+1  A: 

So, this might be completely solved by now, but for posterity I'd like to mention that with iPhone OS 3.0, Core Data is on the iPhone and if you're looking to use it in your Mac apps, you can share a lot of the work with your iPhone app.

Jeff Kelley