In this article by Donny Wals, from the book Mastering iOS 10 Programming, we will go through UITableView touch up. Chances are that you have built a simple app before. If you have, there’s a good probability that you have used UITableView. The UITableView is a core component in many applications. Virtually all applications that display a list of some sort make use of UITableView.
Because UITableView is such an important component in the world of iOS I want you to dive in to it straight away. You may or may not have looked at UITableView before but that’s okay. You’ll be up to speed in no time and you’ll learn how this component achieves that smooth 60 frames per seconds (fps) scrolling that users know and love. If your app can maintain a steady 60,fps your app will feel more responsive and scrolling will feel perfectly smooth to users which is exactly what you want. We’ll also cover new UITableView features that make it even easier to optimize your table views.
In addition to covering the basics of UITableView, you’ll learn how to make use of Contacts.framework to build an application that shows a list of your users’ contacts. This is similar to what the native Contacts app does on iOS.
The contacts in the UITableView component will be rendered in a custom cell. You will learn how to create such a cell, using Auto Layout. Auto Layout is a technique that will be covered throughout this book because it’s an important part of every iOS developer’s tool belt. If you haven’t used Auto Layout before, that’s okay. This article will cover a few basics, and the layout is relatively simple, so you can gradually get used to it as we go.
To sum it all up, this article covers:
- Configuring and displaying UITableView
- Fetching a user’s contacts through Contacts.framework
- UITableView delegate and data source
(For more resources related to this topic, see here.)
Setting up the User Interface (UI)
Every time you start a new project in Xcode, you have to pick a template for your application. These templates will provide you with a bit of boiler plate code or sometimes they will configure a very basic layout for you. Throughout this book, the starting point will always be the Single View Application template. This template will provide you with a bare minimum of boilerplate code. This will enable you to start from scratch every time, and it will boost your knowledge of how the Xcode-provided templates work internally.
In this article, you’ll create an app called HelloContacts. This is the app that will render your user’s contacts in a UITableView. Create a new project by selecting File | New | Project. Select the Single View template, give your project a name (HelloContacts), and make sure you select Swift as the language for your project. You can uncheck all CoreData– and testing-related checkboxes; they aren’t of interest right now. Your configuration should resemble the following screenshot:
Once you have your app configured, open the Main.storyboard file. This is where you will create your UITableView and give it a layout. Storyboards are a great way for you to work on an app and have all of the screens in your app visualized at once.
If you have worked with UITableView before, you may have used UITableViewController. This is a subclass of UIViewController that has a UITableView set as its view. It also abstracts away some of the more complex concepts of UITableView that we are interested in. So, for now, you will be working with the UIViewController subclass that holds UITableView and is configured manually.
On the right hand side of the window, you’ll find the Object Library. The Object Library is opened by clicking on the circular icon that contains a square in the bottom half of the sidebar. In the Object Library, look for a UITableView. If you start typing the name of what you’re looking for in the search box, it should automatically be filtered out for you. After you locate it, drag it into your app’s view. Then, with UITableView selected, drag the white squares to all corners of the screen so that it covers your entire viewport.
If you go to the dynamic viewport inspector at the bottom of the screen by clicking on the current device name as shown in the following screenshot and select a larger device such as an iPad or a smaller device such as the iPhone SE, you will notice that UITableView doesn’t cover the viewport as nicely. On smaller screens, the UITableView will be larger than the viewport. On larger screens, UITableView simply doesn’t stretch:
This is why we will use Auto Layout. Auto Layout enables you to create layouts that will adapt to different viewports to make sure it looks good on all of the devices that are currently out there. For UITableView, you can pin the edges of the table to the edges of the superview, which is the view controller’s main view. This will make sure the table stretches or shrinks to fill the screen at all times.
Auto Layout uses constraints to describe layouts. UITableView should get some constraints that describe its relation to the edges of your view controller. The easiest way to add these constraints is to let Xcode handle it for you. To do this, switch the dynamic viewport inspector back to the view you initially selected.
First, ensure UITableView properly covers the entire viewport, and then click on the Resolve Auto Layout Issues button at the bottom-right corner of the screen and select Reset to Suggested Constraints:
This button automatically adds the required constraints for you. The added constraints will ensure that each edge of UITableView sticks to the corresponding edge of its superview. You can manually inspect these constraints in the Document Outline on the left-hand side of the Interface Builder window.
Make sure that everything works by changing the preview device in the dynamic viewport inspector again. You should verify that no matter which device you choose now, the table will stretch or shrink to cover the entire view at all times.
Now that you have set up your project with UITableView added to the interface and the constraints have been added, it’s time to start writing some code. The next step is to use Contacts.framework to fetch some contacts from your user’s address book.
Fetching a user’s contacts
In the introduction for this article, it was mentioned that we would use Contacts.framework to fetch a user’s contacts list and display it in UITableView.
Before we get started, we need to be sure we have access to the user’s address book. In iOS 10, privacy is a bit more restrictive than it was earlier. If you want to have access to a user’s contacts, you need to specify this in your application’s Info.plist file. If you fail to specify the correct keys for the data your application uses, it will crash without warning. So, before attempting to load your user’s contacts, you should take care of adding the correct key to Info.plist.
To add the key, open Info.plist from the list of files in the Project Navigator on the left and hover over Information Property List at the top of the file. A plus icon should appear, which will add an empty key with a search box when you click on it. If you start typing Privacy – contacts, Xcode will filter options until there is just one left, that is, the key for contact access. In the value column, fill in a short description about what you are going to use this access for. In our app, something like read contacts to display them in a list should be sufficient.
Whenever you need access to photos, Bluetooth, camera, microphone, and more, make sure you check whether your app needs to specify this in its Info.plist. If you fail to specify a key that’s required, your app will crash and will not make it past Apple’s review process.
Now that you have configured your app to specify that it wants to be able to access contact data, let’s get down to writing some code. Before reading the contacts, you’ll need to make sure the user has given permission to access contacts. You’ll have to check this first, after which the code should either fetch contacts or it should ask the user for permission to access the contacts. Add the following code to ViewController.swift. After doing so, we’ll go over what this code does and how it works:
class ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let store = CNContactStore()
if CNContactStore.authorizationStatus(for: .contacts) == .notDetermined {
store.requestAccess(for: .contacts, completionHandler: {[weak self] authorized, error in
if authorized {
self?.retrieveContacts(fromStore: store)
}
})
} else if CNContactStore.authorizationStatus(for: .contacts) == .authorized {
retrieveContacts(fromStore: store)
}
}
func retrieveContacts(fromStore store: CNContactStore) {
let keysToFetch =
[CNContactGivenNameKey as CNKeyDescriptor,
CNContactFamilyNameKey as CNKeyDescriptor,
CNContactImageDataKey as CNKeyDescriptor,
CNContactImageDataAvailableKey as CNKeyDescriptor]
let containerId = store.defaultContainerIdentifier()
let predicate = CNContact.predicateForContactsInContainer(withIdentifier: containerId)
let contacts = try! store.unifiedContacts(matching: predicate, keysToFetch: keysToFetch)
print(contacts)
}
}In the viewDidLoad method, we will get an instance of CNContactStore. This is the object that will access the user’s contacts database to fetch the results you’re looking for. Before you can access the contacts, you need to make sure that the user has given your app permission to do so. First, check whether the current authorizationStatus is equal to .notDetermined. This means that we haven’t asked permission yet and it’s a great time to do so. When asking for permission, we pass a completionHandler. This handler is called a closure. It’s basically a function without a name that gets called when the user has responded to the permission request. If your app is properly authorized after asking permission, the retrieveContacts method is called to actually perform the retrieval. If the app already had permission, we’ll call retrieveContacts right away.
Completion handlers are found throughout the Foundation and UIKit frameworks. You typically pass them to methods that perform a task that could take a while and is performed parallel to the rest of your application so the user interface can continue running without waiting for the result. A simplified implementation of such a function could look like this:
func doSomething(completionHandler: Int -> Void) { // perform some actions
var resultingValue = theResultOfSomeAction()
completionHandler(resultingValue)
}You’ll notice that actually calling completionHandler looks identical to calling an ordinary function or method. The idea of such a completion handler is that we can specify a block of code, a closure, that is supposed to be executed at a later time. For example, after performing a task that is potentially slow. You’ll find plenty of other examples of callback handlers and closures throughout this book as it’s a common pattern in programming.
The retrieveContacts method in ViewController.swift is responsible for actually fetching the contacts and is called with a parameter named store. It’s set up like this so we don’t have to create a new store instance since we already created one in viewDidLoad. When fetching a list of contacts, you use a predicate. We won’t go into too much detail on predicates and how they work yet. The main goal of the predicate is to establish a condition to filter the contacts database on.
In addition to a predicate, you also provide a list of keys your code wants to fetch. These keys represent properties that a contact object can have. They represent data, such as e-mail, phone numbers, names, and more. In this example, you only need to fetch a contact’s given name, family name, and contact image. To make sure the contact image is available at all, there’s a key request for that as well.
When everything is configured, a call is made to unifiedContacts(matching:, keysToFetch:). This method call can throw an error, and since we’re currently not interested in the error, try! is used to tell the compiler that we want to pretend the call can’t fail and if it does, the application should crash.
When you’re building your own app, you might want to wrap this call in do {} catch {} block to make sure that your app doesn’t crash if errors occur. If you run your app now, you’ll see that you’re immediately asked for permission to access contacts. If you allow this, you will see a list of contacts printed in the console. Next, let’s display some content information in the contacts table!
Creating a custom UITableViewCell for our contacts
To display contacts in your UITableView, you will need to set up a few more things. First and foremost, you’ll need to create a UITableViewCell that displays contact information. To do this, you’ll create a custom UITableViewCell by creating a subclass. The design for this cell will be created in Interface Builder, so you’re going to add @IBOutlets in your UITableViewCell subclass. These @IBOutlets are the connection points between Interface Builder and your code.
Designing the contact cell
The first thing you need to do is drag a UITableViewCell out from the Object Library and drop it on top of UITableView. This will add the cell as a prototype.
Next, drag out UILabel and a UIImageView from the Object Library to the newly added UITableViewCell, and arrange them as they are arranged in the following figure. After you’ve done this, select both UILabel and UIImage and use the Reset to Suggested Constraints option you used earlier to lay out UITableView. If you have both the views selected, you should also be able to see the blue lines that are visible in following screenshot:
These blue lines represent the constraints that were added to lay out your label and image. You can see a constraint that offsets the label from the left side of the cell. However, there is also a constraint that spaces the label and the image. The horizontal line through the middle of the cell is a constraint that vertically centers the label and image inside of the cell. You can inspect these constraints in detail in the Document Outline on the right. Now that our cell is designed, it’s time to create a custom subclass for it and hook up @IBOutlets.
Creating the cell subclass
To get started, create a new file (File | New | File…) and select a Cocoa Touch file. Name the file ContactTableViewCell and make sure it subclasses UITableViewCell, as shown in the following screenshot:
When you open the newly created file, you’ll see two methods already added to the template for ContactTableViewCell.swift: awakeFromNib and setSelected(_:animated:). The awakeFromNib method is called the very first time this cell is created; you can use this method to do some initial setup that’s required to be executed only once for your cell.
The other method is used to customize your cell when a user taps on it. You could, for instance, change the background color or text color or even perform an animation. For now, you can delete both of these methods and replace the contents of this class with the following code:
@IBOutlet var nameLabel: UILabel!
@IBOutlet var contactImage: UIImageView!The preceding code should be the entire body of the ContactTableViewCell class. It creates two @IBOutlets that will allow you to connect your prototype cell with so that you can use them in your code to configure the contact’s name and image later.
In the Main.storyboard file, you should select your cell, and in the Identity Inspector on the right, set its class to ContactTableViewCell (as shown in the following screenshot). This will make sure that Interface Builder knows which class it should use for this cell, and it will make the @IBOutlets available to Interface Builder.
Now that our cell has the correct class, select the label that will hold the contact’s name in your prototype cell and click on Connections Inspector. Then, drag a new referencing outlet from the Connections Inspector to your cell and select nameLabel to connect the UILabel in the prototype cell to @IBOutlet in the code (refer to the following screenshot). Perform the same steps for UIImageView and select the contactImage option instead of nameLabel.
The last thing we need to do is provide a reuse identifier for our cell. Click on Attributes Inspector after selecting your cell. In Attributes Inspector, you will find an input field for the Identifier. Set this input field to ContactTableViewCell. The reuse identifier is the identifier that is used to inform the UITableView about the cell it should retrieve when it needs to be created.
Since the custom UITableViewCell is all set up now, we need to make sure UITableView is aware of the fact that our ViewController class will be providing it with the required data and cells.
Displaying the list of contacts
When you’re implementing UITableView, it’s good to be aware of the fact that you’re actually working with a fairly complex component. This is why we didn’t pick a UITableViewController at the beginning of this article. UITableViewController does a pretty good job of hiding the complexities of UITableView from thedevelopers.
The point of this article isn’t just to display a list of contacts; it’s purpose is also to introduce some advanced concepts about a construct that you might have seen before, but never have been aware of.
Protocols and delegation
Throughout the iOS SDK and the Foundation framework the delegate design pattern is used. Delegation provides a way for objects to have some other object handle tasks on their behalf. This allows great decoupling of certain tasks and provides a powerful way to allow communication between objects. The following image visualizes the delegation pattern for a UITableView component and its UITableViewDataSource:
The UITableView uses two objects that help in the process of rendering a list. One is called the delegate, the other is called the data source. When you use a UITableView, you need to explicitly configure the data source and delegate properties. At runtime, the UITableView will call methods on its delegate and data source in order to obtain information about cells, handle interactions and more.
If you look at the documentation for the UITableView delegate property it will tell you that its type is UITableViewDelegate?. This means that the delegate’s type is UITableViewDelegate. The question mark indicates that this value could be nil; we call this an Optional. The reason for the delegate to be Optional is that it might not ever be set at all. Diving deeper into what this UITableViewDelegate is exactly, you’ll learn that it’s actually a protocol and not a class or struct.
A protocol provides a set of properties and/or methods that any object that conforms to (or adopts) this protocol must implement. Sometimes a protocol will provide optional methods, such as UITableViewDelegate does. If this is the case, we can choose which delegate methods we want to implement and which method we want to omit. Other protocols mandatory methods. The UITableViewDataSource has a couple of mandatory methods to ensure that a data source is able to provide UITableView with the minimum amount of information needed in order to render the cells you want to display.
If you’ve never heard of delegation and protocols before, you might feel like this is all a bit foreign and complex. That’s okay; throughout this book you’ll gain a deeper understanding of protocols and how they work. In particular, the next section, where we’ll cover swift and protocol-oriented programming, should provide you with a very thorough overview of what protocols are and how they work. For now, it’s important to be aware that a UITableView always asks another object for data through the UITableViewDataSource protocol and their interactions are handled though the UITableViewDelegate. If you were to look at what UITableView does when it’s rendering contents it could be dissected like this:
- UITableView needs to reload the data.
- UITableView checks whether it has a delegate; it asks the dataSource for the number of sections in this table.
- Once the delegate responds with the number of sections, the table view will figure out how many cells are required for each section. This is done by asking the dataSource for the number of cells in each section.
- Now that the cell knows the amount of content it needs to render, it will ask its data source for the cells that it should display.
- Once the data source provides the required cells based on the number of contacts, the UITableView will request display the cells one by one.
This process is a good example of how UITableView uses other objects to provide data on its behalf. Now that you know how the delegation works for UITableView, it’s about time you start implementing this in your own app.
Conforming to the UITableViewDataSource and UITableViewDelegate protocol
In order to specify the UITableView‘s delegate and data source, the first thing you need to do is to create an @IBOutlet for your UITableView and connect it to ViewController.swift. Add the following line to your ViewController, above the viewDidLoad method.
@IBOutlet var tableView: UITableView!Now, using the same technique as before when designing UITableViewCell, select the UITableView in your Main.storyboard file and use the Connections Inspector to drag a new outlet reference to the UITableView. Make sure you select the tableView property and that’s it. You’ve now hooked up your UITableView to the ViewController code.
To make the ViewController code both the data source and the delegate for UITableView, it will have to conform to the UITableViewDataSource and UITableViewDelegate protocols. To do this, you have to add the protocols you want to conform to your class definition. The protocols are added, separated by commas, after the superclass. When you add the protocols to the ViewController, it should look like this:
class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate {
// class body
}Once you have done this, you will have an error in your code. That’s because even though your class definition claim to implement these protocols, you haven’t actually implemented the required functionality yet. If you look at the errors Xcode is giving you, it becomes clear that there’s two methods you must implement. These methods are tableView(_:numberOfRowsInSection:) and tableView(_:cellForRowAt:).
So let’s fix the errors by adjusting our code a little bit in order to conform to the protocols. This is also a great time to refactor the contacts fetching a little bit. You’ll want to access the contacts in multiple places so that the list should become an instance variable. Also, if you’re going to create cells anyway, you might as well configure them to display the correct information right away. To do so, perform the following code:
var contacts = [CNContact]()
// … viewDidLoad
// … retrieveContacts
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return contacts.count
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "contactCell") as! ContactTableViewCell
let contact = contacts[indexPath.row]
cell.nameLabel.text = "(contact.givenName) (contact.familyName)"
if let imageData = contact.imageData where contact.imageDataAvailable {
cell.contactImage.image = UIImage(data: imageData)
}
return cell
}The preceding code is what’s needed to conform to the UITableViewDataSource protocol. Right below the @IBOutlet of your UITableView, a variable is declared that will hold the list of contacts. The following code snippet was also added to the ViewController:
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return contacts.count
} This method is called by the UITableView to determine how many cells it will have to render. This method just returns the total number of contacts that’s in the contacts list. You’ll notice that there’s a section parameter passed to this method. That’s because a UITableView can contain multiple sections. The contacts list only has a single section; if you have data that contains multiple sections, you should also implement the numberOfSections(in:) method.
The second method we added was:
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = tableView.dequeueReusableCell(withIdentifier: "contactCell") as! ContactTableViewCell
let contact = contacts[indexPath.row]
cell.nameLabel.text = "(contact.givenName) (contact.familyName)"
if let imageData = contact.imageData where contact.imageDataAvailable {
cell.contactImage.image = UIImage(data: imageData)
}
return cell
} This method is used to get an appropriate cell for our UITableView to display. This is done by calling dequeueReusableCell(withIdentifier:) on the UITableView instance that’s passed to this method. This is because UITableView can reuse cells that are currently off screen. This is a performance optimization that allows UITableView to display vast amounts of data without becoming slow or consuming big chunks of memory. The return type of dequeueReusableCell(withIdentifier:) is UITableViewCell, and our custom outlets are not available on this class. This is why we force cast the result from that method to ContactTableViewCell. Force casting to your own subclass will make sure that the rest of your code has access to your nameLabel and contactImage.
Casting objects will convert an object from one class or struct to another. This usually only works correctly when you’re casting from a superclass to a subclass like we’re doing in our example. Casting can fail, so force casting is dangerous and should only be done if you want your app to crash or consider it a programming error in case the cast fails.
We also grab a contact from the contacts array that corresponds to the current row of indexPath. This contact is then used to assign all the correct values to the cell and then the cell is returned. This is all the setup needed to make your UITableView display the cells. Yet, if we build and run our app, it doesn’t work! A few more changes will have to be made for it to do so.
Currently, the retrieveContacts method does fetch the contacts for your user, but it doesn’t update the contacts variable in ViewController. Also, the UITableView won’t know that it needs to reload its data unless it’s told to. Currently, the last few lines of retrieveContacts will look like this:
let contacts = try! store.unifiedContacts(matching: predicate, keysToFetch: keysToFetch)
print(contacts)Let’s update these lines to the following code:
contacts = try! store.unifiedContacts(matching: predicate, keysToFetch: keysToFetch)
tableView.reloadData()Now, the result of fetching contacts is assigned to the instance variable that’s declared at the top of your ViewController. After doing that, we tell the tableView to reload its data, so it will go through the delegate methods that provide the cell count and cells again.
Lastly, the UITableView doesn’t know that the ViewControler instance will act as both the dataSource and the delegate. So, you should update the viewDidLoad method to assign the UITableView’s delegate and dataSource properties. Add the following lines to the end of the viewDidLoad method:
tableView.dataSource = self
tableView.delegate = selfIf you build and run it now, your app works! If you’re running it in the simulator or you haven’t assigned images to your contacts, you won’t see any images. If you’d like to assign some images to the contacts in the simulator, you can drag your images into the simulator to add them to the simulator’s photo library. From there, you can add pictures to contacts just as you would on a real device. However, if you have assigned images to some of your contacts you will see their images appear. You can now scroll through all of your contacts, but there seems to be an issue. When you’re scrolling down your contacts list, you might suddenly see somebody else’s photo next to the name of a contact that has no picture! This is actually a performance optimization.
Summary
Your contacts app is complete for now. We’ve already covered a lot of ground on the way to iOS mastery. We started by creating a UIViewController that contains a UITableView. We used Auto Layout to pin the edges of the UITableView to the edges of main view of ViewController. We also explored the Contacts.framework and understood how to set up our app so it can access the user’s contact data.
Resources for Article:
Further resources on this subject:
- Offloading work from the UI Thread on Android [article]
- Why we need Design Patterns? [article]
- Planning and Structuring Your Test-Driven iOS App [article]