Chapter 5
Showing Data with Table Views

We’ve gone through the basics of models, views, and controllers in iOS development, but now we’re going to dig a little deeper. The UITableView class is so central to most iOS apps that it deserves a whole book to itself, but a chapter will have to suffice for now.^[15]

Although they look very different, the Mail and SMS apps both use UITableViews to display their content:

When you look through the default apps that come on your phone or iPad, you’ll see something that’s even more universal than blue and black tab bars: scrolling lists. And boy, do they scroll, right? The Phoneapp smoothly scrolls through an enormous list of contacts; SMSapp practically flies through all your blue and green bubbles that are messages. Visually, they are quite distinct, but they’re built with the same tool: UITableView.

UITableView manages content that can scroll far beyond the bounds of the screen. It’s designed to present rows upon rows of similar-looking views, each populated with slightly different information. There is a simple reason why these lists can scale from nine to nine hundred items: table views use only a fixed number of subviews in memory at any given time. That sounds complicated, so I’ll break it down.

In your Mailapp, you could have hundreds of emails in your inbox, but only a portion of them are on the screen at any given time (about six). When you scroll, the topmost emails eventually move off the screen. The table view will actually take these hidden views and move them to the opposite end of the screen. So, those message views that move off the top of the screen get repositioned below the screen and have their content replaced with the appropriate data for that new position. The table view can move its rows around incredibly fast, so even if there are hundreds of items in your table, only a handful of row views are kept in memory.

So, how do we take advantage of this great class? UITableView is a view like any other UIView, so we have to add it as a subview with the appropriate frame. We also need to assign it delegate and dataSource objects. These objects must implement a few methods, with the option of implementing more for fine-tuned control. They can be any kind of object but are commonly controllers. The table view will then call those methods to get the information it needs to form the rows it needs. Doesn’t sound bad, right? Let’s get to the code.