Twitter Client

We are going to build a simple Twitter client for displaying the public timeline. We will be using AFNetworking to retrieve our date from the net, and a UITableView to display this data in our app.


Let’s start by making a request to the Twitter API and seeing what the response looks like.

If we pull out one entry from the response, we can find the relevant fields for our application.

Let’s build our own dictionary of tweets, stripping out all the data we don’t need.

We can now use our clean dictionary to populate our table view. We’ll set tweet as the main cell text and the user name as the detail text.

AFNetworking also includes a category (more on categories later) for UIImage which adds functionality to load a remote image.

As a final exercise, add a detail view controller to your app that is displayed when a cell is selected. The view should at least contain the tweet and user image of the corresponding cell, and you can also add more information to it if you’d like.

I will provide my sample application at the end of class.

URL Requests

Your apps will often be required to communicate with a remote server. URL requests are fairly complex and can fail for many reasons: the remote server can’t be reached, the remote server doesn’t understand your request, you don’t understand the server’s response, etc.

Luckily for us, there are many ways to communicate over the network on iOS. We will first look at the relevant Foundation framework classes , then explore a third-party tool that automates much of the process without taking away too much control.

Using the Foundation framework

Many classes are required to build a simple request:

  • NSURL references a URL address.
  • NSURLRequest represents this URL and holds a content cache policy.
  • NSURLConnection actually performs the connection and receives a response.
  • NSData is the container used to store the response data, before it can be interpreted.

As it takes time to perform a request and receive a response, this operation is often done asynchronously, on a separate thread. This allows our app to continue running while the operation is happening. If we were performing the request synchronously, the entire app would hang until a response was received.

As you may have already guessed, asynchronous requests are performed using delegation. The NSURLConnectionDelegate can implement many methods to receive constant status updates on the state of the request.

You can also check for connection errors before proceeding, by making sure that NSURLConnection is valid.

You can also check for errors during the operation, by implementing connection:didFailWithError:.

This example works properly because our response is small. Larger responses will come in chunks, and will call connection:didReceiveData: multiple times. For every call, you would need to append the new data to the old one until the operation is complete.


This is already a lot of overhead for what appears to be a trivial request, but all these steps are necessary as there is a lot is going on behind the scenes. There have been many attempts to simplify this process for programmers, and there are many solid tools out there that you can use. One of these tools is AFNetworking.

AFNetworking is a good solution because:

  • It inherits from Foundation classes and allows you to “step in” and use the NSxxx methods and objects if you need to.
  • It provides default settings and convenient setters and getters for headers, authentication, network reachability, batched operations, etc.
  • It distinguishes errors from successful requests using status codes and response types.
  • It includes media-specific request operations that transform NSData into more useable formats, like JSON, XML, and even images.
  • It uses blocks instead of delegation to handle callbacks, keeping together all the relevant code to an operation.

  1. URL Loading System Programming Guide. Apple, Jan 9 2010.
  2. AFNetworking. Mattt Thompson, Visited Oct 2 2012.

Pop Ups

Action Sheets

The UIActionSheet is used to ask a question with many possible answers.

When any button is selected, the sheet animates out of the view again. The destructive button is at the top and tinted in red. The cancel button is at the bottom and tinted in black. The remaining buttons are in between, in default grey.

The action sheet slides up from the bottom of the screen on iPhone and iPod, and appears in a popover on iPad.

To read and handle the selection in a UIActionSheet, an object must conform to the UIActionSheetDelegate protocol and set itself as that sheet’s delegate.


The UIAlertView is used to ask a question with only two answers (YES/NO, OK/CANCEL), or to inform the user of something going wrong. It is very disruptive to the user experience and should be used sparingly.

Similarly to the UIActionSheet, to read and handle the selection in a UIAlertView, an object must conform to the UIAlertViewDelegate protocol and set itself as that alert’s delegate.

Modal Navigation

Modal view controllers take over the entire screen and block all other navigation in the application until they are dismissed.

Modal segues are created similarly to hierarchical push segues, by control-dragging from an actionable object in one view controller, like a button, to another view controller. They can also be created in code using presentViewController:animated:completion:.

Header Source

By default, modal views animate by sliding from the bottom, covering the current view, but you can change that in the Storyboard if you need to.

Modal views are dismissed by calling dismissViewControllerAnimated:completion: on the presenting view controller, not on the presented modal view controller.

You usually do not want a modal view controller dismissing itself, but if you need to do so, you can use its presentingViewController property.

Header Source

The preferred way to dismiss a modal view is using delegation. When the modal view controller is finished, it reports back to its delegate (usually the presenter). It is then up to the delegate/presenter to dismiss the modal view.

Header Source

It is usually a good idea to make sure the delegate is set, and that it responds to the method we’re calling on it before proceeding.

Table Views

UITableView is used for displaying data in a one-dimensional table (a set of rows). Each row is an instance of UITableViewCell.

The UITableView is very efficient with large data sets and is highly customizable, so it’s often a good solution for displaying large amounts of data.

There are two styles of table views:

  • Plain – UITableViewStylePlain
  • Grouped – UITableViewStyleGrouped

UITableViewStylePlain   UITableViewStyleGrouped

The cells can also be organized into sections. You can see this in the Settings app, for example.

There are four built-in styles for cells:

  • Basic – UITableViewCellStyleDefault
  • Right Detail – UITableViewCellStyleValue1
  • Left Detail – UITableViewCellStyleValue2
  • Subtitle – UITableViewCellStyleSubtitle

Cells also have an optional accessory view. The built-in types are:

  • Disclosure Indicator – UITableViewCellAccessoryDisclosureIndicator
  • Detail Disclosure – UITableViewCellAccessoryDetailDisclosureButton
  • Checkmark – UITableViewCellAccessoryCheckmark

These are active controls, conventionally used to show extra information on that cell’s data.

Cells also have an optional image view. Notice that the Left Detail – UITableViewCellStyleValue2 cell does not display the image.

You can also build your own custom UITableViewCell, in which you can layout these subviews any way you please, and add more subviews if you need to.

Table view data can be static or dynamic.

Static Data

Static cells are built much like any other UI control we’ve seen so far. You can build them using the Storyboard, completing and referencing with a code counterpart, or strictly in code, by subclassing UITableViewCell.

If you want to use segues, you would need to add one per cell.

Dynamic Data

When switching to a dynamic table, the cell you customize in the Storyboard is not an actual instance, but a prototype for all cells in the list. The actual cell instances will be generated in code. To identify the prototype, you mut fill in its Identifier field. If you need to use multiple prototypes in the same table, you can differentiate them by using different Identifiers.

A dynamic table needs a data source. This is usually the view controller that holds the table view, but it can be any object that conforms to the UITableViewDataSource protocol. This protocol has two required methods:

Cell instantiations tend to not be used for very long. For example, imagine if you’re scrolling to the bottom of a table with 100 rows, you’ll be instantiating 99 cells just to fly through them. In order to deal with this, cell objects are recycled. When a cell goes off-screen, it gets put in a reuse pool. The next time a cell is needed, one will be grabbed from the reuse pool if available. If not, a new cell will be created and added to the reuse pool when it’s done.

Header Source

If you want multiple sections, you must implement numberOfSectionsInTableView:. You can then set a header and footer to each section using tableView:titleForHeaderInSection: and tableView:titleForFooterInSection:.

Table View Delegate

A table view will also tend to have a delegate, to control how the table is displayed (as opposed to what is displayed, which is covered by the data source). The delegate is usually the same object as the data source, and must conform to the UITableViewDelegate protocol.

There are many methods available in the UITableViewDelegate protocol to customize the appearance and behaviour of the table view.

  1. Table View Programming Guide for iOS. Apple, Sep 19 2012.
  2. Paul Hegarty. Lecture 9 Slides. iPad and iPhone Application Development. Stanford, Nov 21 2011.