49

I'm working on my 2nd iPhone app and am curious about Core Data. Time on the project is limited, as is my time overall.

I'm the only dev and I have a feeling that Core Data would be useful but I can't clearly explain why.

Please excuse the following obfuscation .. the app needs to retrieve a list of foos from a central server. Users can then add a bar, from a list of bars, to the foos, then add a baz from a list of bazes(!?) to the bar, then add some optional photo and description to the baz.

Once the user is happy with their bar and baz work they then hit a sync button to upload their data back to the central server.

As you can see, it's a simple data driven drill down app, but I'm still not sure I can justify using Core Data with our time constraints - the learning curve looks steep.

If argue to my boss that we should be using Core Data, what bullet points can I shoot at him? Logic grenades are also appreciated.

nikkumang
  • 1,615
  • 2
  • 17
  • 34
  • 2
    Nothing to add beyond what has already been said, but wanted to mention: I asked this same question once upon a time. Today I can't imagine building an app without Core Data. The relationship modeling alone is priceless. It's so worth the trouble. – Danilo Campos Dec 11 '09 at 09:49

7 Answers7

60

Core Data will mainly help in the auxiliary facets of the application - things like data persistence, presentation, etc. Some bullet points for your boss:

  • Core Data manages save and undo functionality for you. It has a persistent store, which tracks changes, and can be flushed to the disk automatically at any number of times (app close, etc.).
  • Core Data and related classes provide easy ways to get your entities into UITableViews, like NSFetchedResultsController.
  • Core Data abstracts away a lot of the messy things you'd otherwise have to deal with yourself, such as lists of objects, one-to-many or many-to-many relationships, or constraints on object attributes, into a single nice clean object-oriented interface.
  • Core Data comes with a nice graphical object model editor that can help you think through your object/entity design, and refine it as you go. (It also supports migration, so if you decide later that you want different attributes on your entities, you can do that relatively easily.)

Sure, the learning curve may be a bit steep, but the Apple examples are great to start with, and the Core Data documentation is very complete and helpful. Once you've got Core Data down, it'll be a breeze to build your app.

Tim
  • 59,527
  • 19
  • 156
  • 165
  • 8
    Add to the list the fact that Core Data in many cases can have better performance than raw SQLite, both CPU- and memory-wise. Using batched fetching with your NSFetchedResultsController is one line of code, yet it can lead to significant performance gains. I've seen Core Data beat even hand-tuned SQLite code on desktop applications, and I'm sure that performance was a priority when bringing it over to the iPhone. – Brad Larson Dec 11 '09 at 00:06
  • The learning curve is definitely steep, and its stopping me from doing simple tasks such as, retrieve a list of products in autocompletion based on the product code numbers typed in so far. Does something as simple as that require the use of Core Data technologies or will using SQLite be fine? I'm just hoping I dont lose any performance in choosing the latter. I am familiar with SQL style coding, and would have fetched all products at startup, and then filtered the products with predicates displaying the set that start with the product number typed in so far. Is that the way to go about it? – Pavan Apr 27 '14 at 02:24
  • The above is a feature requirement for one of the applications I'm creating, and I'm preventing the need to contact a web server since autocompletion would respond slowly, hence local storage being the viable option. But which is better for my purposes? Then I present scenario 2) for app number 2, all it will do is store biometric finger print data locally in a `blob` field x 3000 regstered users, and when a user swipes his finger on my fingerprint machine, the fingerprint returned will need to be matched against every fingerprint template saved in the DB. Is Core Data better here or SQLite? – Pavan Apr 27 '14 at 02:30
8

To leverage CoreData, you'll need to know a fair amount of Cocoa technologies, concepts, and patterns. The learning curve is not really steep if you know these things. If it looks steep, I would avoid making it critical to your project, and then just learn during downtime, finally using it once you are comfortable with it. It is definitely not a beginner technology; you'll need a good programming foundation, including Cocoa specific technologies and concepts. A lot of people see it and think it will be easy for them, because they would, could get a lot for free. It's like a code generator, pretty close to useless to somebody who uses it to do just that (churn out code), rather than using it skillfully in response to the problem set.

justin
  • 104,054
  • 14
  • 179
  • 226
6

As far as the learning curve goes, I don't think it's as bad as you think. Using Apple's example classes and default CoreData project template, I was able to have a working CoreData app (fairly simple, but not trivial) up in a single afternoon, and it only took a couple days of playing around with the code before I had a really good understanding of what all the moving parts were (all while developing the rest of the app, so no time was wasted in tinkering).

CoreData works very...logically, I guess, and it's incredibly convenient. It saves you a lot of overhead, and I know it certainly saved me a lot of time writing that app. The short initial investment in learning the new technology was well worth it in the long run, now that I have such a powerful tool in my holster.

Ian Henry
  • 22,255
  • 4
  • 50
  • 61
4

I'm still in the X-Code 101 range of knowledge, but the first app I undertook on my own used core data (after reading a good tutorial).

There is a lot of boilerplate software that comes already written in the empty app template, but the actual programmer interaction with the data base functionality is minimal and straightforward.

Give it a shot: it's easier than you think.

Pavan
  • 17,840
  • 8
  • 59
  • 100
John R Doner
  • 2,242
  • 8
  • 30
  • 36
3

A Core Data managed object can have all its data saved to database and is only referenced as an ID in memory. Thus Core Data can save lots of memory especially when you have lots of model data. Once you use Core Data you don't even need to worry about model data memory problems anymore.

jack
  • 731
  • 7
  • 8
  • I'm not sure exactly what you are trying to say with this answer but perhaps you should rather talk about Core Data's faulting mechanisms. Thats more powerful than simply asserting that a fetch only returns objectID's. You most definitely do need to worry about memory problems because you can create strong reference cycles in Core Data if you access the reverse relationship on a managedObject. Thats why the refreshObject:mergeChanges: method exists – Daniel Galasko Jan 21 '15 at 09:09
1

You have a couple of different options for a persistent local store, but you would need to use one of them anyway so why not use Core Data?

As for learning curve, there are applications in the examples that will help you here. It's pretty straightforward once you walk through the samples.

-t

Tim
  • 2,794
  • 1
  • 17
  • 10
0

The other answers here do a good job of explaining why you might use core data, but as its learning curve seems to be a common concern, it might be useful for those who stumble upon this question to know that there is an alternative with a considerably "less steep" learning curve: Realm.

Here is a brief Quora post on why you might consider Realm over Core Data: https://www.quora.com/Why-would-you-use-Realm-over-Core-Data

kcstricks
  • 1,489
  • 3
  • 17
  • 32