ECS189H_2009-11-16

sorry I missed on Friday it's a little uh busy at work last week so uh yeah I don't the only announcements I have are that the projects are due and is it less than two weeks less than two weeks so I'm no is it three weeks left I guess we have three weeks we have until December 4th which is two to three weeks away um so I'm anxious to see uh Milestones this week on on Friday I'll definitely be here um so yeah any questions from folks concerns are the projects you chose too big too small you're already finished no okay so today we're gonna do a little bit of a core data recap so for me I think when Colin presented it I'd say for many of you that was probably the first time you saw core data for some of you maybe not for me that was also essentially the first time I sat down and had anyone actually tell me about it so what I've been trying to do is you know spend a little time to to learn it as well so I'll present as much as I can today I only got to a certain point in terms of me learning it so hopefully some of what I've learned will actually help you and then probably what will end up happening is on Friday we'll finish up with it and also include key value coding and key value observing which is something you may have seen in the documentation while poking around through various things and that stuff's interesting because it's sort of how well some of the things that seem like magic with core data are because of key value observing and key value coding and it's also how some of the interface builder stuff happens behind the scenes so we'll look at that on Friday and maybe the accelerometer because we'll have like the things we have are sort of smaller now little chunks of things so okay so core data recap so what is it again does anyone vaguely remember or have some thoughts as to what it is some opinions explore your data that's in like a file system sort of okay so um yes that is part of it so it's a well so you can think of it as a place where you can um where you can store stuff um so that's that's like a piece of it so core data itself is just is this API that lets you manage um well it lets you manage your models in some way so we've you know so we've we've talked about the model view controller pattern a number of times and we've seen that the views come from the interface Builder World um and then sort of the controllers and the models are things that we've been working on ourselves in code so core data and some of the tools that it provides gives us the M part of the model view controller pattern stuff that we've been using and it provides some tools that help us create these models in a nice visual way and then it basically coordinated itself is a set of is a set of apis and objects that basically allow us to save data in certain ways so we can either the data we store doesn't necessarily have to be stored to a file it can actually be in memory in which case it's you know it unless your machine never turns off I guess it's not really persistent but that is an option so let's see what I've got here and we'll sort of see how to use it as we go through so when talking about core data basically usually we refer to this core data stack and these are these objects that um well that work together to read and write data to some sort of storage so that storage could be file storage could be a database could be Memory in general when people are working with it on the iPhone it tends to be like the store tends to be an sqlite database but it doesn't have to be um so I think I feel like I'm doing this backwards because I have some slides towards the end that talk about modeling but we'll go through it this way and then we'll sort of back up again and hopefully we'll have a clear picture of what core data actually is I guess before I go in I'll step back and just say in general the way to think about it is core data gives you some sort of abstraction to stuff that you want to store and generally what happens is through the apis that they provide when you reach into that store and pull things out you get them in a way that you're used to using them which is through objects so you know you've created your own models already where you've got various properties on them so you know there's a person model and it's person has a name and a social security number and various other attributes so core data helps take care of storing that stuff in some way and then retrieving it efficiently to display to interact with in some way so generally when talking about core data we refer to yes object relational mappers is core data really any more than just an object relational mapper with some Associated like visual tools right so um I'm also familiar with object relational mapping so for those of you who've used like Ruby on Rails for example Ruby on Rails provide something called active record which is this abstraction this orm abstraction over your database so what happens is if for whatever reason you want to use a mySQL database as the back end you can do that if you want to use oracles whatever that doesn't really matter to you when you're actually interacting with your database because what what you end up getting are just these objects that you interact with and core data does provide that I I haven't used it enough yet to really know whether it gives you much more than that but in general the way to you know and we'll look at it when I talk about modeling but the general way to think about what's going on with core data when you're creating these things called entities these entities tend to be tables and these tables have cells or have columns and these columns have are represent various properties and then the rows in these tables represent instances of objects from your store so from that in that regard yes it is but the thing that that bugs me is that in none of the documentation that I've seen so far has Apple actually referred to it as an orm so it makes me feel like there's something more there and I think I think that something more that could be there is has to do with um with this idea of bindings and so key value coding which we haven't discussed in key value observing so I'll just mention them briefly right now just because I did want to talk about today but um I didn't think I'd have time but I'll talk about it so key value coding um foreign basically is a mechanism where you can access instance variables of your model classes buy it via string so you know normally you have your model object and you say hey model object dot whatever my property is instead you could say whatever my object is value for key and in a string property name whatever the property name is so that's the first piece so basically you can get inside of your objects by just poking them with some strings and the other part um so you can get into inside your objects by sending in some strings and you can access these instance variables even if properties haven't been created so you know we've been setting up these app properties retaining stuff even if you don't set those up you'd still be able to access them um the other piece of it again I haven't I haven't used this stuff very much at all really but the other piece of key value coding is key value observing so what happens is you can set things up so that when data changes in some place you'll be wrecking you will be notified of that having happened in some other place so that could be useful if you have a lot of views and they're all sort of poking into one model and based on whatever happens you want these various views to change so in in a way to sort of to minimize the coupling between all of these objects you well key value observing facilitates this stuff so I would say that's how it's different from a traditional orm in that when you access or modify something there are some notifications and things that happen in the background that's my first guess at it so if you find something else about it I'd love to know okay so usually when uh when talking about core data we refer to a core data stack and so these are just objects that work together to read and write data to some storage and you know so this is a pool do I have Apple's documentation this you know this is a representation of the core data stack so um at the very bottom we have this store file and then moving up we have persistent Object Store so a collection of object data persistent store coordinator a collection of stores and then off to the right there's this managed object model which people like to call mom um and then at the very top there's this manage object context so let's go through each of those and say something about them and see what we can learn so the persistent Object Store manages storage so uh you know I mentioned earlier that the storage doesn't necessarily have to be doesn't necessarily have to be a file but it could be so it would manage the opening and closing of these files or setting up whatever it needs to set up allocating the memory that you might be utilizing the other thing that it does is it it takes care of this of mapping between data in the store and objects in the manage object context so we'll look at what the manage object context is in in a little bit but um basically if we look here at the very bottom so things sort of you know they'll kind of move up and down this stack as you interact with things and at the lowest level you can imagine that the persistent Object Store at some point has some sort of information that is your object's representation and in order to get your object and shove it into an sqlite database for example or into some other sort of binary file this persistent Object Store which is very specific to say sqlite will take your your objects and transform them into some sort of data that SQL can utilize for example yes so it's a collection of converters I would say the persistent store coordinator is more so uh would be more of a collection of them the persistent Object Store itself as far as I understand it tends to be very specific to a particular type of storage for example SQL Lite and we'll see as we I have another picture somewhere towards the end that maybe makes that a little more clearer so this persistent Object Store there could be multiple persistent object stores and they would be all managed by the persistent store coordinator on the iPhone generally you you will generally just have just one and it'll tend to be an SQL light backed Object Store so the in terms of the persistent Object Store itself your interaction with it is fairly minimal as far as I understand it besides just creating it you're pretty much kind of you know you've created it you've set it up and there it is and as far as the iPhone is concerned you have the type of storage that you can have is sqlite so a sqlite database there's some sort of binary representation and then you can also if you wanted to you could use memory to do various things so utilizing you know so the main memory for this you know it's definitely doable it probably would be a situation where you have you know a number of objects but they don't take up a lot of space and just the interaction that core data gives you the ease with which you can bring data in and out and manipulate it you know it might make sense to to do that um okay so next up the persistent store coordinator so that sits between these managed object context and the persistent Object Store and basically it's a generalized interface to the persistent Object Store so like the question that was asked a little bit ago um basically as you as you go lower in this stack towards the persistent Object Store things start to get more specific so as you you know you move up to the persistent store coordinator it's much more of a generic interface to you know between your model your manage objects and the persistent stores and if we look off to the right of the persistent store coordinator there is a you know it has it has the is information about the managed object model so the model is just you know the models that you're used to using you know these objects that have properties and um whatever various bits about them and as far as well we'll look at the managed object model shortly but basically the persistent store coordinator uses these descriptions to facilitate the I guess the the movement of information up and down this stack so the managed object model like I just mentioned basically the description of your model properties you know we have a person model and the person has name and birth date and various other things that you can can think up um next up the managed object context so this one's at the very top of our stack there and the thing just says here you know it's a collection of managed objects so what happens here the way the documentation likes to refer to it is they say that it is an intelligent scratch Pad so what happens is when you query um you know this when you need objects from your persistent store basically they'll come into the managed object context and they'll just be hanging out there and you can poke at them and do whatever you want to them and you know they're just hanging out there and they're temporary and you know you can modify them in whatever ways you want to modify them and if you don't save them then your persistent store hasn't been modified in any way so in order to actually get that stuff saved off you have to actually tell them to go ahead and Save so basically all of this is just this abstraction you know these layers of abstraction that eventually get you these model objects that that you can interact with and it seems kind of wacky at first but I think like the more I'm looking at it the more I'm like oh this is pretty nice and you know I'm looking forward to using it for something in the near future but um yeah so manage object context so another another diagram I found in the documentation that just sort of you know kind of a higher level well another look at all of this so we have our managed object context up top and we have in this case we have a few of them and you know they link up to some persistent store coordinator and in this case we see the persistent stroke coordinator has two persistent object stores so again on the iPhone you generally you probably will not have more than one but you know in this case I think their image may have would have been more interesting if instead of thought you know one of them would have been file and one of them would have been like database or something because what will end up happening is you can take all these things from different persistent object stores and sort of merge them all into model that you will interact with so even though they're stored off separately you can actually sort of glob them all together and work with them so let's see I think um actually okay so let's take a look at how this core data stack is built and the way we'll do that is um well we'll just look at the sample like at the templates that xcode creates for us and we'll walk through as much of that as I have sort of annotated and maybe we can try and figure out some other stuff too for folks who have used it more in depth so basically this particular project that I have um I won't create another one but basically it's just a navigation based application and make sure that in this case you check that you want to use core data for storage just so that it sets up a bunch more things for you you can do it yourself it's just why when xcode can do it for you um oops so if we take a look our app delegate usually when things get set up I guess some things that get cut off um what we're used to seeing is that you know we'll have this stuff sort of put in there for us by the template now we've got a few other things in here so you know manage object model mom you know we briefly talk about that there's a managed object context and then there's some sort of persistent store coordinator so basically they've you know they've thrown in the things we need to make our core data stack and if we look down below we see a number of properties to access you know those stack elements so let's see here so let's look at constructing this okay so in terms of actually constructing uh you know building the the persistent store coordinator so this was that thing I mentioned that we wouldn't interact with very often but you know he pretty much set it up and then you're you're done so what's going on here basically we're getting a path to to some file core data movie dot SQL or chordata move it's supposed to be movie when I wrote this but um so basically we're saying you know here's here's the path or here's the name here's the path and name of the file that we want to store stuff into and when you generate the template you can look yourself but well I guess we can just jump there so the applications document directory it just does you know just some stuff to help find the document directory and I think uh last time when we talked if you remember when you want to save something when your application wants to save data you want to save that data to that documents directory inside this little application bundle that that gets set up and you want to do that because well first of all that's sort of one of the few places that you can write and it's the place where when the user does a sync and does whatever backups they do with iTunes stuff from that documents directory will get pulled over and so all right so this is the name of our file and it's going in some particular place and next up we just say okay let's take our persistent store allocate it and initialize it with some sort of managed object model we'll look at that one shortly but it's basically you know it's like hey let's set up some pointers and remember right the managed object model is the is this description of your entities and sort of how how your objects relate to each other um so we initialize it and that's pretty much it you probably want to do some of this stuff but for now for us that's good enough so let's take a look at should be the managed object model um and let's see how that gets set up so again this you know the code's pretty short for this it's basically okay and it's managed object model well so if it hasn't been created then go ahead and create it NS managed object model and then merged model from bundles so what this will do is it'll basically look through all your application directories and look for these moms and basically glob them all together and stick them into this one managed object model so the hmm yeah I think during the compile I think that the the models that you create will be placed in this mom file but I'm not 100 sure and certain but that should be what happens because when it starts searching for these it's got to search for something and I think that's what it is so we've created we've created the managed object model so so far we're basically right we set up the persistent Object Store we've set up this managed object model so at some point we'll probably have to set up this persistent store coordinator and let's see um if that is next I'm sorry that part came in for us next up is the actual managed object context um so in terms of manage object context well actually we left out the persistent store coordinator so at this point we're going to go ahead and create our persistent store coordinator and or manage object context and we're going to assign the managed object context the coordinator that we just created so the one thing I wanted to see that I'm missing is the part where we actually tell it um yeah sorry I went a little too fast through the persistent store wait actually no okay let me back up and start again so I was thinking we're at the persistent Object Store which we are but it was also setting up the persistent store coordinator at the very beginning so again we find our file we set up our persistent store coordinator and we you know give it this managed object model which if we go in there it's some other setup that's happening the the thing that is interesting or the the next little useful bit is the the place where we actually tell it hey here's how we're actually setting up our persistent store so persistent store coordinator add persistent store with type and SQL light so this is where we're telling you know we're sort of saying this is here's the type of of thing we've chosen to use so as usual right option double click on there and we should see some information so we'll see that you know if we wanted to we could use an NS binary store type or an s in memory type if that was the right thing to do for for your application so all right let's see I think that's all I wanted to look at in here so that stuff's all kind of Generico boilerplate stuff it's just important to know that in order to create this stack you know you need your Precision Object Store and the store coordinator and the managed object context um and from there let's see um well so let's see let's take a look at how we actually model the objects so so we saw how to build up the stack in terms of actually modeling so I mentioned this briefly at the beginning I'll mention it again so you'll see the words you know you'll see the word entities thrown around in general entities will correspond to some sort of a table and these tables well these tables have columns and those columns will represent properties of your objects and then the objects you know the instances of your objects end up being rows in this table so imagine a table of person objects so a person has a name and a birth date and you know all of us are people and we're in this person's table so you know if we wanted to get data about me we could query query this table and it would find the row with the name Saban and you know bundle that up into some sort of object that you can now work with and you could say oh what's you know what's Saban's birth date or what's his social security number or whatever so that's sort of a very high level way that again I don't think it's it's necessarily the way that I don't remember if I saw them saw Apple describe it this way but this so this is more of the object relational mapping sort of way of thinking about what's happening and modeling your data but so you know in terms of actually doing the modeling when you move well when you select that you know when you click that check box for core data you'll end up having some sort of model file in your resources and usually it'll be it'll have like one little thing in there but I've already gone and done some work in it so let me zoom in a bit hopefully that's a little better the so the idea is in here you know so I've I was thinking of you know setting up something where there's a theater and you know there's a theater model and theaters have movies associated with them so then there's some sort of movie uh movie model and that's you know that's what I was setting up here so I'll push these aside and um I'll just make some new ones and we'll I won't save them just to see how I how I set up this particular thing so if you look over in the upper left corner you'll see you know you'll see your entity that's kind of your entity area so um you know let's create a new one and we'll just call it theater two and once you set it up you now you know theaters have some sort of properties or associated with them so you can head over to this other section and you know add some sort of attribute so the attribute is your property um so let's say that well we'll say the theater has a name we'll just do the same as as what I did in the other ones and and it will set its type to be one of these things let's say it's a string and then you can do some other things some other fancy things with uh with the attribute you can set up some sort of regular expression on them a default value minimum maximum length this optional thing I don't have a good grasp of exactly what it is but the the basic gist of what I've seen is that generally you don't want these things to be optional and when they're not optional it helps maybe I shouldn't say too much about them since I'm not since I'm not 100 sure what the best way of using that is but the things that I have seen mention that generally you want to unclick optional um because it somehow helps with the Integrity of your objects so for now we'll just say non-optional and look through the documentation at some point to figure out what exactly that's all about so we've got a theater and it's got a name and I don't know what else do theaters have won't say that they have today's date and um and there is like a date field that we could use in here but I'll just go ahead and use string just use string again so we've got our theater let's make another movie model or another movie entity the movie two and again our movie might have some sort of name sort of stuff and maybe there's some sort of description for the movie and and we'll just leave it at that for right now so what happens is we now have you know we have a theater model and we have a movie Object and a movie model or we have these entities what we haven't really discussed or set up is how these how these two things relate to each other so you know if you look closer or farther down here we'll see right we've got our attributes so we've taken care of those and we have some sort of relationships so what we can do is we can say well we know that theaters tend to play more than one movie so A theater has many movies in general and for for the sake of this example we'll say that the theater is the theater at my house and so that you know basically you know my theater has many movies but my movies belong in only one theater which is my house um so what we can do is um again on while on the theater model we can instead of adding an attribute we can add a relationship and in this case we'll call the relationship movies and again we'll get rid of this optional thing and if we look I'm not sure how legible or how easy it is to see there but um you know we have a few of these other well there are a few other options so first off there's destination so what this is so this is basically where we're saying you know let's link up one entity to another so our theater two has many movie tubes so we'll go ahead and set that up and if we zoom out we'll see that you know it created this little arrow to it and as I mentioned earlier theater can have many movies so that is this this idea of two of uh too many relationships so an object Maps too many other objects so we can click that and as soon as you do that you will notice that the arrow has now become this double arrow one last thing that we want to do is take care of this delete rule so if if this object is destroyed how do we want to proceed and right now it just says nullify which basically um well it won't do it won't do anything to any of its objects in the relationship so what we want to do say we want to delete everything you want we want to do this Cascade option so with Cascade will you know if you delete the theater it will also remove movies so let's set things up in the other direction because a movie has a theater associated with it and so let's select the movie and add a relationship for it and we'll call that one theater and um and its destination will save this theater too so now we have these Double Arrow things going around and the some of the stuff I saw in the documentation they suggested that in general you want to make sure that you have these inverse relationships set up and I think part of that has to do with just the efficiency of of doing various queries on these objects so the idea is if um well in general I think if if you can map from one object to another you'd like to be able to map back the other way so in this case we can again say that you know let's map back in this case to movies um and once we do that those you know that those two lines kind of they become one and now we see we can we can very clearly tell when we look at the theater and we look at the relationship movies and we Follow the arrow when we reach the end of it we see o there are you know there are two arrows there so this is clearly a one-to-many relationship if we go in the other direction we eventually reach the uh we reach the the Arrow Head there and there's only one of them so you know movies have only a 2-1 relationship and not not too many so the yeah that's so that's sort of the gist of how at least you know you set up your models so you know from a it's kind of you know it's nice like so far we haven't really as far as these things are concerned we haven't written any code but um so the next step and you don't necessarily have to do this but um you know if you actually need to access the code for these models what you'll do is so you can create a group you don't have to create a group but generally you'll create a you'll create a group and say it's called models and you can easily do that right create or click on there and add new group and you know select that and in this case you know so say we grab say we want to do a select all pretend that these other two aren't there um and you actually want to generate the code for these models what you can do is you know go up to file new file and when those things are selected what you should see is an option you know this this new thing comes up for this managed object class and I think if things aren't properly and let's check if things aren't selected I'm not sure if that comes up so that could be no it does um I saw something in the documentation about that thing not necessarily showing up so uh so we've got um so we have our cocoa touch let me check that again I'm curious okay so grab these new file uh manage object class you go next and you'll say you know where do you want to put these things and you can sort of I didn't need to select them the fact that I selected them checked them off ahead of time for me so from here what we can then say is finish um and well we can take a look down here at some things generate accessors generate Objective C Properties we want those checked off generate validation methods I haven't looked into but usually when you deal with with models you want to do something that you know to to make sure that the data that you try to put into them is actually valid data so I suspect that this generate validation methods might be related to that I haven't looked into it but that's my guess because again the the model generally wants to try to protect itself and say oh you're trying to give me bad data no you know I won't let you give me bad data so so I'm going to cancel just because I've already generated those um those files and we'll look at them in a second so the files it would end up creating you know will look very yeah they'll look fairly familiar main thing is we're now inheriting off this NS managed object um you know so we've got some properties right we our movie set up and we had a name for it a description for it and then the movie is playing in some particular theater and if we look at the dot m there isn't very much that really the main thing that's different that we may not have seen is usually we say synthesize name and here we're saying at Dynamic and all this is is basically a way to tell the compiler hey stop warning me about the fact that these Setters and Getters don't actually exist someone will supply them to you at runtime and of course if you don't then there'll be problems but if you do then things are good so if we take a look at the theater same thing it's an NS managed object it's got the things that we put in there so we we said that the theater has a name and maybe it tracks today's date and you know so A theater has movies associated with it and the way that that's sort of taken care of is you know movies are an NS set so this unordered thing uh with all of our movies in it and if we look down a little farther we'll see another interface section and you might remember this from one of the earlier lectures when we were sort of looking at Objective C um I think I spent a bit of time talking about categories so this is a way where as a quick refresher you can you know take an interface like say Theater which was set up up here and open in essence open it up and add additional methods to it so this is sort of the the Syntax for doing that and core data or this template took care of doing this uh well generating generating these models from the entities took care of doing this stuff for us and basically you know so add movies remove movies add um you know they set up these methods for us um another way of injecting methods into into classes is through protocols so Protocols are are a new I think it's an objective c2o feature so prior to that the things that you're doing with protocols now are generally done we're generally done through these categories so um we look at the implementation again not a whole lot going on so behind the scenes core data will be taking care of stuff for us and again Dynamic just telling the compiler hey don't complain that I haven't created these Setters and getters they'll be there at runtime okay so any any questions up to now yes yes um so are you are you saying if you you've now created these files you want to go and mess with them and add additional things to them so accessors well so that's where so now you have the so you have all the accessors right so um the fact that we you know when we when we save these files out we click you know generate The Objective C Properties it put these things in place for us again the main bit of magic is that usually we would say at synthesize the name of the property and that would actually the compiler at that point would generate a Setter and a getter for us in this case ad Dynamic is just saying that at runtime when you use this there will be a Setter and a getter there for you and that's sort of where core data will take care of that if your stuff happens to be well in this case we'll be backed by some sort of core data store what I don't know is again this is just because I haven't I haven't played with this stuff enough yet is well now I have this theater object you know it feels scary because now what I could do is I could go in and start making changes here to this file but if something happens and my model changes I feel like um and and I've actually written things in here and I haven't done them through um yeah if I haven't done it through here then you know you could end up like clobbering over some of your stuff so that's something I haven't figured out yet because you know I haven't used it enough but um in general I'll say you know as you're working with this you know do everything you know set up your models through that model modeling tool and um let me make this go away okay um yeah okay so so we saw how to put some of these together and connect them up next up let's take a look at let's take a look at our root view controller so you know so we have these objects but you know how do we actually do anything with them how do we get at them and this is where the there's an NS fetched results controller that comes into play and this is something I haven't had a chance to look at as closely as I would like to but we'll go through it quickly and then on Friday we'll finish up in more detail with it and um and hopefully we'll have all our core data at least the the initial questions that we have about it sort of in place so at this point this sample I don't think will run because I've made some changes and didn't make them at all you know didn't update things in all the places that we need to but the idea with the sample if you just um if you just build it without even the changes what you'll see is a table comes up and you can add and delete rows in that table and it just keeps time stamps of when that happened um so with that um you know to actually get at our data again so we have this fetch results controller and let's we'll start at you know some of the things that uh table view you know the methods that we need to handle and we'll see how this fetch results controller sort of takes care of things for us and we'll we'll first look at it how it's used and then we'll see how it's set up um so uh if we want to know okay how many rows you know how many sections are in our table view well we just asked we ask our fetched results controller we say hey get the sections and then give me the count Okay so fairly I guess straightforward for that the the other thing we'll generally need so given a section we'll say well how many you know how many rows are in that section so again um you know we can grab using our fetch results controller we can get the sections and then say you know give me some object at some index um so that's for that particular section so now we have some objects associated with that with that section and then we can just say Okay given given that section information tell me how many objects are in there so now you know we know how many we know how many sections we have we know how many rows are in a particular section the other one that's that's usually very important when dealing with table views is the cell for row at index path so most of what you see here should be should be familiar from having worked with it at this point but um you know so the first thing is we want to grab a cell and we want to we want to reuse one assuming that it's been that it was created ahead of time or we've already created one if it hasn't then we'll go ahead and we'll go ahead and allocate it and set up whatever we need to set up for it um so you know we've got our cell next up now is you know so we want to actually do something with our with our little objects so we'll ask the fetched results controller for some particular object at some place and this is easier than I think when we well it's fairly similar to how we did it in say the RSS reader but now it's just the fetch results controller you just feed it this index path you don't have to actually go in and grab anything out of it and basically it's saying you know go off to this table and grab me some object in that table um so the example earlier if we have this person entity and we're querying uh you know somehow the row with my name comes up um you know this managed object will be a person object that has Ron's name and social security number in it and then from there um you know so we have this we have our object we can say and this is where the sort of that key value coding stuff comes in earlier so um you know we can say give me a value for key name and I think the fact that we actually generated these files um so uh the fact that we've actually generated these files and we have properties we wouldn't necessarily have to use that value for key stuff but again just to see sort of how it's done so we'll grab the name and the description and we'll put that into this into the theater's table of of movies um okay so that's sort of you know here's this fetch results controller this thing that helps us get stuff let's see how it's actually set up um okay so this one again I think very briefly I'll just say some of the things that the fetch results controller has associated with it and then next time we'll start with the fetch results controller and look in in Greater detail into sort of this connection of where we now have our models we have this fetch results controller and we'll look more deeply at okay here's how we actually here's what it means to do all the things we do with it and here's how to use it but in general from the stuff I remember the fetch result controller you know has a fetch request associated with it um and let's see so then there's you know this entity description so you know our entities are theater and movie um in this case you know we just had event sitting here but uh from the default thing that that xcode generated but we would basically you know this is where we could say NS entity description entity for name and we could say theater and it would give us you know or we'd say movie and it would give us a movie object or at least a description for it um okay so fetch request I guess we can you know we can choose how large you know how many things we want to fetch at a time um just because you know you might have thousands of objects you don't actually want to grab them all um with these you know when you do a fetch so actually has everyone in here taken some sort of database course I managed not to take one at UC Davis so I'm just I'm curious I didn't get to play with mumps or whatever it was that people used in that class but you know so you're doing some sort of query on your database and you're getting um you know you get back you know your your rows of information in this case for us we'll get objects which represent those rows um the sort descriptor basically is a way of saying hey here's you know sort based on some particular key or some particular attribute and you know in this case do we want these things to be ascending or descending and the sort descriptor I'm not quite sure uh there's another one which is the there's a predicate which I'm not seeing in here but you can get you know the queries you make can be fairly well as complicated as you need them to be or as intricate as you need them to be so there is something there's an NS predicate which basically you can feed it these little regular expression type things to help pull your data in um so I think yeah I think I'll just leave it at that for today and on on Friday we'll we'll look more deeply into the fetch result controller and maybe it will try and finish this little example which will be like here's some movie theater and here's some movies associated with it and let's actually do something and there'll be another sort of recap of key value coding and key value observing because that's very intimately connected to core data and I think you know we'll look at the accelerometer we probably won't spend too much time on it because I don't know how many people are using it for stuff but we'll take a we'll walk through some of the examples and see how to filter the accelerometer data using some low-pass filters and and things so all right is is this is chordata slightly clear for people now a little bit so so okay on Friday it will be very very clear I think how many people are using it for their final projects okay more people should use it because it's actually yeah it's again it seems kind of weird at first but I think like even as I'm as I'm learning it I'm like okay it's wacky but I think once you get past a few of the the kind of the setup things it's actually it's very useful so okay see you next time