Chapter 4. Multiple Views: A table with a view

Most iOS apps have more than one view.

We’ve written a cool app with one view, but anyone who’s used a smartphone knows that most apps aren’t like that. Some of the more impressive iOS apps out there do a great job of working with complex information by using multiple views. We’re going to start with navigation controllers and table views, like the kind you see in your Mail and Contacts apps. Only we’re going to do it with a twist...

Brain Barbell

This chapter is about apps with more than one view. What views would you need to have for a bartending app?

____________________________________________________________________________________

So, how do these views fit together?

Before you pick the template for our bartending app, take a minute to look at how you want the user to interact with the drink information. We’re going to have a scrollable list of drink names, and when the user taps on a row, we’ll show the detailed drink information using view #2, our detail view. Once our user has seen enough, they’re going to want to go back to the drink list.

Brain Barbell

Below are the templates available for an app. Which do you think we should use for DrinkMixer?

	Window-based Application		View-based Application		Utility Application		Split view-based Application
	Tab Bar Application		OpenGL ES Application		Navigation-based Application

The navigation template pulls multiple views together

For this app, we’re going to use a Navigation-based project. The navigation template comes with a lot of functionality built in, including a navigation controller, which handles transitions between views, and the ability to deal with hierarchical data. Hierarchical data means there’s layers to it, and each view gives you more detail than the previous one.

Do this!

To get started, go into Xcode and choose the File→New Project option. Choose the Navigation-based application and name it DrinkMixer. Make sure that “Use Core Data” and “Include Unit Tests” are not checked.

The table view is built in

The navigation template comes with a navigation controller and a root view that the controller displays on startup. That root view is set up with a table view by default, and that works great for our app, so we’ll keep it that way. A table view is typically used for listing items, one of which can then be selected for more details about that item.

There are no Dumb Questions

Q:
Q: If the navigation template is about handing lots of views, why does it only come with one?
A:
A: Most navigation-based applications start out with a table view and show detailed views from there. The number of detailed views, what they look like, etc., are very application-specific, so you have to decide which views you want and add those views. The navigation template doesn’t assume anything beyond the initial table view.
Q:
Q: Which built-in apps on iOS use the Navigation control?
A:
A: Contacts and Mail, which are both core iOS apps, use this design. It’s a good idea to spend some time with those apps on your phone to see how the entire template is implemented. For a neat twist, take a look at the Messages (SMS) app. That one uses a Navigation Controller but frequently starts in the “detail” view, showing the last person you sent or received a message from.
On the iPad, Mail uses navigation control, too, but it’s part of a split view-based application. We’ll get into that more in a couple of chapters.
Q:
Q: The UITextField looks editable. Shouldn’t we fix that?
A:
A: Maybe. We’re going to go on to use that field in a few different ways, so think about it again at the end of the app in a couple of chapters.
To make it look less editable, you can change the font or change the border.
Q:
Q: Do I have to use a table view for my root view?
A:
A: No, it’s just the most common, since it provides a natural way to show an overview of a lot of data and have the user drill down for more information. Table views are very easily customized, too, so some apps that might not seem like table views really are, like Notes or the iTunes store, for example.
Q:
Q: How does the navigation controller relate to view controllers?
A:
A: We’ll talk a lot more about this in a minute, but the Navigation Controller coordinates the transition between view controllers. Typically, each top-level view is backed by a View Controller, and as views transition onscreen, the corresponding View Controller starts getting events from its view. There’s a whole view lifecycle that we’ll work through that lets a View Controller know what’s going on with its view.

The Table View Up Close

Navigation controllers and table views are almost always used together to work with hierarchical data. When you selected the navigation-based project as your template, Xcode created a different view setup than we’ve used in the past. The template includes MainWindow.xib, which has a single UINavigationController in it. That controller starts out with a main view, which is a UITableView that is loaded from RootViewController.xib (which is actually a subclass of UITableViewController.xib).

A table is a collection of cells

The UITableView provides a lot of the functionality we need right away, but it still needs to know what data we’re actually trying to show and what to do when the user interacts with that data. This is where the datasource and delegate come in. A table view is easy to customize and is set up by the template to talk to the datasource and delegate to see what it needs to show, how many rows, what table cells to use, etc.

Note

Remember that MVC pattern from Chapter 1? Now we’re adding in the Model piece with a datasource for our drinks list.

Brain Power

Look through some of the apps you have on your device. What are some of the most customized table views you can find? Are they using sections? Are they grouped? How did they lay out their cells?

There are no Dumb Questions

Q:
Q: How do cells get into that reusable list to begin with?
A:
A: The table view handles that. When cells scroll off the screen (either the top or the bottom), the table view will queue up cells that are no longer needed. When it asks the datasource for a cell for a particular row, you can check that queue of cells to see if there are any available for use.
Q:
Q: I don’t understand the cell identifier...does it have to be “Cell”?
A:
A: No—that’s just the default. When you do more complex table views, you can create custom cell types depending on what data you’re trying to display. You use the cell identifier to make sure that when you ask for a reusable cell, the table view gives you back the type you expect. The identifier can be anything you want—just make sure you have a unique name for each unique cell type you use.

Sharpen your pencil

It’s time to start displaying some drinks. You’ll need to make some modifications to both the RootViewController.h and RootViewController.m files.

Declare the drinks array.
Using syntax similar to what we used for the picker, declare an array called “drinks” in RootViewController.h with the necessary properties declaration.
Implement and populate the array.
In RootViewController.m, uncomment and expand the viewDidLoad method to create the array with the three drinks from the drink list here.
Tell the table how many rows you have.
The auto-generated code needs to be modified to tell the table that it will have the same number of rows as there are drinks in the array. Modify the implementation file under this line: // Customize the number of rows in the table view.
Populate the table cells.
Implement the code that we talked about in “Table Cell Code Up Close” so that the table gets populated with the items from the array.

You’re right. Like everything else on iOS, the UITableView does have to worry about memory.

So, how does it balance concerns about memory with an unknown amount of data to display? It breaks things up into cells.

Each drink gets its own temporary cell

The UITableView only has to display enough data to fill an iPhone screen—it doesn’t really matter how much data you might have in total. The UITableView does this by reusing cells that scrolled off the screen.

In this part of the MVC pattern, the datasource (M) updates the view (V) whenever it has to scroll to a new row.

There are no Dumb Questions

Q:
Q: You mentioned the table view’s datasource and delegate, but why didn’t I have to conform to anything like we did with UIPickerView?
A:
A: Great catch. Normally you would, but the navigation-based template we used has already set this up. To see what’s happening, look at the RootViewController.h file. You’ll see that it is a subclass of UITableViewController, and that class conforms to the UITableViewDataSourceProtocol and the UITableViewDelegateProtocol. If you look in RootViewController.xib, you’ll see that the table view’s datasource and delegate are both set to be our RootViewController. If we weren’t using a template, you’d have to set these up yourself (we’ll revisit this again later in the book).
Q:
Q: I noticed we used an NSMutableArray. Is that because we had to initialize it?
A:
A: No—both NSMutableArray and NSArray can be initialized with values when you create them. We’re using an NSMutableArray because we’re going to manipulate the contents of this array later. We’ll get there in a minute.
Q:
Q: What’s the nil at the end of the drink names when we create the drink array?
A:
A: NSMutableArray’s initializer takes a variable number of arguments. It uses nil to know it’s reached the end of the arguments. The last element in the array will be the value before the nil—nil won’t (and can’t) be added to the array.
Q:
Q: Tell me again about that @ symbol before our drink names?
A:
A: The @ symbol is shorthand for creating an NSString. NSArrays store arrays of objects, so we need to convert our text names (char*s) to NSStrings. We do that by putting an @ in front of the text constant.
Q:
Q: When we customized the table view cells, we used the cell.textLabel. Are there other labels? What’s the difference between cell.textLabel and cell.text?
A:
A: Before the iPhone 3.0 SDK, there was just one label and set of disclosure indicators in the default cell, and it was all handled by the cell itself. You just set the text you wanted on the cell.text property. Nearly everyone wanted a little more information on the table cells, so in the iPhone 3.0 SDK, Apple added a few different styles with different label layouts. Once they did that, they introduced specific properties for the different text areas, like textLabel, detailLabel, etc., and deprecated the old cell.text property. You shouldn’t use cell.text in your apps—Apple will likely remove it at some point in the future. We’ll talk more about the other labels later in the chapter.
Q:
Q: You mention that we can use section headers and footers—how do you specify those?
A:
A: The datasource is responsible for that information, too. There are optional methods you can provide that return the title for section headers and the title for section footers based on the section number. They work a lot like our cellForRowAtIndexPath, except they only return strings.
Q:
Q: What’s the difference between a plain table view and a grouped table view?
A:
A: The only difference is the appearance. In a plain table view, like the one we’re using, all the sections touch each other and are separated by the section header and footer if you have them. In a grouped table view, the table view puts space between the sections and shows the section header in bigger letters. Take a look at your contact list, then select a contact. The first view, where all of your contacts are listed together and separated by letters, is a plain table view. The detailed view, where the phone numbers are separated from email addresses, etc., is a grouped table view.
Q:
Q: So why are you putting underscores after instance variables again?
A:
A: Remember there are really different things in play when we talk about instance variables and properties. Instance variables are the actual attributes that hold data. We use _’s after those names to help indicate that those are actually internal class information, not really something we want other classes poking around with (we also mark them as private so the compiler enforces that for us).
Next, we have properties. By declaring something as a property, we get the ability to use the dot notation. Accessing a property through the dot notation gets turned into a call to setSomeProperty(...) or getSomeProperty(...). Memory management, copying values we want copied, etc., are all handled in those accessors. To make sure we don’t accidentally refer to an instance variable when we really want the functionality of the accessors and vice-versa, we name the instance variable with an ‘_’ and property without.

Just a few more drinks...

Get ready to start typing...

We could, but not the way we’re set up now.

Since the drinks are populated with an array that’s hardcoded into the implementation file, we can’t import anything.

What would work well is a standardized way to read and import data; then we would be able to quickly get that drink list loaded.

Brain Power

There must be a better way to handle this. How can we speed up getting 40 drinks in our list?

Plists are an easy way to save and load data

Plist stands for “property list” and has been around for quite a while with OS X. In fact, there are a number of plists already in use in your application. We’ve already worked with the most important plist, DrinkMixer-Info.plist. This is created by Xcode when you first create your project, and besides the app icons, it stores things like the main nib file to load when the application starts, the application version, and more. Xcode can create and edit these plists like any other file. Click on DrinkMixer-Info.plist to take a look at what’s inside.

Built-in types can save and load from plists automatically

All of the built-in types we’ve been using, like NSArray and NSString, can be loaded or saved from plists automatically. They do this through the NSCoding protocol. We can take advantage of this and move our drink list out of our source code and into a plist.

Exercise

Before you import Sam’s list, let’s create a sample plist that’s the same format. We’ll make sure we get that working properly, and then pull in Sam’s list.

Create the empty plist.
Go back into Xcode and expand the Supporting Files folder. Right-click on Resources and select New file→Mac OS X Resource, and Property List. Call the new list DrinkArray.plist.
Note
Make sure you pick “Resource” under Mac OS X—plists aren’t listed under iOS Resources.
Format and populate the plist.
Open up the file using the Open As→Source Code and change the <dict/> to <array/> and save. Then right-click and use the Open As→ASCII Property List option. Right-click inside the plist editor and click Add Row. You will need three string items. Then you can populate the names for the drinks.

Exercise Solution

With the sample list created, we can use it for testing before we get the big list.

Create the empty plist.
Go back into Xcode and expand the Supporting Files folder. Right-click on Resources and select New file→Mac OS X Resource, and Property List. Call the new list DrinkArray.plist.
Format and populate the plist.
Open up the file using the Open As→Source Code and change the <dict/> to <array/> and save. Then right-click and use the Open As→ASCII Property List option. Right-click inside the plist editor and click Add Row. You will need three string items. Then you can populate the names for the drinks.

Arrays (and more) have built-in support for plists

Changing the array initialization code to use the plist is remarkably easy. Most Cocoa collection types like NSArray and NSDictionary have built-in support for serializing to and from a plist. As long as you’re using built-in types (like other collections, NSStrings, etc.), you can just ask an array to initialize itself from a plist.

The only piece missing is telling the array which plist to use. To do that, we’ll use the project’s resource bundle, which acts as a handle to application-specific information and files. Add the bolded code below to your RootViewController.m file.

Creating your detail view will complete the app.

The entire list of drinks is great, but Sam still needs to know what goes in those views and how to make them. That information is going to go in the detail view that we sketched up earlier.

Brain Barbell

How are we going to get from the list to the detail view? And how are we going to display the details?

Use a detail view to drill down into data

Earlier, we classified DrinkMixer as a productivity app and we chose a navigation controller because we have hierarchical data. We have a great big list of drinks loaded, but what Sam needs now is the detailed information for each drink: what are the ingredients, how do you mix them, etc. Now we’ll use that navigation controller to display a more detailed view of a drink from the list.

The standard pattern for table views is that you show more information about an item when a user taps on a table cell. We’ll use that to let the user select a drink and then show our detailed view. The detail view follows the same MVC pattern as our other views.

A closer look at the detail view

We sketched out the detail view earlier—but let’s look more closely at what we’re about to build.

Let’s start building...

Long Exercise

You’ve got the hang of this now. Start building your detail view by creating the files and code you’ll need, then put it together in Interface Builder and wire it up. Get to it!

Create the files you’ll need.
To create the new view, you need a new *.xib file, as well as the supporting header and implementation files. The file type is a Cocoa Touch Class type, and it’s a UIViewController subclass.
Lay out the new view in Xcode.
Use the object library to drag and drop the elements that you need and build the view we sketched out earlier.
Hint: to reserve the space for the navigation controller, just bring up the Utilities Panel and choose the Attributes Inspector. Under Simulated Metrics, Top Bar, select Navigation Controller. That will make sure that you lay out your view below the navigation bar.
Write the code to handle the declarations and outlets for the new properties.
You’ll need to work in both DetailViewController.h and DetailViewController.m. Call the new properties nameTextField, ingredientsTextView, and directionsTextView. Don’t forget to create the instance variables then synthesize and release everything.
Connect the detail view to the new outlets.
Just like we did for InstaEmail, use Interface Builder to link the controls to the properties.
Make the text fields uneditable.
Using the inspector, find the checkbox that makes the fields uneditable.

There are no Questions

Q:
Q: We keep drawing the datasource, view, and View Controller as separate things, but then we stick the datasource and controller together into the same class. What’s going on?
A:
A: It’s all about the pattern. In general, you’ll have a view defined in a xib, a View Controller backing it, and a set of data it needs to work on. Whether these are combined into one class or not really depends on the complexity of your application. If you’re not using Interface Builder, you can go completely off the deep end and have your single class create the view programmatically. We’ll show more of that later in the book. Conceptually, however, you still have a view that’s calling into the View Controller when things happen. Likewise, you usually have one or more datasource protocols being realized somewhere that are providing data to your view.
Q:
Q: Why do we have to move the *.xib file into the Resources group?
A:
A: You don’t have to, but we recommend it to help keep your code organized. Different developers use different groups, things like “User Interface,” “Business Objects,” “Data Objects,” etc. Xcode really doesn’t care; it’s just important that you know how your code is organized and you can find what you’re looking for. Reusing a structure that others will recognize is a good practice so people can pick up your code quickly and you can understand their code. We use the templated defaults in this book.
Q:
Q: What are other ways to save and load data?
A:
A: There are quite a few of them. We’ll cover the more common ones in this book in different projects. The one you’re using now, plists, is the simplest, but it does limit what you can save and load. That doesn’t make it bad; if it works for what you need, it’s a fine solution—it’s just too limited for everything. There’s a serialization protocol called NSCoding that works well for custom objects, but can make version migration a challenge. iOS supports saving and loading to a database using SQLite. This used to be the preferred way to go if you had a lot of data or needed to search and access it without loading it all into memory. However, with the iPhone 3.0 SDK (now just iOS), Apple introduced Core Data. Core Data is a very powerful framework that provides an OO wrapper on persistence and has nearly all the benefits of using SQLite. It’s definitely not trivial to get started, but it’s really powerful. We’ll build an app on it later.
Q:
Q: Why didn’t you use a label for the name field?
A:
A: UITextFields allow you to have placeholder text that appears in the field when it’s empty. Rather than using up screen space with a Name label, we chose to use the placeholder. If the meaning of the text shown on the screen is obvious to the user, consider using placeholder text.
Q:
Q: So why didn’t we use it for the ingredients and directions?
A:
A: We could have, but since those contain multiple lines of text, we wanted to break them up with labels clearly showing what they were. Ultimately it’s an aesthetic and usability decision, not a technical one.

Long Exercise Solution

Here’s all the info for the new detail view. After this, you should have a working (but still empty) detail view.

Create the files you’ll need.
We need a new .xib for the detail view. To create one from scratch, go back into Xcode and click on the File→New→New File menu option.
After clicking Next, you can confirm the subclass of UIViewController. In our case, we need both the nib and the supporting files, so leave the “With XIB for user interface” box checked and click Next.
One more thing. Xcode will create all your files in the DrinkMixer group, keeping them with the other class files. Name the file “DrinkDetailViewController.m.”
Lay out the new view in Xcode.
Write the code to handle the declarations and outlets for the new fields.
Connect the detail view to the new outlets.
All three outlets—the directionsTextView, the ingredientsTextView, and the nameTextField—need to be connected to their control on the new view.
Make the text fields un-editable.
We need to disable both the UITextField and the two UITextViews to prevent the user from making changes. Simply click on each field and toggle the Enabled or Editable checkboxes to off.
Once those changes are made, the keyboard issue goes away, because there won’t be one!

Sharpen your pencil

When your users browse through the drink information, they’re going to need to switch between the list and detail views. Take a few minutes to think about how to do that while keeping the user from getting lost.

How does the user navigate between views?
_______________________________________________
_______________________________________________
How can we keep track of what view to show?
_______________________________________________
_______________________________________________
How does the detail view know what drink to show?
_______________________________________________
_______________________________________________
How do you get the user back to the table view?
_______________________________________________
_______________________________________________

Sharpen your pencil Solution

When your users browse through the drink information, they’re going to need to switch between our list and detail views. Think about how we do that and keep the user from getting lost.

How does the user navigate between views? The user is going to tap on the cell of the drink name that they want to see.
How can we keep track of what view to show? The Navigation Controller will keep track with back buttons and the title of the pane.
How does the detail view know what drink to show? That’s based on the table cell that the user selects.
How do you get the user back to the table view? The Navigation Controller can supply a back button that can get us back to the main view.

Use the Navigation Controller to switch between views

Now that we’ve got the table view populated and the detail view built, it’s time to manage moving between the two views. The navigation-based template comes preloaded with the functionality we need:

A view stack for moving between views
As users move back and forth, you can ask the Navigation Controller to display the appropriate view. The Navigation Controller keeps track of where the users are and gives them buttons to go back.
A navigation bar for buttons and a title
The Navigation Controller interacts with the navigation bar to display buttons that interact with the view being shown, along with a title to help the users know where they are.
A navigation toolbar for view-specific buttons
The Navigation Controller can display a toolbar at the bottom of the screen that shows custom buttons for its current view.

The UINavigationController supports a delegate, called the UINavigationControllerDelegate, that gets told when the controller is about to switch views, but for DrinkMixer, we won’t need this information. Since the views get told when they’re shown and hidden, that’s all we need for our app.

Now we need to get the Table View and Nav Controller working together to display the detail view.

Navigation Controllers maintain a stack of View Controllers

We’ve been dragging the Navigation Controller along since the beginning of this project, and now we finally get to put it to use. The Navigation Controller maintains a stack of views and displays the one on top. It will also automatically provide a back button, as well as the cool slide-in and-out animations. We’re going to talk more about the whole Navigation Controller stack in the next chapter, but for now, we’re just going to push our new view onto the stack and let the controller take care of the rest. We just need to figure out how to get that new view.

Brain Power

Here’s where things get interesting: our RootViewController is our delegate, so it needs to hand off control to a new View Controller to push the detail view onto the screen. How do you think we should handle that?

Instantiate a View Controller like any other class

The only piece left to create is the View Controller for the detail view. Instantiating a View Controller is no different than instantiating any other class, with the exception that you can pass in the nib file it should load its view from:

[[DrinkDetailViewController alloc] initWithNibName:@"DrinkDetailView
Controller" bundle:nil];

Once we’ve created the detail View Controller, we’ll ask the NavigationController to push the new View Controller onto the view stack. Let’s put all of this together by implementing the callback in the delegate and creating the new View Controller to push onto the stack:

Let’s try this out...

Yep, we’ve outgrown our array.

All that’s left is to get the ingredients and directions in the detail view, and we’ll have a bartender’s brain. To save you from having to type in the ingredients and directions, we put together a new file with all the extra information. The problem is we can’t just jam that information into an array. To add the drink details to this version, we need a different data model.

Sharpen your pencil

Which options below are possible ways to load the drink data?

	Create a database with drink information		Use dictionaries in our plist to hold the drink details
	Use an XML file to hold the drink details		Create multiple arrays in our plist

Which of these options is the best for DrinkMixer? Why? __________________

__________________________________________________________________________

Sharpen your pencil Solution

Which options below are possible ways to load the drink data?

Which of these options is the best for DrinkMixer? Why? Since we already have code written that uses plists, we can change our plist to have an array of dictionaries instead of an array of strings without a lot of effort. This way we don’t have to introduce SQL or XML into our project. However, we do lose out on the strong typing and data checking that both SQL and XML could give us. Since this is a smaller project, we’re going to go with dictionaries.

Dictionaries store information as key-value pairs

Our current drink plist is just a single array of drink names. That worked great for populating the table view with just drink names, but doesn’t help us at all with drink details. For this plist, instead of an array of strings, we created an array of dictionaries. Within each dictionary are three keys: name, ingredients, and directions. Each of these have string values with the corresponding information. Since NSDictionary adopts the NSCoding protocol, it can be saved and loaded in plists just like our basic array from before.

There are no Dumb Questions

Q:
Q: You keep talking about NSCoding. What is that?
A:
A: NSCoding is a protocol that provides an API for encoding and decoding objects. A lot of the basic container types like NSArray NSDictionary conform to this protocol; that’s why we can serialize them in and out of a plist. You can conform to this protocol on your own custom objects as well. For more information about NSCoding, see the Apple documentation.
Q:
Q: Where did the back button in the detail view come from? We didn’t do that...
A:
A: It’s automatic functionality that comes with the Navigation Controller. When you added a title for the main view, the Navigation Controller kept track of that name as part of the view stack for navigation, and added a back button with the title in it. So yeah, you did do that!

Debugging—the dark side of iOS development

Something has gone wrong, but honestly, this is a pretty normal part of the development process. There are lots of things that could cause our application to crash, so we need to figure out what the problem is.

Warnings can help find problems first

In general, if your application doesn’t build, Xcode won’t launch it—but that’s not true for warnings. Xcode will happily compile and run an application with warnings and your only indication will be a little yellow yield signs in the gutter of the Xcode editor. Two minutes spent investigating a warning can save hours of debugging time later.

Geek Bits

Some common warning culprits:

Now that iOS 4.3 is out, code that uses deprecated 2.0 or 3.0 properties triggers warnings.
Sending a message to an object that it doesn’t claim to understand (from a typo or an autocompletion error) will trigger warnings. Your app will compile, but will likely end up in a runtime exception when that code is executed.

That’s not our problem, though: at this point our code is (at least it should be) warning and compile-error-free. The good news is that when an app crashes in the Simulator, it doesn’t go away completely (like it would on a real device). Xcode stops the app right before the OS would normally shut it down. Let’s use that to see what’s going on.

Time for some debugging...

First stop on your debugging adventure: the console

We need to figure out why our app crashed, and thankfully, Xcode has a lot of strong debugging capabilities. For now we’re just going to look at the information it gave us about the crash, but later in the book, we’ll talk about some of the more advanced debugging features.

Since you ran the program in the simulator, Xcode is going to bring up the debugging pane at the bottom of the editor. You’ll probably want to resize it to make the log easier to review.

Interact with your application while it’s running

Xcode 4 is a very powerful debugging tool. Some of the best debugging techniques involve well-placed logging messages using NSLog(...). This information is printed into the console and can help you diagnose problems quickly. The console isn’t just read-only, though; it is your window into your running application. We’ll see log messages displayed in the console, and when your application hits a breakpoint, you’ll be placed at the console prompt. From there you can use debugging commands like print, continue, where, up, and down to inspect the state of your application.

Note

The console debugger is actually the gdb (GNU debugger) prompt, so nearly all gdb commands work here.

And when it’s about to stop running

In this case, we’re dealing with a nearly dead application, but the idea is the same. Since DrinkMixer has crashed, Xcode provides you with the basic information of what went wrong. In our case, an “unrecognized selector” was sent to an object. Remember that a selector is basically a method call—it means that some code is trying to invoke methods on an object and those methods don’t exist.

But Xcode doesn’t stop at the command line. It has a full GUI debugger built right in. Let’s take a look...

Xcode supports you after your app breaks, too

So far we’ve used Xcode to write code and compile and launch our applications. Its usefulness doesn’t stop once we hit the “Build and Debug” button. First, we can set breakpoints in our code to let us keep an eye on what’s going on. Simply click in the gutter next to the line where you want to set a breakpoint. Xcode will put a small blue arrow next to the line and when your application gets to that line of code, it will stop and let you poke around using the console.

Slide the scrubber all the way to the right to see the full stack from the app...

The Xcode debugger shows you the state of your application

The debugger shows your code and also adds a stack view and a window to inspect variables and memory. When you click on a stack frame, Xcode will show you the line of code associated with that frame and set up the corresponding local variables. There isn’t anything in the debugger window you couldn’t do with the console, but this provides a nice GUI on top of it.

What the heck is going on?

Our application is crashing, and it’s not at the array loading code, so get back into Xcode. It will show you the line that’s causing the problem, can you see what’s wrong?

To be continued...

MultipleViews cross

Take what you’ve learned about the Navigation Controller and multiple views to fill in the blanks.

Across		Down
3.	The set of views that the nav controller deals with.	1.	A more versatile way to manage data beyond an array.
6.	Dictionaries use __________ to organize data.	2.	DrinkMixer is this type of app.
8.	The screen that gives you output from the app.	4.	To use a new class you need to ___________ it.
9.	A template that combines a table view and nav controls.	5.	The @ symbol is shorthand for creating one of these.
10.	Has cells that need to be customized to work.	7.	A tool in Xcode to help fix broken code.

Your iOS Toolbox

You’ve got Chapter 4 under your belt and now you’ve added multiple views and the Navigation Controller to your toolbox.

MultipleViews cross Solution

Take what you’ve learned about the navigation controller and multiple views to fill in the blanks.

Across		Down
3.	The set of views that the nav controller deals with. [VIEWSTACK]	1.	A more versatile way to manage data beyond an array. [DICTIONARY]
6.	Dictionaries use __________ to organize data. [KEYS]	2.	DrinkMixer is this type of app. [PRODUCTIVITY]
8.	The screen that gives you output from the app. [CONSOLE]	4.	To use a new class you need to ___________ it. [INSTANTIATE]
9.	A template that combines a table view and nav controls. [NAVIGATION]	5.	The @ symbol is shorthand for creating one of these. [NSSRING]
10.	Has cells that need to be customized to work. [TABLEVIEW]	7.	A tool in Xcode to help fix broken code. [DEBUGGER]

Get Head First iPhone and iPad Development, 2nd Edition now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Chapter 4. Multiple Views: A table with a view

Brain Barbell

So, how do these views fit together?

Brain Barbell

The navigation template pulls multiple views together

Do this!

The table view is built in

Watch it!

A table is a collection of cells

Note

Brain Power

Each drink gets its own temporary cell

Just a few more drinks...

Brain Power

Plists are an easy way to save and load data

Built-in types can save and load from plists automatically

Note

Arrays (and more) have built-in support for plists

Brain Barbell

Use a detail view to drill down into data

A closer look at the detail view

Use the Navigation Controller to switch between views

Navigation Controllers maintain a stack of View Controllers

Brain Power

Instantiate a View Controller like any other class

Dictionaries store information as key-value pairs

Debugging—the dark side of iOS development

Warnings can help find problems first

Geek Bits

First stop on your debugging adventure: the console

Interact with your application while it’s running

Note

And when it’s about to stop running

Xcode supports you after your app breaks, too

The Xcode debugger shows you the state of your application

What the heck is going on?

Your iOS Toolbox

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly