Question

I have some basic questions about core data (which I am new to) and I would like some points of view on current standards and implementations.

Basically I have an app on the iPhone (supporting iOS 3.0 and above) which gets a lot of data from web calls over HTTP, Im looking at moving the results into local storage for fast retrieval for the next time the user might load the same data again (the data doesnt change, which is why I can rely on the cached version be accurate).

I just wanted to know a few things first:

1. Do people these days treat the managed objects that extend NSManagedObject as domain objects, or do you create seperate classes strictly for storage and create helper methods to create them into domain objects? I sometimes find keep all persistence logic out of the domain to be a good thing.

2. What about clean up? How does one typically delete all the data when the app closes, or perhaps, expire data in the local storage? I certainly dont want to hold the data on the users phone at all times.

3. Is there any type of atomicity with Core Data? My implementation will first check for data locally before hitting the web services, I would like to make sure that there is never half a dataset being committed to the local storage and get funny results.

4. I would like to run a fair few background threads to fetch data in the background, are there any things I would need to consider when persisting objects on a background thread?

5. In relation to the above question, what is the best way to create a “background fetching” loop? In the app delegate? Per view, depending on the view? etc…?

I hope these are not too basic 🙂

Thanks for any help you can give.

Answer 1

Do people these days treat the managed
objects that extend NSManagedObject as
domain objects, or do you create
seperate classes strictly for storage
and create helper methods to create
them into domain objects? I sometimes
find keep all persistence logic out of
the domain to be a good thing.

If you create totally independent domain objects, you have the cost of keeping them in sync with your Core Data model, and keeping the translation between core data and these objects working – plus you have duplicate objects in memory, depending on how many objects you have this might be a concern.

However the benefit side of using separate domain objects is that you are no longer wedded to a managed object context. One case where something like that can hurt you is if you maintain references to managed objects and then some background operation causes the main managed object context to remove objects – now if you access any property in the deleted managed object, you trigger a fault exception (even if you have explicitly had the object loaded with no faulted data).

One thing I have tried with moderate success is occasional very lightweight separate data objects for specific uses – what I did was to define a protocol to represent the data object accessors, with the same names as the core data accessors. Then I had both the core data object and a custom standalone data object implement this protocol, and had a mechanism to automatically copy properties from one to the other. So I didn’t do every object as custom, and could treat objects either coming from the local store or standalone interchangeably.

I don’t have a clear preference on this one yet but lean to using the managed objects directly, because of the lack of duplication. You can mitigate bad side effects by listening for changes or using the core data controller class.

One thing that helps to keep domain objects and data objects sort of the same yet not, is using mogenerator to generate data objects. It generates very nice object representations of the objects in your core data store, plus front-end objects you are meant to edit – adding custom accessors, or complex methods to. On changing the data store mogenerator regenerates the data object but leaves your custom code alone.

http://rentzsch.github.com/mogenerator/

What about clean up? How does one
typically delete all the data when the
app closes, or perhaps, expire data in
the local storage? I certainly dont
want to hold the data on the users
phone at all times.

The data is generally small enough that I just leave it there, with an expiration timestamp for use so that you know when the data is too old to use directly. There is a ton of value to keeping data around since users close and reopen applications so frequently, and with data already there you can present results instantly while still fetching content updates.

Is there any type of atomicity with
Core Data? My implementation will
first check for data locally before
hitting the web services, I would like
to make sure that there is never half
a dataset being committed to the local
storage and get funny results.

The atomicity comes in that you perform operations in a context and then tell the context to save. So true atomicity means avoiding other components issuing a save before you are ready, which generally means doing something in its own context and merging back into a master context.

I would like to run a fair few
background threads to fetch data in
the background, are there any things I
would need to consider when persisting
objects on a background thread?

Every background thread needs its own context, you should listen for the save notification and merge into the master context at that time.

You should strive mightily to avoid duplicate requests that might be saving to the same objects nearly at the same time, this can sometimes cause core data errors on merge. Related to that – set a merge policy on your main context as the default policy is to throw an exception.

That also means that in doing modeling, go for as many separate objects as you possibly can rather than one large object that aggregates data from a lot of different sources.

For more information on saving and merging into other contexts, see this question:

CoreData and mergeChangesFromContextDidSaveNotification

In relation to the above question,
what is the best way to create a
“background fetching” loop? In the app
delegate? Per view, depending on the
view? etc…?

I like to do this from a separate singleton class (after all, the AppDelegate itself is a singleton…), that I can ask for the main managed object context in addition to a context specific to a thread.

This is also useful in that when starting a new Core Data project, you don’t have to use the Core Data template and can just re-use this core data manager.