[MUSIC] Hello everyone, in this lecture we're gonna step away a bit from our filter app. Up to now, you have created quite a bit of different kinds of UI. And know how to connect buttons and interface elements and modify them. And perform actions in code. And with that knowledge you can create many of these basic interfaces and have them work. You can have the buttons perform actions. You can change the UI, like we animated the filter Bar N. But in this lecture we're going to talk about the delegate pattern. And that will unlock a whole new world of different kinds of elements. User interface elements, and other system frameworks that allow us to do way more complicated things. And you'll see what I mean when we learn about it. So by step wave and filter we're gonna introduce this concept with the table view. And we're gonna have a brand new view controller, outside of our main one to do that. So a table view as it's name suggests allows you to display a table we've looked at it briefly before. But by table it's really a list a single column table. So instead of a sort of a grid table, it's a single column table that goes from top to bottom. And so we're gonna set that up by dragging a Table View into our view, and constraining it to the edges. So the power of the delegate pen, well let's finish this first, not get ahead of ourselves. The delegate pattern allows system, so you can implement a delegate pattern yourself. The delegate pattern is utilized a lot in In our lesson U I kit, and you'll see it a lot as well. What it allows you to do. What it allows iOS to do is have a system component, such as a table view, which only handles laying out elements in a table. It doesn't need to know what its laying out and it does'nt need to do if say a row is pressed. It delegates those out to some other object which will be something in your hands, in your control. In this case, the view controller, the table view, and the view controller will do all that. It will provide the content and will perform any actions and update the UI in any way it should when actions occur. And so that's the idea of the delegate pattern. And what it accomplishes. Which is allows the table view to not worry about what goes on outside of it's table view responsibilities. So we're going to create a brand new view controller. And right click here, in your file as well, Cocoa touch class. Up at the top type UI view controller, called table view controller. And of course we want it to be in Swift. Going to create it right here, and we're gonna change this class name. This class and the third property, TableViewController. That makes this ViewController an instance of EveryController. And we're gonna connect this table to the ViewController. So we have a blank ViewController here. We're gonna click on a Table View, and control-drag. And we got ourselves a tableview. All right, so the delegate pattern and that, we're gonna do one more thing actually is create one, tableview is rendered prototype cells. What I'm gonna do is create one prototype cell, which is a prototype cell, as its name suggests. Is a cell that, so if there's a prototype to all the cells in a table, because a table can have infinite amount of cells. And each one of them will, you can create prototypes to allow you to render the same cell efficiently by reusing them. So if you have say, one kind of cell, and you render 100 of them. You only need one prototype, and what XiOs will do is actually whenever you scroll away it will de-que the ones from the top and reuse them at the bottom. So you don't actually have 100 displayed at a time. So here we're just gonna have a basic cell, which means there is a title. So if you change it to a basic cell it has a Title wave on that's all it has and we're just gonna call it Filter Name. That will change that later. So in our TableViewController that we've connected the tableView. Again, it's sort of unclear. You don't set up the tableView in the beginning because your content may change. So the tableView doesn't need to be set up in the beginning. Its data needs to be able to reload and, basically the data need to be completely separate to it's presentation. And it's the table view will handle how to lay things out in a table. And all you have, and it will ask you and it will delegate certain things to you. So look at two aspects of this, and delete all of this boilerplate down here. The first one is the data source. So a table view has actually sort of two delegates, and they can be different objects. One is called the delegate. Another one's called the data source. And really, there's not much difference between these. It's just the relationship between the table view and its delegate is that it'll delegate. Sort of actions to that and with it's data source, is it will delegate control of the data to that. So the data source will provide the data and the delegate will handle any actions and sort of user interface control. And as I was mentioning, the delegate is implemented using protocols, the delegate pattern. And that's because protocols, if you remember, allow you to specify functions without implementing them. In this case, we're gonna add the protocol to our TableViewController for, to conform to the UITableView data source. So this means that it is a data source, which means that it will have implement if you command and click on this. All of the required UI table view data source methods. And the good thing is there's only two required ones. And if you click on here it should tell you which ones. It will just tell you it doesn't conform. And so it's quite intuitive, actually. So a table view that needs to lay out its data. It really just needs to know, at the very basic level, of course it can go deeper. How many rows it It wants to display in total, and then once you're scrolling, that way it can display the scroll bar and know how much data to expect. When you're scrolling it will as you to fill in the cells dynamically. So we'll see how that looks like. So the first one when you do Is numbers of rows and table views. So it usually starts with table views. So in a delegate method it's often that the table view is passed into you to know which table view is actually calling this delegate. And that's very convenient. And here's the one we want, which is number of rows in section. And for this purposes, we are going to create some fake data first so lets take a step back and create some data. So we're gonna have an array called filters. So this is again, we're gonna go back to colors. Our filters which happen to be names of colors. And it's simply gonna be an array of filter names. Remember we had red, blue, green and yellow. Good for now. All right, so this is the data that our view controller has that it wants to display in the list. And so back here. Back to the table view. Number of rows and sections. How many rows? We know exactly how many. It is filters.count. And so that's the first method you want. And table views can have sections. And we're not gonna go into that. But you can have say three sections of four cells. And then that was basically 12 cells in total. But in this case, we're gonna assume there's only one section. And so we can safely ignore the section argument. The next function we need is the cellForRowAtIndexPath. This is a very common, delicate method that you'll be implementing. And this tells you which TableView, it gives you the TableView again and tells you which cell it wants. It wants the cell for this indexPath. And you could create a new cell using this method every time. But there's a very convenient method that allows you to, on TableView, that allows you to DQ. So if we call DQ reusable cell with identifier for index path. We need to assign our prototypes identifier. So identifier identifies which prototype cell should be used and we'll call it the filter cell. And we have it we haven't set that up yet we will have to do that. For an index path, which is exactly index path you that was passed in to use. You passed this index path back in down here and this returns a cell. So we're gonna assign it to a cell. The cell equals that on that. And finally, we're gonna return cell at the end. And all we're gonna do is populate the cell now, which is set it's title, it's text label, .text to be equal to our filters. And the one at index path at the row we are currently at. An indexPath is just an object that lets you specify an entire path. Not just a single index, for example it could have rows and sections and all the ways down. So an indexPath is a path, which can be one to one, which would mean the first index, and within that you go to the second index, and within that you go back to the first one. But in this case, it's flat. It's just one index. And we're just gonna take the row property which is very convenient. It's not gonna let us do this right now, because text label is optional. We know it exists cuz we have a basic tableView cell, and if yours was a custom tableView cell, this might not be set up. And actually it definitely won't be. So last thing we need to do is setup this identifier, the reuseable cell identifier. We go back to our storyboard and inside this Table View Cell we have. There's a nice place for it right here. In its properties it has it has view as identifier. I'll call it FilterCell. Before we go any farther. We also missed out one very minor but important detail, which is actually setting the data source itself. You have to let us know that the data source is in fact yourself. And you can simply assign yourself to be the data source. And there's multiple ways you can do this. You can actually do this in a story board as well. If you right click on cable view, there's actually outlets for data source and delicate. And if you can drag it to table view controller and this effectively does the exact same thing. So we just did it twice and that's really fine. And now for the final thing, since we're showing our filter view right now. We're gonna set our table view to be the initial view controller. And when you click that, all that's being done is this arrow was being is now moved to our table view controller which is our new sort of route view controller. Let's run. See what happens. Wow, there we go, we get a full table just with a few lines of code. And we didn't do much in the interface builder either. And we now have a table of our filters and the really amazing part is like, it is completely independent of the data. The data is here. This code populates into a table and we can modify this as much as we want. We can copy that,. Paste that five more times, and now just by changing the data we have a much longer table. And that's really the power of the data source protocol. Is that, first of all, the table doesn't need to know about your data and your data source can just feed it in using these methods. And you can't really tell, but it's being efficient as well. When you're scrolling past it, it's actually de-queueing the cells down there that were scrolled out and re-using them up here. And that's so, you can have, like, infinite cells. And you won't have a performance issue as long as you're setting it up well, which you are. So, that is the data source. And finally, we're gonna look at the delegate. Which again, the data source is the delegate as well. But there's actually a true delegate. Let's set it to self. It will complain here because the delegate is of a type UI table view delegate and we're not conforming to that yet. But that can be easily fixed. And now, the delegate sort of does the same things. It'll, iOS, the table view will call upon to delegate at certain times, just sort of different times than a data source. This is when it expects or whenever something happens that you might to re active. And there's a few different ones here like say will tell you when will it display a certain cell. When will it display headers and footers. Which we haven't talked about. And it can actually support different heights. So every cell having a different height the delegate would handle that. And the more important one would be shouldHighlight, didHighlight, and willSelect, and didSelect. So it will tell you when a user will select a cell. And it gives you an opportunity to cancel it and It will even change the selection. And it will tell you when it deselects and when it actually is selected. And so this is the most useful one. So whenever the user presses on a cell, they've selected it. And that triggers this callback on our delegate which happens to be view control. So again, all this functionality is baked into the table view controller without it knowing anything about what the app should do, when a row is selected. That is all handled by the delegate here. And so, let's see what we can do. Now that delegate is set to ourselves. These two are data source, we're just gonna push them down a bit. Let's implement tableview,select cell and there's a long list here. Then select row of index path. And what are we gonna do? How about just for fun, we're going to change the cells' background color for a visual. And actually, we might not even have to do that. Let's change its, usually, when a table view cell is like that, you may want to go to a different view controller. Push on push on view controller. Go on to navigation stack, or do something say in this case it's a filter. So we want to apply the filter. But we're not going to do that right now so let's make it very, very simple and just print which one we select. So we're simply going to print the name of the filter which is very simple it's just filters And a one at indexPath.row. And that is it. I'm gonna run. And now when you tap on these guys, it will print out their name. And that is really, really cool because that was one line of code. And I hope you have a grasp and an idea of how delegate in data sources work. And this will allow us moving forward to do quite a few cooler things and access the camera for example and other stuff as well.
