Core Data seems to add a needless layer of complexity. If you want to save data created natively by the user in an app why not just use an object and then write the data all to SQLite or back to a server using a RESTful script if necessary.

Android doesn't have Core Data (though if it has something similar I haven't seen it.). What the heck is the point of buggy CD except useless needless overhead for people who can't write SQL or CGI scripts?

  • 2
    I think you're in the wrong place. This isn't "post a rant." – Robert Harvey Nov 7 '13 at 23:51
  • 2
    I don't think it's a rant at all. I think it's a completely fair question. Android doesn't have it and it can be assumed that Google went through a reasoned discussion about it. So what is it's usefulness in Objective-C. I don't have to be passionless about technology I use often. I think passion is essential to product design and technology. – Curtis Sumpter Nov 7 '13 at 23:56
  • 1
    That may not be the most logical conclusion. That's like saying, "Well Galileo, of course you think the Earth revolves around the sun. You 'discovered' it." Just because a person defends what they say doesn't thereby decrease it's merit. – Curtis Sumpter Nov 7 '13 at 23:58
  • 1
    @CurtisSumpter I complete agree about prefering fewer levels of data abstraction... but this is clearly a rant. – GrandmasterB Nov 8 '13 at 0:01
  • 3
    You apparently have frequented places on the Internet where hyperbole gets you more attention. That approach doesn't work well here. – Robert Harvey Nov 8 '13 at 0:04

You absolutely could write SQL queries and store whatever data you need in a SQLite database or just write raw data to a file. In fact you are free to do so right now in an iOS app. Why then might we want a different abstraction?

Immediately you're going to notice that your application is working with objects and you need to translate them into some form you can write to your data store. You might just write a bunch of raw bytes from memory to disk but that will be very hard to reconstruct back into an object of the appropriate type and as soon as you change an object's structure your data will be even more difficult to recover. Instead you'll probably decide to serialize the object into some more reasonable form. That works well if you just want to write to a file but then it is hard to selectively reconstruct objects. No problem, you store data in sqlite in a form you can query on and now you can quickly search for and load specific objects. Of course its inconvenient to have every class in your app handle a bunch of database reads and writes, you probably want some service which can automate mapping classes to tables and objects to rows in those tables. Now you've build your own object-relational mapping library.

Mapping objects to rows in tables is a good start but some of your objects contain other child objects so you end up needing to save and load entire graphs of objects at a time. That's ok with a little work you can handle that too.

Oh and it would be nice if you could double check that your data is valid before you actually save it so you might add some rules to prevent saving invalid objects to the database.

Your ORM library works great but as you keep working on the app you discover that you need to change some of your objects. That means you need to change how they are represented in the database too. Now you need to define some process for migrating an old database schema to a new one.

As your app grows it becomes infeasible to store all of the results of some of your queries in memory. You solve that with a clever scheme for just loading a few objects at a time as they are needed.

Then you discover that users sometimes want to undo their changes. You could store each change as a row in a table but after doing that a couple of times you realize that your data storage service could automatically keep track of changes for you.

Now you have a pretty powerful tool for managing persisted objects in your application. Its so handy it would be nice if you could use it in other situations too, like for objects you just want to keep in memory and not write to a database. Of course then it would be even better if you could choose to move some of those objects over into the database later.

You have now reinvented most of CoreData. An attempt to build a fairly general purpose tool for persisting objects and managing common operations around their persistence. You don't use it for everything but it's awfully handy to pull into your apps as soon as they have some non-trivial requirements around how they manage data.

  • I get the gist of what you're saying but it's nuanced. I'll have to think it over and really dissect it to understand it in a mid-level fashion (as the explanation is conceptual as it should be). But thanks for the answer. I just read it once but I look forward to digging into it. Thanks again Jonah. – Curtis Sumpter Nov 8 '13 at 0:31
  • It's an explanation that's really worth digging into. I think I'll become a better programmer because of it. Thanks again. – Curtis Sumpter Nov 8 '13 at 0:32
  • No problem, hopefully the answer makes sense even if you haven't already felt pain from encountering a need for these sort of features in your app. A shorter answer might have been to counter with "why use UIViews instead of just drawing pixels directly to the screen". Sure you can do that yourself and at a lower level the framework does but it would quickly become inconvenient and unsustainable. – Jonah Nov 8 '13 at 0:34
  • While I appreciate your long form answer and look forward to dissecting it your comment seems to suggest that questioning Core Data questions OOP and persistence generally. I think the programmers of Android would beg to differ. – Curtis Sumpter Nov 8 '13 at 0:44
  • 1
    @CurtisSumpter that's certainly not my intent. CoreData is a specific solution to a general set of problems. Android programmers encounter the same problems and solve them with different tools. The same way Android Views or iOS UIViews or drawing in an openGL context are all tools to solve a similar set of problems. Apps which persist data often have similar needs, CoreData tries to solve some of those common problems. If you understand them then you can judge if it is a useful solution. – Jonah Nov 8 '13 at 0:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.