[MUSIC] I'd like to begin a discussion about Core Data. We'll do a few lectures about different aspects of Core Data in preparation for a peer review assignment where you use it. Core Data is a really powerful set of functionality that iOS has built into and that Xcode supports through the automatic generation of code. The high level, Core Data is a way to store data that lasts beyond your app life cycle. So we call this a persistent storage system and the reason that we say, persistent is because it persists even after your application is out of memory. It is a way of storing data to the device that you can later retrieve. You can think of it in some ways as a file system, but it's much more powerful than that. Because what it is, it is easy way to store objects in a database. You may be familiar with other technology that's like this. Code Data is an example of object relation mapping or ORM that maps Objective-C objects into a SQLite Database that's managed on the file system. It's encrypted by default, it's protected by the user's password and that aspect has been in place since iOS 5. And so, it's a very clean way of storing user data that lasts for a lengthy period of time. What you should think of it as if you're new to this kind of technology is you should think of it as a way of creating complex data relationships and letting the iOS operating system manage their persistence over time. If you do have a lot of this data, especially data that has these complex relationships and you wanted to do this manually, it's a lot of work. It's a lot of work to make sure that your data objects are stored to the file and that they're stored in such a way that you can retrieve them and retrieve all the relationships correctly and build it correctly when you need it, it just takes a lot of time. So it's difficult to both make sure it's saved, it's difficult to load it, it's difficult to create those Objective-C objects that are consistent with the file system. And then if you make a change to the object while you're running your program and you want that change to be reflected with the data stored back on the disk, then it's difficult to write the code that's gonna save it and Core Data makes all of this much easier. Core Data makes it possible to work with objects and those objects can just be saved to disk and you don't need to think very much about the process of saving it once you have described it adequately. So let's take as just a motivating example a house that needs to have some chores done. So here's an example of a sink with a lot of dirty dishes and let's say that you would just like to have a simple app that keeps track of who in your house has done what chores and when. So to do this, we might think of three simple data tables. One that keeps track of the people that do the chores, another that keeps track of the chores that are possible to be done and then another that says that this person did this chore on this date. If we wanted to represent that in an entity diagram, in a way that core data supports, we would come up with a relationships that looks like this. Three different tables. One that has people in them and you can see in that people entity, which is like a database table, it has one attribute, which is the name of the person. And that's a string, so you can think of this a little bit like a class. There is a entity called people, there's an attribute called name. It has a property of being, it is the type, a string type. On the other side, you have chores. And the chores, there's a chore name. That's one of the attributes and that's a string. You can't see that it's a string from this diagram, but it is. And in the middle, you have a chore log. And the chore log has its own attribute, which is this date variable called when and that captures when a particular person did a particular chore. And you can see that we have this relationship between the people and the chores in the chore log such that when someone does a chore, we connect who did it with the people table, and we connect what was done with the chores table over on the other side. So we might fill up our people entity with entries. For example, these four entries, dad, mom, daughter and son. Each of these would correspond to a row. If you're familiar with database terminology, it is a four different entries in our people model. On the chore side, we might have several chores. We might wanna do washing dishes, walking dog, doing laundry, maybe cooking dinner. And then when it comes time to record that someone has done one of these chores, we would like to take one element from the people table and one element from the chore table and a particular time and bundle them altogether. So dad, mom, son and daughter is an example of four different objects that are being managed by core data and that are persisting to desk. So after an app that's using this idea, this concept, it is swapped out of memory that list of people who are able to do the chores remains and that's because it is represented in Xcode with a model that has a table that is persistent. Similarly, our list of chores persists. We have those stored within our core data infrastructure and so through a process, through a software stack that core data manages, they get moved from being objects in Objective-C all the way down into a database where they're being stored and that's also because they're represented in an entity called chores. Four different entries, modeled by that entry. And then finally, our middle entity captures a relationship. It captures a relationship between the chore and the person and it adds a little bit of information from the time and that relationships is captured in the chore log and that's managed also by Core Data. On the software side, this is what's happening when we implement a Core Data Stack. We say, Core Data Stack, because it is a stack of software objects that we initialize within our application to help us accomplish what we just saw with our data management and it starts over on the side with our Managed Object Model. And it actually starts with our model, which is a description of the relationships in our data. The Managed Object Model is software that is an object that we instantiate in our software that takes as input this model and it configures itself and it defines how core data's gonna work with objects and store them to disk. So the model, working with the Managed Object Model, those together are equivalent to a database schema. And they helped to describe for Core Data what the relationships are between chores and people and chore logs and what the attributes are for each one of those tables. You find the definition of the model in a file that ends with .xcdatamodeld that's built for you automatically when you start a Core Data project. Under the hood, all of this is being stored in a file. That file is being managed by SQLite and that SQLite Database is being stored in that file. SQLite is a relational database. It is a simplified version of a larger SQL Syntax. It doesn't have all the syntax of SQL, but it has a lot of it. It has probably 90% of what an app is gonna do, it can be done in SQLite. I've never actually run into a situation where I needed SQL and needed the power of SQL and couldn't accomplish it with SQLite although I'm not a really heavy database programmer. All this core data out of the box will be built on top of the file system. So, all your data will be stored in the file system via a SQLite Database. SQLite is relational, and this is the database that actually holds your data when the app ends. So there's a file that's manage by a SQLite instance. It is in that format, it sits encrypted on your device in a file. That the thing that's interesting about this though is that because it's the way it's abstracted where you can see that there's this persistent store object talking to the SQLite Database, you can actually swap out this database for a different kind of database. Or more interestingly, you could swap this out for Cloud storage. So rather than storing your data in a SQLite Database on your device, it's possible that you could connect this to a Cloud base data service. So that the data isn't actually stored in your device, it's stored in the Cloud. And as long as the persistent store object can interface with that Cloud base storage in the sense that it interfaces with the sequel light database it's kind of equivalent in a lot of ways. So it's a very powerful abstraction that's built into the core data stack. Now On top of these items, the model and the data store, the SQLite data store database, we have the Persistent Store Coordinator. And what this is responsible for, is it's responsible for managing the conversion of objects that you're using in Objective-C into Objects or into the SQLite format. So, it's kind of like a translator between Objective-C and the SQLite Database. In order to do that, it needs information about the model and it needs information about where the model is gonna be stored. And then finally, the real workhorse that you as an app developer are gonna interact with is the Managed Object Context. The Managed Object Context is like a scratch pad for your objects or it is also like a cache for your objects. It is a place from which you request new objects and it is a place where you put objects that you have created. Temporarily, while you're working with them and then when you've made the changes you want to make to your objects and you say, okay, they're ready, I wanna make sure that I store them persistent storage. You tell your Managed Object Context, okay, all of the objects that you've given me, I want you to store them now. And the Managed Object Context will then take all the references to the objects that it has given you as the developer and it will make sure that they have been stored to the SQLite Database. All that exists within your core data application. So working with Core Data, so the good news is that Xcode builds a lot of that stack for you. So working with core data involves few steps. The first thing that you do is you design your own model. By that I mean, you create using the tools that Xcode provides you. Create that diagram that had the tour tour log and people boxes. You can use the GUI editor to do that. There's a view that's sort of GUI based and there is a view that is more form based and this is almost exactly the same as a database schema. Once you have designed your model, you create Managed Objects for that model within your code. You ask your Managed Object Context to give you a new object to instantiate a new object and then you work with it just like any other object that you might work with in Objective-C. Those are classes that are going to be derived from the schema that you create. So it's a different way of sort of describing the object. You describe them via this entity diagram rather than describing them directly through code. So then, oops, let me go back one slide. So then your application does its thing. When you need a new class to hold data, you ask the Managed Object Context to do it. You use the version of the classes that Xcode wrote form you based on that diagram. [COUGH] When you wanna persist your data, meaning when you want your data to be snapshotted and saved, your tell your Managed Object Context to save. It doesn't continuously save your data. If you make one change to your object, it doesn't constantly save that to disk. You have to tell it that now is the time when I want the current state of all my objects saved. And then finally, if you wanna fetch data that is stored in your SQLite Database, bring them in as objects. You'll ask the Managed Object Context to go get it. If your program ends, if its swapped out, if your user ends it. Any data that you have persisted, fancy word for saved, is gonna be there when you restart. So let's take a look at this. So over on the left is an example of an application I put together, it's ugly. I know I'm sorry Sam, I apologize. Sam is offended when I present ugly in our faces, but I'll for the interest of teaching, I'll give you an ugly interface. So on the left, we have at the top two fields for adding chores and adding a person and what these are gonna do is they're going to add rows into our people object and into our chore object, into our people entity and into our chore entity and those are going to persist. So first, I'm gonna add some chores to this element. And I have them mapped to a picker, so that after they're added, they'll show up in a interface where we can pick which chore we want to log. So we'll add four of them here. We're washing the dishes, we're walking the dog and stumbling a little bit here as I try and work and try to enter text through the simulator. And then we'll get four different elements and they're being stored to persistent storage as four different objects that have been created with the people entity. Similarly, I added chores to the chores entity and I'm adding people to the people entity. The diagram has them swapped left and right. So in the interface, chores on the left, but on the diagram, chores on the right. Once they're entered, you can see I can pick them. And once I've picked them, I can select okay, who's cooking dinner, who's doing laundry? My son is doing laundry today at 11:02. And so I can click record chore and that's going to make an entry in the chore log based on selecting one chore and one person, binding them together and then making an entry in the log. So I can do that 4 different times and you can see down in the label box in the bottom, I'm just outputting whatever's stored. Now when I quit the program and I come back, you can see everything's still there. That's not that interesting, because it was just frozen or suspended. But if I swap out the program, the program's not running and I restart the program fresh. Now all that data still persists, because I use the Core Data stack and asked Core Data to store these things for me. If I add another person, another son, I swap it out and I come back, other son is still there, because I built into this app the ability to store that data. So when we add a person, the person gets added to our people's entity, to our people data store. When we want to get the list of people that we can select from, we ask the Manage Object Context to give us that list of people, so that we can populate our picker. When we add a chore to our persistent storage through our interface that goes into this entity, our chores entity and then we use whatever is stored in our Core Data, persistent storage, we use that to fill our picker over on the left. And finally, when we record a chore, we are going to make an entry into the chore log that pairs whatever chore is selected and whatever person is selected and whatever time is selected together into an entry into the chore log. And then when we wanna display all the things that are stored, we display them down on the bottom there in that label. So in summary, Core Data is a secure way to store data. It's built on top of a database view of the world and then your application, you work with managed objects the way we've been working with objects all along. Not databases, but knowing that there's a database under the covers is helpful for being helpful to debug and being able to understand what's happening if you ever get an error. Thank you. [MUSIC]
