Objective-C Programming: The Big Nerd Ranch Guide (2nd Edition) 阅读笔记(Part IV)

• Your first iOS application
    ○ GUI-based application
        § A GUI-based application is event-driven. When the application is launched, it starts a run loop that sits and waits for events. Event can be generated by the user or by the system. When an event happens, the application leaps into action to respond to the specific event. All iOS applications are event-driven applications.
        § AppDelegate
            □ The "app delegate" is the starting point of an application, and every iOS application has one.
            □ UIKit.h was imported by the template. Uikit is the framework that contains most of the iOS-specific classed, like UITableView, UITextField, and UIButton.
            □ AppDelegate is a subclass of UIResponder and conforms to the UIApplicationDelegate protocol.
            □ AppDelegate has one property that points to an instance of UIWindow. This object fills the screen of your iOS application. You add other objects to the windows to create your application's user interface.
        § MVC
            □ MVC is a design pattern that is based on the idea that any class that you create should fall into one of three job categories: model, view, or controller.
            □ Models are responsible for storing data and making it available to other objects. Models have no knowledge of the user interface or how to draw themselves on the screen; their sole purpose is holding and managing data. (Such as NSString, NSData, and NSArray)
            □ Views are the visual elements of an application. View know how to draw themselves on the screen and how to response to user input. Views have no knowledge of the actual data that they display or how it structured and stored. (UIView and its various subclasses, including UIWindow, are common examples of view objects.)
            If you can see it, it is a view.
            □ Controllers perform the logic necessary to connect and drive the different parts of your application. They process events and coordinate the other objects in your application. Controllers are the real workhorses of any application.
            □ Most of the Cocoa and Cocoa Touch APIS are written with MVC in mind, and your own code should be, too.
        § The application delegate
            □ When an iOS application first launches, a lot of setup is happening behind the scenes. An instance of UIApplication is created to control the application's state and act as liaison to the operating system. An instance of AppDelegate is also created and set as the delegate of the UIApplication instance.
            □ This makes AppDelegate a busy class. It would be good to have a way to organize the class so that it would be easy to find methods quickly. You can use #pragma mark to group methods within a class for easier navigation.
        § Setting up views
        § Running on the iOS simulator
        § Wiring up the button
            □ A button works using target-action. The button's action is the message that you want sent when the button is tapped. The button's target is the object to which that message should be sent.
            □ Some view objects are also controls. A control is a view that the user can interact with. Buttons, sliders, and text fields are examples of controls. (Keep in mind that the term "control" has nothing to do with "controllers" in MVC)
            When there are controls on the screen, one of them can be the first responder. When a control has first responder status, it gets the first chance to handle text input from the keyboard and shake events.
            When the user interacts with a control that can accept first responder status, that control is sent the becomeFirstResponder message. When a control that accepts text input becomes the first responder, the keyboard appears on the screen.
        § Wiring up the table view
            □ As a view object, the table view does not contain anything about actual data. It needs an object to act as its data source.
            □ To do the job of table view's data source, it must conform to the UITableViewDataSource protocol. 
            UITableViewDataSource protocol has two required methods. A table view's data source must be prepared to tell the table view:
                ® How many rows are in a given section of the table (tableView:numberOfRowsInSection:)
                ® What the cell in a given row should be (tableView:cellForRowAtIndexPath:)
        § Saving and loading data
            □ Adding a C helper function
            □ Saving task data
    ○ For the more curious: what about main()?
        § The entry point into your program's code is the main() function when learning C and Objective-C. It is absolutely true in Cocoa and Cocoa touch development as well, although it is extremely rare to edit this function in Cocoa and Cocoa Touch applications.

        § The UIApplicationMain function creates the necessary objects for your application to run. First, it creates a single instance of the UIApplication class. Then it creates an instance of whatever class is denoted by the fourth and final argument and sets it to be the application delegate, so that it can send its delegate messages when memory get low, when the application is quit or backgrounded, or when it finishes launching.
• Your First Cocoa Application
    ○ First, note that you have not declared a property for the NSButton. All the work to create and wire up this view object will be done in Interface Builder. You do not need a property for it because you will not be interacting with the button programmatically.
    Second, you used two new keywords: IBOutlet and IBAction. IBOutlets tells Xcode that the taskTable pointer will be assigned in Interface Builder and not in the class's code files. IBAction tells Xcode that addTask: is an action method and that the associated target-action pair will be configured in Interface Builder and not in the class's code files.
    ○ Setting up views in Interface Builder