2011 Stanford University iOS Application Development Tutorials Study notes (lesson one) mvc.and.introduction.to.objective-c

2011 Winter Stanford University Open course iOS App development Tutorial is a very classic tutorial, the old man is very good at speaking. Take notes to summarize.

First lesson name: MVC and Introduction to objective-c the main contents of this lesson are:

Overview of iOS-what is iOS

MVC-Object-oriented concepts

objective-c-Introduction to the concept of language

iOS includes four layers of cores

The kernel is the Mach 4.x BSD Unix kernel Mac OS 10 operating system, is a multi-tasking UNIX kernel, which provides network, socket, security, file system, most of these APIs are C API because this write is UNIX code. We're not going to write code on this floor.

Core sevices Layer

This layer starts with object-oriented and provides a lot of underlying services. Provides runtime, multithreading and so on. There are collection classes, arrays, dictionaries. This layer can be used as a package that provides an object-oriented core OS.

Multimedia layer

Seems to be farther away from the hardware, in fact, is still very close, the IPhone iPod ipad is a multimedia device, multimedia-related code implementation of the entire iOS, in the eyes of developers, core services are multimedia API.

Cocoa Touch Layer

Our 90% time is used in this layer, buttons, scroll bars, various controls and so on.

Describes the composition of the platform:

Tools: XCode 4

Language: Objective-c

Framework Foundation UIKit

Design Patterns

Focus on the three major camps of MVC: Model View Controller

Model

Describe what your program is. For example, a spaceship's program, such as the location of the ship, model, how many machine guns, armor how much.

Controller

Describe how the model unfolds in front of the user, it acquires the spacecraft's position in space, and then calculates how it is displayed on the screen. For example, how many machine guns on the ship are displayed on the screen. In summary, the controller controls how the model is displayed on the UI.

View

It's the controller's little brother, view is the tool. As far as possible is the view universal, the button, the scroll bar and so on, must not contain any how to express the logic. The controller uses these generic view to do what the model wants to do.

With these three camps, the rest is to manage and communicate with each other.

Controller->model completely allowed. Because the controller asks the model how to show the content on the screen.

Controller->view completely allowed. The communication attribute outlet, created in the controller outlets transferred to the view.

Model---View will never communicate. Because model and interface are not related. The view is to be reused, model and view associated, and when the model changes, the view is rewritten.

The View->controller communicates through the target action structure. The controller draws a target, and then gives the action (action) to the view. When a view takes on something, such as a button being pressed, it sends the action to target, and the controller knows. The view and controller also have other communication mechanisms, such as view to tell the controller what's going on, what's going to happen, or asking if it's allowed, using will do should. The controller sets himself up as a delegate and uses the protocol to complete the delegation. Back and forth should be will,did,should. At this point, the view still does not know which controller is responding to which class.

Remember: Views do not have the data they display.

How does the view get the data?

The delegation method, such as data at, count, is obtained through the protocol.

The delegation of the data source is always the controller, not the model.

The work flow of the three camps is this: the controller goes to the model to fetch the data and tells the view to show the data on the screen. Even if there is only one line of code, you have to have a controller to participate, not bad rules.

Model can not actively seduce controller, the model data has changed, then how to let controller know? Notification or KVO mechanism. When the model data changes, it broadcasts, and the controller receives it.

MVC pattern relationships, remember this picture, and the following classes often mention relationships:

MVC Group:

When a lot of model, controller, view, the composition of the MVC group, or to follow the above rules.

The basic concept of objective-c language.

Objective-c is a superset of C, the use of import, @property replace the original class instance variable, of course, the instance variable can also be used, @property help you automatically generate getter and setter, @property can use the dot number Self.topspeed access variable, equivalent to [self topSpeed]

[CPP]View Plaincopy

1. @interface Spaceship ()
2. ??? //Declaration of private methods (as needed)
3. @end

Declare the private method in this way.

Personally feel that the grammar here is not conducive to the understanding of the Chinese people, more cumbersome. Here are some of the objective-c classes that you can refer to later:

OBJECTIVE-C syntax and objects

may be easier to understand. Video View address: Http://i.youku.com/u/UOTYxNjIxNTY=/videos Apple official video address: https://itunes.apple.com/itunes-u/ ipad-iphone-application-development/id473757255?mt=10 Stanford official all tutorials corresponding to the source, job, ppt:http://www.stanford.edu/class/ ppt download in cs193p/cgi-bin/drupal/downloads-2011-fall Video: http://download.csdn.net/detail/totogo2010/4798766

Jongfangzhi (http://blog.csdn.net/totogo2010)

This article follows "Attribution-non-commercial use-consistent" authoring public agreement

2011 Stanford University iOS Application Development Tutorials Study notes (lesson one) mvc.and.introduction.to.objective-c