Table Classes

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Table Classes

To add a table to an iOS app, we use an instance of UITableView. This is a UIScrollView subclass, itself a subclass of UIView, so it can either be a full-screen view unto itself or embedded as the child of another view. It cannot, however, have arbitrary subviews added to it, as it uses its subviews to present the individual cells within the table view.

The table has two properties that are crucial for it to actually do anything. The most important is the dataSource, which is an object that implements the UITableViewDataSource protocol. This protocol defines methods that tell the table how many sections it has (and optionally what their titles are) and how many rows are in a given section, and provides a cell view for a given section-row pair. The data source also has editing methods that allow for the addition, deletion, or reordering of table contents. There’s also a delegate, an object implementing the UITableViewDelegate protocol, which provides method definitions for handling selection of rows and other user interface events.

These roles are performed not by the table itself—whose only responsibility is presenting the data and tracking user gestures like scrolling and selection—but by some other object, often a view controller. Typically, there are two approaches to wiring up a table to its contents:

Have a UIViewController implement the UITableViewDataSource and UITableViewDelegate protocols.
Use a UITableViewController, a subclass of the UIViewController that is also defined as implementing the UITableViewDataSource and UITableViewDelegate protocols

It’s helpful to use the second approach when the only view presented by the controller is a table, as this gives us some nice additional functionality like built-in pull-to-refresh, or scrolling to the top when the status bar is tapped. But if the table is just a subview, and the main view has other subviews like buttons or a heads-up view, then we need to use the first approach instead.

The careful apportioning of responsibilities between the view class and the controller comes from UIKit’s use of the model-view-controller design pattern, or MVC. The idea of this design is to split out three distinct responsibilities of our UI:

Model—The data to be presented, such as the array of tweets
View—The user interface object, like a text view or a table
Controller—The logic that connects the model and the view, such as how to fill in the rows of the table, and what to do when a row is tapped

This pattern explains why the class we’ve been doing most of our work in is a “view controller”; as a controller, it provides the logic that populates an onscreen view, and updates its state in reaction to user interface events. Notice that it is not necessary for each member of the design to be have its own class: the view is an object we created in the storyboard, and the model can be a simple object like an array. At this point in our app’s evolution, only the controller currently requires a custom class. Still, some developers prefer the clarity of each role having its own class, so sometimes you’ll see a class that exists only to implement UITableViewDataSource for a given table.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Table Classes

Create new playlist

Sign In

Sign Up

Table Classes

Table of Contents for
Table Classes