Custom Table Cells

To create a custom table cell, it usually makes sense to create a subclass of UITableViewCell and give it public properties for the fields that we’ll need to update from tableView(cellForRowAtIndexPath:). So, in the File Navigator, select the Pragmatic Tweets group, choose File > New > File, and select the Cocoa Touch Class template. In the next pane of the assistant, name the class ParsedTweetCell, and set the Subclass of: to UITableViewCell. We don’t need to do anything with the code yet, but it will help us in the storyboard to have this class already created.

Back in Main.storyboard, select the table view. We could edit the existing prototype cell, but just to prove that we can juggle multiple prototypes, let’s create our custom cell as a second prototype. In the Attributes Inspector, tap the up button on the Prototype Cells field so the table has two prototypes. A second prototype is created, a copy of the first. Select the second and, in the Attributes Inspector (⌥⌘4), change its style to Custom and its identifier to CustomTweetCell. Then, in the Identity Inspector (⌥⌘3), change its class to the ParsedTweetCell class that we just created; the Module should default to Current - PragmaticTweets.

Switch to the Size Inspector (⌥⌘5) and notice that the first field is Row Height, currently shown with the placeholder text Default because the Custom check box is not selected. If we want to pack a bunch of fields in here, it’s pretty clear that the default row height is not going to cut it for us, so click Custom and enter a height of 125. That should give us enough room.

Now we get to lay out a UI inside the cell pretty much the same way we built the app’s original view with buttons and a web view in earlier chapters. Within the cell, we can add labels, image views, whatever we like…provided that we wrangle all the autolayout constraints to put them in their place (there had to be a catch, right?). We’re going to add four subviews: labels for the username, tweet text, and a created-at string, plus an image view for the user’s picture. Feel free to play around; for the sample code, we’ve used the following views:

• An image view (use the icon with the palm tree) with height and width constraints to lock its size at 75×75 points, plus top and leading constraints of 0 points each from the margin. The image view will initially want to be much larger than this when you drop it, but once you set the constraints, using Update Frames in the autolayout Resolve menu (⌥⌘=) will clean it up.

• A label for the username, with the font set to System - Bold, leading constraint of 8 points from the image view, 0 point top, and trailing (i.e., right) space constraints from the margins.

• A label for the tweet text, Lines set to 3, with the font set to System 14-point, leading and top constraints of 8 points, and trailing constraint of 0 points from the margin.

• A label for the created-at string, with the font set to Caption 1, center-aligned text, a Horizontal Center in Container constraint, and a bottom constraint of 0 points to the margin.

Once we’ve created the layout, we’re going to connect this prototype cell to the custom class we created earlier. Since we used the Identity Inspector to assign the cell to our ParsedTweetCell, the Assistant Editor will let us connect these subviews to new IBOutlet properties in that class. With the cell selected in the storyboard, switch to Assistant Editor mode via the rings icon or ⌥⌘↩ (it may help to hide the utility pane too). Ideally, Assistant Editor should bring up ParsedTweetCell.swift on the right, but sometimes it chooses ViewController.swift; in that case, use the jump bar at the top of the pane to load ParsedTweetCell.swift into the right side.

Control-drag from each of the subviews over to the ParsedTweetCell.swift code, just under the class declaration and before the first method. After releasing the drag, give each property an appropriate name. With all the connections established, the properties should look like this:

Problems When Connecting Custom Cell Subviews

When creating connections from subviews in the custom cell, be sure that the subview (the label, image view, and so on) is selected, and not the Content View that is a superview to all of them. If the pop-up that appears at the end of the drag wants to define the class of the outlet as UIView rather than UILabel or UIImageView or what have you, chances are the connection is being made to the Content View instead of the specific subview we’re trying to connect. One way to be sure is to start the drag from the subview’s item in the scene’s tree list, rather than from the storyboard view itself.

There’s one more thing we need to do in the storyboard: the cells know they’re 125 points tall, but the table doesn’t, and will continue to assume the default row height of 44. Return to the Standard Editor mode, select the table, bring up its Size Inspector (⌥⌘5), and set Row Height to 125. We could also provide this height in code, which would in turn also make it possible for rows to be of different heights, but this easy approach is fine for now.

Now it’s time to start populating these custom cells. Back in ViewController, we again need to update our method that dequeues and populates cells. Rewrite tableView(cellForRowAtIndexPath:) as follows:

The first big change here is on lines 3--5, where we dequeue the cell with the identifier string CustomTweetCell, and since we know it’s our custom cell, we can use as! to forcibly convert it to our ParsedTweetCell class. Then, on lines 7--9, we set the values of the cell’s properties that we connected.

Then we have the avatar image. The UIImageView has an image property we want to populate, of type UIImage. Unfortunately, UIImage can’t be created directly from the contents of a URL. However, it will accept an NSData object containing image data, and we can initialize that with an NSURL, so we can chain those together with a chained if let on lines 10--11. If we make it into the curly braces, we have the imageData, and use it on line 12 to populate the image view.

With the image loaded into the image view, we return cell to the caller, just as before. The result looks like the figure.

This is looking a lot better. The avatar image is there, and the author name is nicely set off from the tweet text and created-on date. The difference in fonts lets us easily distinguish between username and their tweet, and the smaller Caption 1 font downplays the timestamp label.

There is one problem right now, though, and it’s our images. If we have enough cells that we need to scroll—copy-and-paste a bunch of ParsedTweet initializers into the parsedTweets array initializer if you want to see it for yourself—the scrolling performance is pretty choppy. It’s nowhere near as smooth as on a real iPhone or iPad, and this is running on the Simulator, where the power of a full-blown computer tends to run apps faster than they will on the device. So why is this happening?

The culprit is how we’re loading our images. Our approach of loading the image data from the NSURL right when the tableView(cellForRowAtIndexPath:) needs it has a big downside: it means that everything in our app just stops while we load that image from the network. We can’t draw the cell, continue scrolling, or update anything else in the UI until the image data loads. Just imagine how well that’s going to go over with users who are only getting one bar of cellular signal. In the next two chapters, we’ll fix this problem with a more sophisticated approach.

How I Gave Up Tables and Learned to Love Lists

One of the things we haven’t talked about is the fact that UITableView looks a lot more like a list than a table. Isn’t a table supposed to be two-dimensional? With columns and headers, like a spreadsheet? That’s what a table is in most other UI toolkits.

This takes me back to a job I had back in 2002 or so, building a Java UI for a network operations center. The idea was it would feed out video clips, and the engineers there needed to see what was in the queue to go out, its priority, where it was going, and so on.

The first cut of the UI used a Java Swing JTable and, yeah, it did look like an Excel spreadsheet. I’d been playing with Mac OS X by this point—I was the only one in the office using it, and took a lot of crap for doing so—and realized that this was a lousy user interface. The wide table made it hard to trace a single item all the way across the window, and reading vertically down columns wasn’t useful anyway. Also, JTable defaulted to making columns the same width, even when some of our fields were 4 characters and others were more than 40. It didn’t need to be a table; it didn’t work as a table.

So, I turned it into a list. I created custom cells that would group all the data together, using layout, fonts, and color to call out the stuff that mattered most, and how the items related to one another.

I liked it well enough that a decade later, with the company long gone, I still have screenshots. Here’s one of the lists from the main status window:

The purple color scheme, programmer art, aliased text, and bland Windows NT fonts are hard on the eyes 10 years later, but at the time, this was a real breakthrough for us in how we thought about our in-house UI. You could easily see what was going out when, which items had priority, and why the queue was arranged the way it was. The cell layouts made the whole list more readable, and I’ve been a big fan of custom cells in lists and tables ever since.