If table views on iOS have one thing going for them, it’s that they’re routine fodder for introductory materials. Table views are where most developers new to working with Apple platforms encounter the delegation design pattern. Delegation is a routine stumbling block, most often encountered in UITableView. WKInterfaceTable, by contrast, has no datasource to set and no delegate to implement, and—most importantly—it eschews UIKit’s “don’t call us; we’ll call you” paradigm in favor of requiring you to tell it in advance all of the data it’ll need to display. If you’ve never used UITableView and have no idea what I’m talking about, don’t worry. You don’t need to have used it to understand WKInterfaceTable.
The difference between the two, as with many features of the Apple Watch UI, is that the display is divorced from the data. Your users scroll through content on the watch, and given its performance concerns, achieving the 60-frames-per-second scrolling users have come to expect from Apple devices requires tradeoffs. Instead of running code every time a new row comes onscreen, as you do with UITableView, you’ll populate the entire table at once, allowing the watch’s processor to take a break while the user moves the content up and down. This also helps battery life—another paramount concern for Apple Watch apps.
Architectural differences aside, you’ll notice as soon as you drag a WKInterfaceTable onto the storyboard that each distinct type of row in the table is nothing more than a WKInterfaceGroup. Unlike UIKit’s UITableViewCell, there’s no built-in UI element to repurpose. Your table view rows will be fully custom groups, configured with whatever interface objects make sense. To serve as a bridge between your interface controller and your table rows, you’ll create objects that coordinate the data, known as row controllers. Now, what to put in a table? To introduce using tables to show data, let’s create a new screen in TapALap—one for displaying the user’s run history in the app.
3.15.25.131