Delegates in table view

The delegation pattern

The concept of delegation is very common in iOS. An object will often rely on another object to help it out with certain tasks. This separation of concerns keeps the system simple as each object does only what it is good at and lets other objects take care of the rest. The table view offers a great examples of this.

Because every app has its own requirements for what its data looks like, the table view must be able to deal with lots of different types of data. Instead of making the table view very complex, or requiring that you modify it to suit your own apps, its designers have chosen to delegate the duty of filling up the cells to another object, the data source.

The table view doesn't really care who its data source is or what kind of data your app deals with, just that it can send the cellForRowAtIndexPath message and that it will receive a cell in return. This keeps the table view component simple and moves the responsibility for handling the data to where it belongs: in your code.

Likewise,the table view knows how to recognise when the user taps a row, but what it should do in response completely depends on the app. In our app we'll make this toggle the checkmark but another app will likely do something totally different. Using the delegation system, the table view can simply send a message that a tap occurred and let the delegate sort it out.

Usually components will have just one delegate but the table view split up its delegate duties into two separate helpers: the UITableViewDataSource for putting rows into the table, and the UITabelDelegate for handling taps on the rows and several other tasks.