In the previous lesson we opened up with an overview of the tools you’llbe using the build your iOS apps, as well as a demonstration of the wizard and a quick rundown of the Xcode editor. In this lesson, we’ll be popping the hood on our “Tutorial1″ app and see what makes it tick.
The Project Navigator
As mentioned before, the left view panel of the editor is the Navigator. The first tab in that panel is known as the Project Navigator. This functions pretty much the same way as the Package Explorer in Flash Builder, with one caveat (which I will get into later). At the top is the Tutorial1.xcodeproj file, which keeps track of the project files, as well as build settings and all that other nifty stuff. (If you were so bold as to check out the folder you pointed the wizard to in the previous lesson, you should see this file sitting there nicely. Unlike Flex, which requires you to manually import your projects, Xcode project files can be moved effortlessly between machines and accessed just by double clicking them.) The project file will serve as the root in the tree list for all your classes, resource files, linked libraries, unit tests, and other stuff I dare not mention yet. Now, I’m sure at this point you’re REALLY anxious in diving into the code, so let’s just move straight on to the actual meat of the application.
Just as the MX library exists as a framework on top of AS3 for Flex applications, Apple has devised a pretty clever architecture that remains highly consistent throughout the UIKit. For reference, the UIKit is to the base Foundation framework as Flex’s MX library is to AS3. UIKit serves as a higher level framework for application user interfaces for iOS. (Note that this is NOT to be confused with AppKit, which is similar, but specialized for desktop Mac applications). When working with UIKit, you have a few major subsets of classes. Here are the big three that we will be focusing on for most of these lessons:
- UIViews - The actual view objects that render on the screen, including text fields, buttons, images, etc. Think of Flex’s UIComponent.
- UIViewControllers - Each view state for your app will need its own controller to represent it. That’s what these are for.
- Delegate protocols - Many different views define their own protocols (expected method declarations similarly to interfaces in AS3) which allow you to plug in and observe feedback responses from within the views.
Pinpointing these types in the project navigator should be easy. First we have the AppDelegate, which plugs into the main application, holds a reference to the app’s window (like the stage in Flash), and handles app-level events, such as initialization, gaining/losing focus, being called from another app, termination, etc. At this point you should notice something distinctly unique in convention â€” where Flex favors extension of the base application, iOS uses delegation. Interesting, huh? One thing I’m a big fan of with UIKit is it heavily favors delegation and composition over inheritance of views. Controllers compose the views, and then provide a bridge between the view and the rest of your application, so you can stop making those silly KissBradPittWinIPod mxml components and start making SlapSumoWrestlerGetFiftyBucks view controllers like the rest of us.
Next we have MasterViewController. This controller extends UITableViewController, which is a convenience subclass of the standard view controller for controllers that use a basic table view. (If you look at your app through the simulator again, it’s the first view that says “Master” at the top.) Tables are like Flex’s list component, and can be found in practically every app you have on your device. It’s extremely popular as a menu tool as well as listing a collection of values. You may be wondering where the MasterView is for the controller. Well, it doesn’t exist. Didn’t I just tell you that UIKit hates needless view inheritance? The controller itself contains all the logic used by the app to populate the view, and the view itself gets plugged into the display list internally. (Note: Although the wizard named this class the “MasterViewController,” most older projects would likely have a “RootViewController” instead. Regardless of the name, though, both serve the same purpose â€” to act as the root level controller of the application.)
Finally, we have the DetailViewController. Same as the with the master, this is simply a controller that represents a view state. Unlike the master, however, it does not inherit from UITableViewController, which makes sense as the detail view in the simulator clearly isn’t a table. Basic rule of thumb: If your base view isn’t a UITableView, then your controller should directly extend UIViewController. In fact, even if you ARE using a UITableView, you might still opt to extend the standard controller, for greater customization over the view’s style or layout.
Dance, Skeleton, Dance
So these are the three main objects that make our app uniquely ours, but how do they relate and interact?
The chart above depicts how everything is connected thus far. The AppDelegate is created by the app’s main, which then instantiates our MasterViewController and shoves it into a UINavigationController. Think of the navigation controller as everything below the status bar (where the connection and battery indicators are) and the master as everything below that blueish bar next to it. The blueish bar that you all should be so familiar with is the UINavigationBar. It belongs to the navigation controller, but any view controller in the navigation chain has access to it, which lets you conveniently set what it displays, or drop in buttons like cancel, submit or edit. The navigation controller is responsible for switching views inside it, which it does whenever the currently active subview triggers its push or pop methods. So when you press “Detail” on the home screen, you’re telling the master to “push”Â an instance of DetailViewController into the nav. When you hit the back button, you tell the nav itself to “pop” back to the previous controller, which would be the master. Of course, there are other view controllers that also specialize in navigation, such as the UITabBarController, which differs from our nav in that it presents a list of controllers along the bottom of the screen that you can toggle between. Navigation type controllers interact directly with your other view controllers. Your view controllers, in turn, expose their corresponding views, which the navigation adds to and removes from the display list internally, so you don’t have to worry about any of that.
Well that’s all the time we have for today. What? Where’s the code? Oh yeah, I forgot about that. How embarrassing. I feel like one of those college professors that ramble on and on about something and then not realize until the bell rings that I didn’t even cover the topic I wanted to. I remember this one time… (Seriously, though, next lesson will be code. Promise!)
April 2014 M T W T F S S « May 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30