Join Simon Allardice for an in-depth discussion in this video Learning Core Data, part of Core Data for iOS and OS X.
More than any other area of iOS and Cocoa, I'll talk to developers who seem to just hit a brick wall getting started with Core Data and find it difficult to get a handle on this technology. Now let me talk about why for just a moment, because it is easy to approach Core Data the wrong way and end up wasting your time. The first problem is actually with the first question most developers ask, what exactly is Core Data? Because I can answer that, but I end up using phrases that don't really help. I can quote Apple that Core Data is quote a schema-driven object graph management and persistence framework.
This is technically true, but it's not helpful. It doesn't give us any sense of what we need to do and how we would deal with it. The next problem is that most developers will jump into asking questions to try and force an equivalent to something they already know, and I'll always have to answer these with a phrase that begins, "No, but..." So is Core Data a database? No, but it might use one. If they have a Java background, they might ask is Core Data like Hibernate? Again, no, but. Or if they come from .NET, they might ask is it like entity framework, or is it like some other technology you might know on a different platform? And once again, no, but there might be some comparisons sure, because a lot of things deal with the same problem space.
However, this whole approach is doomed from the beginning, and I suggest you avoid it, and don't obsess about trying to make Core Data exactly like something you already know. It isn't. Now if you have ever started to read a tutorial on Core Data, you'll find that most will quickly hit you with architectural diagrams. What's often referred to as the Core Data stack, the technical pieces of this framework, all these new objects we now have access to and how they interact with each other. And you will see this kind of thing a lot in more or less detail, but this like most architectural diagrams is once again technically true but only useful to people who know most of it already.
Whenever you see something like this, you're seeing the result of someone who's worked their way through a technology and is writing about it from the other side. So for them, this diagram is a good compact reminder. It's useful and contextual because they already know which of these things are the most important, which take the most work, what order they are done in a project, which classes they need to care about, and which they don't. And this diagram tells us none of that. So we are not going to do it this way. We are going to take a different approach to learning Core Data. We will see this popular Core Data stack diagram, but we'll see it later on when it helps.
However, let me bring it back for a second, because this diagram does have one thing right, and there is a reason I show it to you now. Now don't worry about what all these names represent right now. Just understand that Core Data is not one piece. It's not one really important class, nor like many other frameworks in Apple development is it a bunch of vaguely-related utility classes you just pick and choose from as you see fit. Instead, Core Data is several large pieces of functionality designed to work together.
It is a machine full of moving parts, objects deeply dependent on other objects that's being handed to you by Apple. And that's what can make it difficult to approach. If we can pull this apart and take it piece by independent piece, it would be much easier, but there are no single parts of Core Data that makes sense all by themselves. It's all or nothing. You try and focus just on one piece, and you'll find it drags all the others along with it, and that makes things a little different when we are learning it. Think about it this way.
When you first learn regular iOS or Cocoa development, or indeed pretty much any programming language, there are ways to smooth the learning curve. You can begin by creating a Hello World application. Then you can make a simple app that works with integers. You can make one with strings. Then you learn how to work with dates. You make an app with one button. You can make an app with a button and a slider. You can slowly learn new objects one by one and grow your knowledge bit by bit, and that kind of learning curve doesn't really stop.
You can go on like this for years, but learning Core Data on the other hand, that's kind of like learning to ride a bicycle. You have to do it all at once, and you have to do it all up front. You don't learn to ride a bicycle by taking it apart. You don't spend a day first just spinning the right pedals and then a day spinning the left pedals and then a day moving the handlebars. You have to do it all together, balancing, steering, pedals, brakes. At some point you will have to get on and do all of it at the same time. Because up until the point where you can do all of these things together, there is actually no benefit to just knowing one part of it. That's the same with Core Data.
There's no benefit to knowing just one part of this. You need all of it working together. What that means is that Core Data is a steep learning curve, although what's tough to see from here is it's a short learning curve. You must have all the pieces in place to make Core Data work at all, but as soon as it is in place you're done. You're rolling. It's all downhill from there. We just need to get over that first hump. There are several things to learn, and we will need to get them all moving at the same time. So what are those things? How do we start? Well, the best way to begin is actually by asking a different first question.
Not what, what exactly is Core Data technically, but first, why? Why does this exist, why was Core Data invented, and what problems is it a solution for?
- Understanding Core Data and object persistence frameworks
- Creating a Core Data project
- Exploring data modeling
- Creating entities, attributes, and relationships
- Creating managed objects
- Fetching in Core Data
- Implementing undo and redo support
- Creating a Core Data Cocoa app without code
- Responding to validation issues
- Converting store types
- Preloading default data
Skill Level Intermediate
Q: In the CoursesViewController.m file, I receive a message that the method dismissModalViewControllerAnimated is no longer supported by Apple. Is there a newer method to use?
A: You may have received the warning that a call to the dismissModalViewControllerAnimated: method is now deprecated.
This is a recently deprecated method, so the code _will_ continue to work using that call, but to remove the warning, change the code from:
to the current recommended version:
[self dismissViewControllerAnimated:YES completion:nil];
It should take care of that message.