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...
You’ve just landed the development gig for Spin City, a hit new underground record store. The owner, Rob, is listening to his customers and has a request...
The app needs to keep track of the data for the store inventory and then display it in a way that customers can search. This way, all of Rob’s vintage records are easier to find and he can start converting all that foot traffic into sales.
Your job is to create an iPhone app that displays the record location, price, and description. The app needs to list all of the records.
There’s a lot of information that we need to get across to users. Location and price aren’t so bad, but any kind of detailed listing or description and that row is going to get crowded.
iOS applications were one of the first interfaces to work through touch. That, coupled with a small screen being used for a single task, leads to multiview apps being the norm. Spin City is going to need to respond to user touch by presenting more information.
Multiview iOS applications typically have some kind of overview display (called the master view), and one or more views that drill in on specific pieces of information (called detail views). Our table view acts as our master view; we need a detail view to show all of the information we want to convey.
Data frequently falls into the category of being organized into parent-child relationships, where there is a high-level piece of data with further details to follow. It happens with contacts and calendars, for example. In our case, the record data fits nicely into this model.
The table view/detail view combination is perfect for this type of data. The table view shows all of the top-level items (in this case, records) and then each detail view shows the information for each individual record.
When you build applications, give a lot of thought to how each view should be used: What’s it trying to convey to the user? How will they interact with it? Different views frequently support different use cases, so you might want to place buttons or eliminate access to some functions entirely depending on which view the user is in and what they’re trying to do.
Apple has a lot to say about iPhone apps in the HIG.
The iOS Human Interface Guidelines (HIG) is a document maintained by Apple that gives both best practices and App Store guidelines for app interaction patterns.
When you start going through the introduction, check out the note about using navigation for hierarchical data (using a detail view). Since it’s such a common pattern, one of the app templates in Xcode is the master-detail template.
Note
The HIG can be found online at https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ or through the Organizer window in Xcode, search for “iOS Human Interface Guidelines.”
UI Design Magnets Solution
Here’s what we came up with for the detail view just to give you an idea. We’ll get into implementing it later!
Relax
This is the detail view that we came up with, but it’s OK if yours was different.
We’re following the built-in Contacts app style, but application style is part of what makes each application unique. Be careful about trading style for functionality, but make sure you give your app personality. We’ll get into more details later about how to implement all of this.
You have the two views, but there’s nothing linking them. We need to set up when each should be used, how we transition between them, and what kind of information each one needs in order to do its thing.
How does the table view know what to show in the detail view? How does the user get back?
Sharpen your pencil Solution
What do we need to wire up to make things work?
A tab bar for the bottom of the main view. A tab bar is used when you have views of equal importance that don’t necessarily relate to each other. Useful, but not here! | Navigation buttons View transitions and back buttons come as part of the navigation controller | ||
A utility application. A utility application is a term used to describe a straightforward app that’s usually one or two views only. Think the weather app that comes on iOS or a stock app. | Table cell touch handling Table cells can be tapped by the user and shoot off an event to let us know what happened. We can take advantage of that to hook our views together. |
The navigation controller can handle transitions between views. There are several view transitions built in, we just need to wire things up. It provides things like back buttons, title bars, and view history so that the user can move between data without getting lost. The navigation controller handles things like sizing the views and maintaining a view stack; we just need to tell it which views we’re working with.
Now that we have a good understanding of what the app is going to do (show records and some details about them) and how it’s going to do that (using a navigation controller and a table view), we can get started. Go ahead and open up Xcode.
Choose the template.
Start a new project and choose the “Master-Detail Application.” That one comes with the basic views and the navigation controller. Change the product name to “SpinCity” and do not add a class prefix. Leave the “Use Core Data” box unchecked.
Click “Next” and save your project.
Save your new project somewhere you can find it later and Xcode will create a new iOS application with a table view master view and a blank detail view.
Open up the storyboard.
The template includes a storyboard that has all the project’s views on it, including transitions. Click on the storyboard and Xcode will open it up in the storyboard view. Let’s dig into what we get out of the box...
Storyboards Up Close
The storyboard is a view within Xcode that was introduced with Xcode 4.2 and allows you to work graphically with all the views and transitions used in your app. Now that we’re moving into an app with multiple views, it’s important to see how those views are related.
Scenes represent a view controller’s worth of content. On iPhone it’s on one screen, but on iPad there can be more than one view controller (and its view) present on the screen at one time. You can also see segues above. They represent the different types of transitions between views. Some different segues include modal or push transitions and can be customized. The segue itself is an object that is created to prep the new view and is also used to pass data between views.
Test Drive
Using the instructions on the previous page, dive into Xcode and get Spin City set up. This will give you a generic template app to work with.
Set the title of the master view.
In the storyboard view, click on the navigation item in the master view controller. In the property editor on the right, change the title to “Spin City Albums.”
Build and Run!
You don’t need to do anything else to get the app to run—the template comes ready to go. Click the Play button to build and run, and you’re off!
Now that you have the basic views and transitions between them, we need to start working with real data.
Joe: The TableView view controller knows about the table view, so we can stick the data there.
Jim: We need more than just the title of the album though, we need everything that goes on that detail view too.
Joe: We need to store that somewhere....
Frank: ...but data doesn’t belong in the view controllers.
Jim: Why not? The view controller knows everything that’s going on, shouldn’t it have the data too?
Frank: What happens when we need to add new albums or edit albums in a different view? Should all of our views know about the master view controller?
Joe: No, I see your point. Hey, is this a place to use MVC?
Jim: What’s MVC?
Frank: MVC is the model-view-controller pattern. It’s used in web apps all the time with things like Ruby on Rails. It means we keep the visual presentation (the view) separate from the business logic (the controller) separate from the underlying data (the model).
Joe: But so far everything we’ve done has put the logic and the data in the same class.
Frank: Well, I think it’s time that we changed that. We need a separate class for an album and some place for them to live.
Jim: That’s fine, I guess, but what’s going in that class?
Frank: We need to define the fields for the data, build up the data model...
The MVC pattern is a common pattern in a number of frameworks and it’s all over CocoaTouch. The MVC pattern pushes you to separate the various concerns in an application into their own class or classes to help reduce the complexity in each one. iOS development blurs the view and the view controller a little, but generally you describe the view in the storyboard and keep the business logic in the view controller.
The model in MVC is conceptual—there isn’t a single class that is your model in your application. You may have a number of classes that together represent your model. The important thing is that the representation of the data in your application, and how you access that data, is a separate concern from the view and the general flow control. For Spin City, let’s start with a class that represents an album and go from there.
Behind the Scenes
We’ve only worked with the classes that have come with the template so far, so we need to get into some nuts and bolts for adding a new class in Xcode. When you create a new class with Xcode, it will generate the header and implementation files for you using a wizard. This is probably also a good time to mention the folders in the Xcode file tree. They’re really just groups to help you organize things in Xcode; they don’t necessarily have any bearing on where the files actually live on disk. We’re going to stick our new class in the Spin City group.
Get the class generated.
Right-click on the folder for Spin City in Xcode and then select New File....From there you’ll go through a dialog to create the new class. Make sure that Cocoa Touch is selected under iOS and you should see Objective-C class as a file option. Click Next. Name the class Album, select Next; save it in Spin City, in the Spin City group, and make sure that the Spin City Target is still selected. Then click Create.
We have album information that we want to be accessible to users of our Album class. To do that, we’ll declare a set of properties which the Objective-C compiler will turn into accessor methods for us to let people get to the information we want to expose. Update our Album class with a property for title, artist, summary, location in store, and price. We’re also going to tack on a method to initialize a new Album so we can set everything the way we want it whenever we create a new Album.
Do this!
Here’s how we flesh out the new data model. Open up the Album header and implementation file and update them to look like this.
How are we going to load/save the actual data to put in these objects?
So now we have a class that neatly encapsulates the idea of an album, but we still don’t know where we’re getting this data from. We already talked about why we don’t want to just jam it into a view controller, so where are we going to put it and how are we going to get to it?
This is a common problem/question in iOS development. We’re getting into an important pattern here...
Just like the view has a controller, we’ll use a class to hide how we’re actually fetching the data we’re stuffing into instances of our album class. By hiding the actual retrieval, we avoid splattering SQL or web service calls all over our view controllers. We can encapsulate the data access into a Data Access Object or DAO.
Our DAO needs to take requests like “I need album 12” and translate that into a request that works with the data, gets the information back out, and passes it in some meaningful way back to the view controller.
Sharpen your pencil
Now that you have a general idea of what needs to go into a DAO,
let’s try and whip one up for Spin City. Of the options below, check
off the things that you think should be in the
AlbumDataController class.
Sharpen your pencil Solution
Now that you have a general idea of what needs to go into a DAO, let’s try and whip one up for SpinCity. Of the options below, check off the things that you think should be in the AlbumDataController class.
Transitions between views | Seed default data for albums The class will have a default array created with some seed data. | Icon images These go in the plist for the app. | |||
Code to initialize album creation | .Actions to respond to the add (+) button | Code to keep album count and make it available to view controllers To populate the table view, it needs to know how many albums there will be... |
Not this time.
Remember we’re deliberately trying to abstract away (read: hide) the implementation details of how the data is actually stored. We really have two different audiences for our DAO. We have the outside world, who want to fetch and save albums, and we have the implementation of the DAO where we need to know how we’re storing things and whatnot. To do that, we’re going to have two different interfaces: a public interface and a private interface.
That’s it! Check that you don’t have any warnings or errors and you should be all set. The app isn’t quite ready to show you any new tricks (we need to wire it up with the table view), but we have a lot to work with now.
Exactly!
Now we have a home for the data and a way to get at it. Next we need to wire that up to the actual view controller and table view. Just a few more steps and you’ll be able to see all those albums you just created.
Exercise Solution
Let’s get the MasterViewController working with the AlbumDataController class. Let’s see the changes that we needed to make to the template code to get this all working.
Remove some of the template code in MasterViewController.m.
We’re building this out past the template now, and so need to make some modifications. Remove the
NSMuteableArraydeclared in the private @interface, the button creation fromviewDidLoad, theinsertNewObjectmethod, andcommitEditingStyle. Finally, changecanEditRowAtIndexPathto return NO instead of YES.Add the code to work with the
AlbumDataControllerin MasterViewController.m.Add the imports for the
AlbumDataControllerand Album classes at the top of the file, declare a property to hold ourAlbumDataControllerand initialize theAlbumDataControllerproperty inawakeFromNib.
You’re ready to get back in it!
Now the data and the logic to handle the data are in place. Get back in and let’s make those table views work.
Now that we know how to get to the albums, we need to get them visible on the screen. To do that, we’ll use our table view. Right now we only have a handful of albums set up, but if we were to put the whole inventory of the store in there we’d have hundreds or maybe thousands of albums to deal with. Rather than loading all of the albums and trying to jam them into the table at once, table views optimize memory usage by taking advantage of the fact that a user can’t tell if a cell that would be off the screen has any data in it or not.
UITableViews only have to display enough data to fill an iPhone screen or the view in an iPad—it doesn’t really matter how much data you might have in total. The UITableView does this super efficiently by reusing cells that scrolled off the screen.
Table Cell Code Up Close
The table view methods are all inside the
MasterViewController (which makes sense, since the
master view is responsible for the table view). The template code
comes with the required methods for the table views plus some optional
code to rearrange cells, but that’s commented out. This is a read-only
application, so we won’t need that code anyway.
Test Drive
After tying the table view to the data, you should be able to fire up the app and see the albums you put in the DAO in the table view. Feel free to add more albums in the DAO too if you want!
Sure!
After talking it over with Rob, we figured out he needs a summary included in the table view cell, too. Like this:
Sharpen your pencil
Layout the new cell using the information that Rob wants shown in each table view cell on the main view of the app.
Sharpen your pencil Solution
Here’s how we laid out the cell to get some more information in there. This is a spot where pulling in a designer can help a lot. You want to balance showing enough information to be useful but not so much that the table becomes unusable.
So far we’ve used the default table view cell layout in our app.
It works fine, but we want more. Tableview cells actually come with a
couple different layout styles using properties like
detailTextLabel and imageView.
If those work for your application, then by all means you should use
those. We’re going to show how to build a custom cell, though, since
it’s not much more difficult and gives you the flexibility to do
whatever you want with cells.
Since we’re not going to be using a default table cell, we need
to create a new class that inherits from the basic
UITableViewCell and adds the custom properties we
want to show.
Custom Table Cell Construction
To get into making the new table cells, we need to create a
new class which subclasses the basic UITableViewCell.
Create a new class that is an Objective-C class titled
AlbumTableViewCellthat is a subclass ofUITableViewCelland make sure it’s in the Spin City group and that the Spin City target is checked.Next you need to modify the storyboard to use your custom table view cell instead of the basic one. Go back into Main.storyboard and click on the default empty table view cell in the table view scene.
Now to layout the actual cell we need to work inside of the storyboard and drag elements into the cell just like we do for elements of a view.
Drag a label over to be the albumTitle. Align it to the top half of the cell, left guideline. Drag the width out to about half the cell. Change the default text to be albumTitle.
Grab a second label to be the albumSummary. Put it in the bottom half of the cell, left guideline drag it out to 3/4 of the cell. In the Attributes inspector, change the font size to 12, color to Light Gray Color. Change the default text to be albumSummary.
For the price label, put it in the middle vertically, aligned with the right guideline. Change the font to custom, Marker Felt Thin, 14pt. Make the text right aligned. Stretch the label left to bump up against the right edge of the summary label. Change the default text to be price.
Test Drive
Now that the cells are all laid out, all that’s left is to wire the labels up with their outlets and actions. Do that and you’re ready to see the new cells!
Open up the assistant editor and show the AlbumTableViewCell.h.
You should have the storyboard next to the assistant editor. Control-drag from the
albumTitlelabel to in between@interfaceand@endin theAlbumTableViewCell.h. Make sure the pop up is for an Outlet. Set the name to bealbumTitleLabel, typeUILabel, and weak storage.Repeat the process for the
albumSummaryLabelandpriceLabel.When you’re finished, there should be three filled in circles in the gutter next to the AlbumTableViewCell.h file.
Go into MasterViewController.m.
Add an import for the new AlbumTableViewCell.h file and then update c
ellforRowAtIndexPathto use the new custom cell type.Run it....
We know...
Now that the app is working and all is well, it’s time to dive into the details in the next chapter...
Table View Cross
Exercise the right half of your brain and make sure
you know your terms.
Across | Down |
|---|---|
1. _______ cells allow you to do your own layout. 2. You use a ______ method for use in just one class. 3. Use _______-drag to create code graphically. 5. ___________ files are used to lay out and transition between views. 7. Table views with details are great for _________ data. 8. The DAO is the data ___________ object. 9. MVC stands for ______-view-controller. | 1. A table is a collection of ______. 4. The ________ bar holds the buttons for navigating through views. 6. Data works best when it’s in its own _______. 7. Apple uses the _____ to dictate interaction patterns. |
You’ve got Chapter 4 under your belt and now you’ve added table views to your toolbox.
Table View Cross Solution
Exercise the right half of your brain and make sure you
know your terms.
Across | Down |
|---|---|
1. _______ cells allow you to do your own layout. [CUSTOM] 2. You use a ______ method for use in just one class. [PRIVATE] 3. Use _______-drag to create code graphically. [CONTROL] 5. ___________ files are used to lay out and transition between views. [STORYBOARD] 7. Table views with details are great for _________ data. [HEIRARCHICAL] 8. The DAO is the data ___________ object. [ACCESS] 9. MVC stands for ______-view-controller. [MODEL] | 1. A table is a collection of ______. [CELLS] 4. The ________ bar holds the buttons for navigating through views. [NAVIGATION] 6. Data works best when it’s in its own _______. [CLASS] 7. Apple uses the _____ to dictate interaction patterns. [HIG] |
Get Head First iPhone and iPad Development, 3rd 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.
