Head First iPhone and iPad Development (2013)
Chapter 4. Tables, Views, and Data: 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...
Congratulations!
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...
SpinCity browsing app overview
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.
The way iOS apps work
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.
Using the touch screen....
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.
UI DESIGN MAGNETS
We’ve already shown you a little about what the first view will look like. What are you thinking for the detail view?
If you feel like you’re getting stuck, turn the page for a little help!
Hierarchical data—get out your table view
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.
Use table and detail views together to represent hierarchical data
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.”
THERE ARE NO DUMB QUESTIONS
Q: |
Q: Do I have to follow the HIG? |
A: |
A: Yes and no. It’s a good idea to make sure that your app behaves the iOS way; it will keep the user experience consistent for the user and will make it easy for the Apple reviewers when you submit the app. Of course, you want to keep some originality for your app. For basic things, like drilling down into data, it’s best to keep things uniform with user expectations. For things that are more unique to your app, that’s a good place to differentiate yourself. |
Q: |
Q: Why switch views instead of changing the view to present more information? |
A: |
A: This is one of those times when the small screen and basic interaction patterns used in iOS become important. With limited screen space, iOS apps are very task centric. One of the most challenging parts of building a good application is effectively presenting the information you need to communicate without overloading the user or making overly complicated interactions. Each view should have a specific purpose and be designed to get the user the information they need in a way that makes it easy (and fun!) to understand and use. |
Q: |
Q: What other ways does touch influence the interface? |
A: |
A: Designing for a touch interface means that some things need to be completely different from web development; the biggest one being that the space for interaction needs to be the size of a fingertip, not a mouse pointer. Other things like hover don’t really work as a design paradigm either. |
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.
We need to hook these views together...
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
What do we need to wire up to make things work?
|
A tab bar for the bottom of the main view |
|
Navigation buttons |
|
A utility application. |
|
Table cell touch handling |
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 gets you around in your views
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.
THERE ARE NO DUMB QUESTIONS
Q: |
Q: What built-in apps on iOS use the navigation controller? |
A: |
A: For examples on how the navigation controller works, check out the Mail app on both iPhone and iPad. The iPad uses the split view controller, which is similar to the iPhone but it allows for the presentation of the master view and the detail view at the same time. That allows iPads to leverage the additional screen space without really changing the navigation pattern of the app between devices. Another good example is the Calendar app on the iPhone. Although it supports several different views (the month, day, list or week view), it still is fundamentally driven by the navigation controller. |
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 on screen, 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. |
Q: |
Q: What if I want buttons, like the Edit button in the iPhone Mail app, up in the top? Is that a problem with navigation controllers? |
A: |
A: Nope, not at all. The navigation controller has the idea of button in that top navigation bar; you just tell it what to put up there. It also supports the back navigation button to the previous view. |
Q: |
Q: You mentioned that on the iPad you can see the master and detail view side by side. Does that make things complicated? |
A: |
A: Not really. On the iPad, you’ll use a split view control which takes a master view and a detail view. These could be the same master and detail views you use on your iPhone application. They’re wired together with the SplitViewController on the iPad instead of a navigation controller like on the iPhone or a Touch. Sometimes on the iPad you actually see the master view wrapped in its own navigation controller. Check out the Mail app on the iPad to see that in action. The master view (when in landscape mode) can show accounts, then drill down to folders, then down to actual messages. Those are all different views inside a navigation controller. When you actually tap an email, the detail view (bigger view on the right) shows the details of the selected message. |
Three views in one template
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.
1. 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.
2. 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.
3. 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
1. Create the app.
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.
2. 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.”
3. 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...
Use MVC to separate your concerns...
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.
Adding a new class
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.
1. 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, selectNext; save it in Spin City, in the Spin City group, and make sure that the Spin City Target is still selected. Then click Create.
BRAIN BARBELL
Now we have a class to represent an album. Take a minute here to list the properties we need to capture the various pieces of information we want. Think about what type each property should be, too. There’s also one method that we need in the Album Class. Take a guess for extra credit!
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
________________________________________________________________________
NOTE
Class properties
NOTE
Method for the Album class
Properties expose class attributes
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.
THERE ARE NO DUMB QUESTIONS
Q: |
Q: Where are we going to get this data? |
A: |
A: We’re going to add it as an array to start, but other options include plists, SQL databases, and more. Just about every app out there has some kind of data store and we’re going to be talking about several different kinds as we work through the book. Some data sources are purely web-based and just do local caching. Anybody using DropBox APIs or iCloud is working with a web service to move data in and out of the app. Those types of services are often used as a mechanism to keep data synced across devices. |
Q: |
Q: What happens if we return nil from an initializer? |
A: |
A: If this happens, it’s indicating to the caller that initialization failed. The caller should then handle this properly and recover. In practice, that’s a pretty bad situation to be in and doesn’t happen very often. You need to follow convention properly here though, as CocoaTouch frameworks assume (and provide) this pattern. |
Q: |
Q: How do we display this data to the user? |
A: |
A: First we need to actually get some data together to use and figure out how to create all those little Album objects we need. Let’s work on that next... |
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...
Data Access Objects hide low-level data access
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 aData 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.
|
Transitions between views |
|
Seed default data for albums |
|
Icon images |
|
Code to initialize album creation |
|
Actions to respond to the add (+) button |
|
Code to keep album count and make it available to view controllers |
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.
DO THIS!
Create a new class the way we did before, called AlbumDataController. Then update the header and implementation to look like this.
DO THIS TOO!
You’ve built your DAO!
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.
THERE ARE NO DUMB QUESTIONS
Q: |
Q: Why did we just do all that? Couldn’t we just add an array to the view controller? |
A: |
A: You could have, but the view controller already has stuff to do. In iOS, view controllers tend to become dumping grounds for code that really belongs somewhere else. We’ve set this up with a standard pattern that’s going to make it easier to update later if we want to add a database or core data to the app. Using the DAO storage pattern is much more maintainable and it will match up with Apple’s sample code that’s out there for download if you look at other sample apps. |
Q: |
Q: I’m still a little fuzzy on the public/ private interface thing. Why did we put an @interface in our implementation file? |
A: |
A: Objective-C uses the @interface keyword to define a place to declare properties and methods for a class. You typically think of @interface being used in header files to declare a public interface for a class. Other classes include the header file and know what that class has to offer. There are lots of times, however, where you want to set up internal properties or methods that are implementation specific and you don’t want other people to call. You still want to use the nice property notation, etc., you just don’t want people all up in your class’s business. To do that, we can declare a private interface by putting an @interface section in your implementation file. Since the only code that sees that file is the actual class implementation, that’s the only code that knows that interface even exists. |
Q: |
Q: So no other code could call my private methods? |
A: |
A: Well, sorta. Since private methods aren’t declared in the header file, no other code should know they’re there. Objective-C allows for runtime invocation of methods through message passing and won’t prevent other code from inspecting your class at runtime and sending it a message it thinks your class might respond to. Their compiler will yell at them (with a warning) and puppies will shiver, but they technically could still do it. |
Q: |
Q: OH! So is that what Apple talks about with “don’t use private APIs”? |
A: |
A: YES! Exactly. Pull some private method invocation madness on a CocoaTouch class and you’ll be rejected from the App Store post haste! |
On to wiring this up to the view!
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
Let’s get the MasterViewController working with the AlbumDataController class. The template code obviously isn’t set up to use it, so some edits are needed...
1. 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 NSMuteableArray declared in the private @interface, the button creation from viewDidLoad, the insertNewObject method, and commitEditingStyle. Finally, change canEditRowAtIndexPath to return NO instead of YES.
2. Add the code to work with the AlbumDataController in MasterViewController.m.
Add the imports for the AlbumDataController and Album classes at the top of the file, declare a property to hold our AlbumDataController, and initialize the AlbumDataController property in awakeFromNib.
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.
1. 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 NSMuteableArray declared in the private @interface, the button creation from viewDidLoad, the insertNewObject method, and commitEditingStyle. Finally, change canEditRowAtIndexPath to return NO instead of YES.
2. Add the code to work with the AlbumDataController in MasterViewController.m.
Add the imports for the AlbumDataController and Album classes at the top of the file, declare a property to hold our AlbumDataController and initialize the AlbumDataController property in awakeFromNib.
EXERCISE SOLUTION
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.
A table is a collection of cells
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!
THERE ARE NO DUMB QUESTIONS
Q: |
Q: What were all those methods we removed from the MasterViewController for? |
A: |
A: The MasterViewController inherits from UITableViewController, which is a built-in class that works with table views. The tableview is set up to use our view controller as its datasource and delegate, meaning the table view will call methods on the view controller whenever things happen. Out of the box, the template view controller has support for putting a + button in the app to add new items and for letting the user delete and rearrange items in the list. Our app doesn’t support that, so we removed those template methods. You can check out what delegate methods are available by looking at the UITableViewDelegate protocol in the iOS documentation. |
Q: |
Q: What the heck is going on with that segue thing? |
A: |
A: Remember in the storyboard where we have the two scenes connected together with a push segue transition? The template code is set up so that when someone taps on a row, the app fires off that segue. The segue handles getting the next view ready, then calls back into the view controller to let it know things are about to transition (that’s the prepareforSegue call we filled in). In prepareForSegue, we can do just that, get ready for the next view to show up. Sometimes you want to close network connections or whatever you need to do to clean up for the view that’s about to disappear. Other times, like in our case, we need to tell the new view that’s about to appear what’s going on. We simply grab the new view from the segue and tell it which album the user tapped on. The new view exposes that setDetailItem method (via a property). If you had other things on a view that’s about to come in, you can use those here too. Notice that we check which segue is doing the transition in this method because it’s possible that there might be multiple segues coming out of a view, all leading to different places. |
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.
Storyboards can layout custom table view cells too
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.
1. Create a new class that is an Objective-C class titled AlbumTableViewCell that is a subclass of UITableViewCell and make sure it’s in the Spin City group and that the Spin City target is checked.
2. 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.
3. 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.
4. 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.
5. 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!
1. Open up the assistant editor and show the AlbumTableViewCell.h.
You should have the storyboard next to the assistant editor. Control-drag from the albumTitle label to in between @interface and @end in the AlbumTableViewCell.h. Make sure the pop up is for an Outlet. Set the name to be albumTitleLabel, type UILabel, and weak storage.
2. Repeat the process for the albumSummaryLabel and priceLabel .
When you’re finished, there should be three filled in circles in the gutter next to the AlbumTableViewCell.h file.
3. Go into MasterViewController.m.
Add an import for the new AlbumTableViewCell.h file and then update cellforRowAtIndexPath to use the new custom cell type.
4. Run it....
TEST DRIVE
It works!
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. |
Your View toolbox
You’ve got Chapter 4 under your belt and now you’ve added table views to your toolbox.
BULLET PONINTS
§ iOS applications work using touch—and they were the first to do so.
§ MVC is the primary design pattern for iOS applications.
§ Data Access Objects are used to hide low-level data access.
§ Tableview cells are allocated based on which rows are visible and reused whenever possible.
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] |