
You should use Core Data - easonchan42
http://sealedabstract.com/code/you-should-use-core-data/
======
dguaraglia
Wouldn't Objective-C's "library management" be the same as C's? Wouldn't you
include the source files in your project, add the header files to the proper
path somewhere and be done with it? People developing software in C and C++
have been doing this for decades without much of a problem, I can't understand
how all of a sudden this is a "dependency nightmare".

Recommending to roll your own solution for every new problem goes directly
against the last 20 years of evolution in the software development industry.
It's like the other conclusion some iOS developers seem to arrive to: "you
should debug by logging because XCode's debugger sucks". Another 20 year
regression.

I'm just confused. Is XCode singlehandedly messing up the minds of a whole
generation of developers?

EDIT: removed profanity.

~~~
Aqua_Geek
> Is XCode singlehandedly [messing] up the minds of a whole generation of
> developers?

No. I think the situation is more that there are a LOT of people jumping into
iOS development without a programming background (let alone a strong
background in Objective-C).

------
Aqua_Geek
> if you are saving more than 3 objects to disk without linking to
> CoreData.framework, you’re doing it wrong.

That's a pretty broad stroke (that I'm, admittedly, unfairly singling out).

Core Data works great in apps where you're dealing with a limited number of
entities and displaying them in table views full of repeated cells
(NSFetchedResultsController FTW!).

Once your entity graph gets fairly complex, however, things start to fall
apart rather quickly. Child contexts? In theory, they're awesome. But we've
ran into a number of nasty cases where objects were getting over-released on
cleanup of the context. Error messages are less than helpful, merging model
changes is a nightmare, batch deletion sucks, splitting data into multiple
stores is way too complex - the list goes on.

The biggest problem I have with Core Data is that there is just not enough
"best practices"-type documentation out there. The WWDC videos and everything
else from Apple do a good job of getting people to get in the pool. But then
you have a pool full of people who don't know how to swim and are now
drowning.

Two weeks ago, I rewrote a third party library, because it didn't account for
the fact that the app itself might be using Core Data as well (shock!). Among
many other things, it was grabbing any model files it could find in the whole
app bundle instead of specifically searching for its own, causing migration
issues.

The sooner Apple admits that Core Data is a mess and moves on, the better off
the ecosystem will be.

~~~
icodestuff
> Child contexts? In theory, they're awesome. But we've ran into a number of
> nasty cases where objects were getting over-released on cleanup of the
> context.

This is a known ARC bug. Implement -dealloc and nil out the managed object
ivar (or property) and MOC ivar (or property), in that order.

> The biggest problem I have with Core Data is that there is just not enough
> "best practices"-type documentation out there.

I wholeheartedly agree.

------
tl
I was going to give a point-by-point on why this article is just plain wrong,
but then I came across this gem:

> It’s a corner case. Corner cases exist, and if you’re in one, don’t use Core
> Data.

The problem here with Core Data is that it's not a piecemeal solution. You
either use it or you don't, so when you run into something the Core Data
doesn't do properly (like bulk delete, or bulk anything really), you're stuck.

~~~
dguaraglia
I'm appalled by this article, as explained in my comment not two minutes ago.
I wonder if this is just a terrible article of the mindset of a whole
industry. I have first hand experience with iOS developers doing _exactly_
what the article describes. Is XCode/Cocoa development the next PHP?

