CODEWITHSUNDEEP
iphoneobjective-c
hmthur
hmthur

Reputation: 2565

iPhone app with CoreData

I am planning to create an iphone app which uses CoreData. There might be enhancements added later as new versions of the app. My question is; When using CoreData, what are the factors to keep in mind to ensure if the user upgrades the version, his previous data remains intact ? Like I heard we should keep the.sqlite file name same. What are other factors to keep in mind while releasing Core Data apps?

Thank you.

Upvotes: 2

Views: 189

Answers (2)

slycrel
slycrel

Reputation: 4285

One thing we have done is to manage two separate core data databases. First, a "read-only" core data database that gets supplied with app updates (assuming you want to be sending data with the app, if not then don't bother with this part). Second, a local core data database (data store) that's stored on the phone that is initially populated with the data from the first, and then added to by the user or with updates from a server that you control. This second core data store can stay persistent between updates.

For later modification and updates you have two options. You can add additional features in a new core data store as long as you don't need to get at the new data at the same time as the old data. The other option is to use apple's core data migration stuff which you can read more about here.

Here are also some additional resources for gearing up with core data, there are plenty of more specific core data examples on SO.

Finally, if you plan on significantly adding/modifying your core data store I'd suggest looking into SQLite. That's easier to change with updates (in my experience) than migrating an existing core data store to a new schema, especially if the schema changes often.

Upvotes: 1

Matthew Frederick
Matthew Frederick

Reputation: 22305

Data migration concepts are important to understand if you're going to maintain it over time, since you're likely to want to change at least some things eventually.

The ideal is Lightweight Migration, where minor conversion from your old data model to your new one is automatic. As noted in the document, it can take care of itself if your changes are:

  • Simple addition of a new attribute
  • A non-optional attribute becoming optional
  • An optional attribute becoming non-optional, and defining a default value

Renaming an entity or an attribute is also easy and nearly automatic.

Everything beyond that -- new or removed entities, new or removed or changed relationships -- is hairier. It's not incredibly difficult, but it's definitely more work, with more room for failure.

As such, a little speculation about likely potential changes may make it easier and more efficient to provide a little wiggle room in advance. Obviously if you do too much, especially with theoretical-but-currently-unused relationships, you're likely slowing down the current system and potentially for no reason.

Worth consideration.

Upvotes: 2

Related Questions