[MUSIC] All right, we've built our core data project. Now let's build the model that's gonna support our data storage, our persistence data storage that will keep our data intact over multiple life cycles of our program. The high-level, this is what we're gonna do, we're going to create a model that describes our data structure, this is like creating a database schema. And this is gonna become the basis for our automatic code generation and it's going to be enable Xcode to generate the code for us that correctly handles all the relationships that are present in the data that we want to represent. So let's do that. Just as background, if you're familiar with working with databases, working with the model in Xcode, there's kind of a pretty similar translation between the different terms you might use in Xcode versus in databases. For example, a model in Xcode terminology is like a database schema. An entity is like, on the one hand, in a database world, it's like a table. In object-oriented programming world, it's like a class. So we use those things kinda interchangeably. An attribute is like a column, it is a column in a database table, it is like a property in a class. And then finally, a relationship is like a foreign key in a database schema. It doesn't really have an analog, I guess it's just a reference in an object class, a reference to another object. So there's kind of a mapping between these terms. Then when you create an instance of a particular class in the Java object, that's like putting a particular row into your table or into your entity, all right? So let's remind ourselves what we're doing here. We're looking at creating these three tables, a people, a chore log, and a chores table. I think I'm actually gonna change the names slightly to make it a little bit more clear. And that's gonna support the application that we're working on. All right, so we're going to construct that model. We're going to create the relationships between the models. We're going to create the managed object code, or in fact, we're gonna tell Xcode to do it. And then we're gonna create some helper functions that are gonna enable us to create an object using our managed object context from within our view controller. All right, we're gonna call our AppDelegate from our view controller to get that. So let's do that, let's first construct our model. So to construct the model, you click over here on your .xc data model D file, and you get a different interface, a different graphical user interface, and what you're looking for is down here at the bottom, the place you can start is to add entities. So we're gonna add our first entity and our first entity is going to be our chores. And I'm going to just call it singular chore. We're gonna add one attribute and this is going to be the name of the chore. When we add our attributes we have to give it a type, just like as if we were putting a property into a class. In this case it's gonna be a string. We could put other things in this entity. For example, how much time it takes to do the chore, maybe difficulty of the chore, maybe how much we like the chore, or something. Other different kinds of things we could put there, maybe location where a chore is done. But just for the purposes of representing this relationship, that's sufficient. This is gonna be the list of all the chores that are possible to do. We're also gonna create another entity. This is going to be where we keep the people who can do the chores. So we'll call this entity, we're gonna call it person. And internally, it's going to have several people, every person is going to be in the person entity. And we're also going to give an attribute to this entity, and we're gonna say name for the name of the person. In fact, to mirror what we said with chore name, we'll say person name, and we will use a string for that. Now, examples all over the place show examples of people objects, where you have a first name and a last name and a date of birth, all kinds of other stuff. You can also put that information into this entity if you wanted. But for the purposes of us creating the relationships, we're just gonna make one attribute so that we can connect them. The last entity we need, is we need an entity that represents the fact that a chore was done. And we're gonna call this one the chore log, because it is a record of the chores being done. Now our chore log is slightly different because this is the first place where we're gonna initiate a relationship. For starters, be careful when you select these that the view in the center updates. You can see that I had to click off and click back to clear the view. It's kind of a little bit of a bug in this code. So if I add something to the chore log, the additional attribute that I wanna add is when the chore was done, and that will be a date time. Now, you'd think that I would also want to add the person who did the chore and the chore that was accomplished, but I'm not gonna do that as attributes. I'm gonna manage that as relationships, because I want the values of the person and the chores to be drawn from a table that's being kept separately. This is known as normalization in your database. If we wanna see a different view, we can come down here now to our editor style, and select a visual view. And from here, it would be possible to see all the relationships. So right now we have three different entities, and there's no relationship between them. Chore has chore name, chore log has when, and person has person name, but they're not connected, and I wanna connect them. So I'm gonna go back to our table form based editor. And in chore log, I'm gonna add a relationship. And this relationship is gonna be called the chore_done. And it is going to connect with the chore. So this means it's gonna connect to the chore entity. And that connection is going to be over here, we're gonna specify the kind of connection it is, and it's gonna be to-one. By that I mean that any given chore log only has one chore that was done, right? Person, the other thing we need to do is we need to enter in who did it. So we'll say person_who_did_it. This is awful naming, but it's clear. And this is gonna connect our person table. That's also to-one because every chore log has one chore and one person, and that will be coupled with the date when that person did that chore. Now we need to go to each of the entities that we linked and we need to create a relationship back. We'll call this relationship the chore log relationship. It's going to connect back to the chore log. I'm sorry, yeah, it's gonna connect to the chore log and the inverse relationship is going to be the chore_done. So this is just from the chore's perspective, saying which way do the arrows go? Which way do the dependencies flow? Starting from the tour log it's clearest, and you can see that when we specified our chore_done, our destination was our chore, meaning there's one chore that gets done, and for that chore to find its way back, we need a pointer back. And so, that's the relationship in the chore log. We're gonna do the same thing in person, we're gonna add a relationship to connect back to our Chore log. We'll call this also chore log. Destination will be the chore log, and the inverse relationship, the one that comes to the person is the person who did it. Go back to chore. Now unlike the relationship from chore log to chore, which is, we want our chore log to have one element from our chore. If you go back the other way, one element in chore log can be used many times in the chore table, meaning if you have washing listed in your list of chores, that can be done many times and recorded many times in your chore log. So this relationship is gonna be a one-to-many relationship. Same with person, you may have each person listed only one time in your person table, and every entry in your chore log will only have one person who did it. But for every person in your person table, they may execute many different chores and that means that they'll be listed many times in the chore log, so that's gonna be a one-to-many relationship. Now, if we go back to our visual editor, we could see that relationships have been connected between our tables. And this is what we want. This is going to ensure that we don't have duplicates in our database, we minimize the size of our database because we only list the names of the people once, and we only list the chores one time. The last thing that I wanna do is I want to specify the names of the classes that are gonna be used when these get represented in Xcode. So I'm gonna select chore, and I'm gonna come over here and I'm going to choose up here in the data model inspector, and I'm gonna specify a class name so that I can recognize the code that Xcode has made for me. And I'm just gonna call it chore and I'm going to put MO after it for Managed Object. And for person, I'm gonna do the same thing. I'm gonna say person MO, and for chore log, I'm gonna do the same thing, I'm gonna say chore log MO. All right, so I've created the tables, I've given them attributes, I've create relationships between them. I've specified the nature of those relationships, one-to-one and one-to-many. I've given the classes names that override the default names. Now I wanna tell Xcode to make those classes. So I'm gonna come over here and I'm gonna select the entities. I'm gonna use the editor dropdown, and I'm gonna say, create the NS Managed Object subclasses. And that's gonna create several different classes in my project, one for each of the ones I select, I want them for all of them. Put them into my project, and you see they show up here in the upper left. These are all just representations of those entities that I created in that visual editor. These are the objects that I'm gonna use, that I'm gonna instantiate, that the managed object context is gonna instantiate for me so that I can use them. So we constructed a model, we constructed relationships, and we created the managed object code. Now what I wanna do is create a couple helper functions to just initialize and create those objects for me. And I'm gonna do that in my AppDelegate. That's the one central place in my code where I will get my managed objects from, so let's add that code. So, we do that in my AppDelegate, and I have some template code down here at the bottom that I'll cut and paste. But where I'm gonna put it is I'm gonna put it up here, after I'm done finished launching with options I'll put it right after here. I'll say, just add this in here for reference for me. Call it, My Managed Object Code. This is just basically a comment that gets understood by Xcode. I'm gonna drop in my first template, and this template needs to be fixed because the names have changed to protect the innocent. So we are going to create a chore managed object. All right, so what that's gonna return is it's going to return a chore managed object, which is up here, created from my entity table. All right, that's good. The first thing that I do here in order to get that is I grab my managed object context. To get the managed object context I send a message to myself, that will return the managed object context that I initialized when I first ran my application. There it is. Once I have my managed object context, I am going to get my managed object by asking for a new object for the entity name chore. So this is my table. And that should deliver back to me a new managed object and this managed object is gonna have an entry for the chore name in it. We can even go and see that if we come up here, we can see that in the header file, for this one we can see that the chore name is listed, and here you can see the relationship is there too. You don't have to worry too much about this code cuz it works for you when you use it. All right, then the last thing that we're gonna do is we're going to return the object that we made. Then we're getting a bunch of Xcode errors because this piece of code, when Xcode compiles this code, knows nothing about my chore managed objects. So I'm gonna go up here and I'm gonna go ahead and let it know about my chore managed objects by including the header. If all goes well, everything will compile. Now, when I need a new managed object, instead of and emitting a chore managed object, what I'm going to do is I'm going to come to my AppDelegate, I'm going to call create chore managed object in order to get that code. Now in addition to chore managed object, I'm gonna want to be able to create an object for my person managed object, as well. And, Oops. So we'll cut and paste this code, and update it appropriately. And we will also make it aware up here of the person managed object. All right, compile's good, great. And then the last thing that we wanna do is we wanna create a chore log object that's going to connect a time, a person managed object, and a chore managed object. So we're going to create our chore log managed object. We're gonna get our managed object contacts to do that, we'll create it. Create a variable with the same name but a lowercase letter, and we're gonna access our chore log. And unlike the other two, that one is not compiling correctly. What am I doing wrong here? Oh, I need to include my import, there we go. All right, there we go. So we made our model, we made our relationships, we asked Xcode to generate the managed object code for us. And we created a couple helper functions so that we can get these objects when we want them. Great, so in summary, Core Data has a special set of tools for creating models. That's that graphical and form based entity modeler that we saw. Once you build that model, Xcode will use it just like we saw in our original diagram, Xcode will use that to understand how to create sequel light objects from our Java code. And it'll write that code for us as well. And those objects, those managed objects that we create, are the objects that will be stored persistently on our storage device. [MUSIC]
