Tips for converting an iPhone 2.x app to 3.0 with Core Data

Question

I have an app developed for iPhone OS 2.x. For the obvious reasons, the model classes in that app were written without Core Data.

Now that 3.x is available, I'd like to know what are some of my options for taking my existing model classes and rebuilding them with Core Data. I do many things with my models besides the obvious, such as serializing them and storing them into an sqlite3 database so that my application can work when there isn't any network connectivity. I would expect Core Data to be able to help me with that as well.

Also, with the incorporation of Core Data in your application, is there any reason at all to still use sqlite3? Would you still use it for things such as providing for offline content, keeping around statistics that might not necessarily make sense to create a model out of? Or is there ways of incorporating all of that into Core Data as well?

Answer 1

The primary benefits I've found from using Core Data in my iPhone applications are:

• Keeping referential integrity
• Managed model migration on schema changes
• providing an object relational mapping
• Vastly simplified insertion and join and query process - joins for instance are typically just done through "dotted" syntax
• Multiple store overlaying (although look for my stackoverflow question about this to see if it actually works on sqllite, still awaiting response...)
• Structured predicate construction - you can create your predicates as objects instead of inline embedded sql statements
• Reflective data store - you can introspect the data store at run time in a structured and statically analyzable way

That said, if your app already has been designed to work against a sqllite database, you really need to ask yourself if you're ready to convert your application over.

You will need to do at least these things:

• Remodel your entire database schema in Core Data managed object models
• Rewrite all of your database queries and management to use Core Data
• Rewrite all of your models to either be backed by Core Data generated managed objects, or extending them
• Import all of your existing data by hand into your Core Data database
• Be prepared for potentially writing a lot more code! Although Core Data provides a good object framework for dealing with data store querying and management, it also does so at the expense of verbosity.
• To continue the previous point, when you do even relatively minor changes to your schema, you're going to be prepared to spend a relatively significant amount of time providing a schema mapping and applying it correctly to your existing schemas.

Give you already have solved almost all of these issues already, the benefit you would get form porting an existing application to Core Data is elegance and keeping up with latest technology. You will have to provide a not insignificant amount of effort to get that, and given the benefits probably aren't stupendous, you might find it not really worth your while.

To answer your second question, I can't really think of any reason for using sqllite directly if you are using Core Data to be honest. I'm not certain that outer joins are terribly simple in Core Data for instance. However, you don't typically use Core Data in that manner - you would use it procedurally to craft the same effect as the outer join in SQL.

For statistics and stuff I would still use Core Data because it provides some fantastic aggregation functionality.

Note there is nothing preventing you from taking the opposite approach: adopt Core Data for extended functionality until you become comfortable enough with it, then begin porting your main applications existing code to use Core Data.

Answer 2

The other answer is very good, but I disagree on the benefits being mainly elegance and keeping up with technology... the real reason to move to Core Data is actually performance and memory related, in the Core Data manages caching very intelligently and you'd have to do a lot of work to replicate that. That to me is the sole reason to even consider it, as it is very verbose as noted and you also have to work around all data objects needing to use NSNumber to hold primitive values (which I find particularly annoying).

For something like your setup, the approach I'd probably take for migration is to have each model class hold on to managed objects that are actually the storage classes - then your whole code would not have to change, just some things in the model objects and possibly management classes you might have built to handle creation or population of the model objects. That even hides the NSNumber wrapped primitive issue.

If you are strongly considering working with Core Data, you may want to take a look at this book that covers the iPhone specific Core Data as well (including NSFetchedResultsController):

http://www.pragprog.com/titles/mzcd/core-data

You can buy an e-book only unlocked PDF version which is not too expensive...