MVC in IOS

MVC in IOS

Let's talk about the Model-View-controller (MVC) model in cocoa programming today. We will discuss MVC in two aspects:

1. What is MVC?
2. What is the communication between M, V, and C?

Understanding the concept of MVC is crucial to cocoa program development.

 

I. MVC Concept

MVC is Model-View-controller, that is, Model-View-controller. What are these things?

 

MVC divides the software system into three parts: model, view, and controller. In cocoa, every object in your program will obviously belong to only one of these three parts, but not the other two.

 

Model = What is your program (rather than how your program is displayed)

 

Let's take an example. When we went to middle school, we had a game called "Thunder fighter" in our BBG electronic dictionary, that is, the "airplane hitting" game. The model was: what is the attack power of your small plane? What weapons, shells, missiles, and laser guns are mounted on your plane? How much blood does your plane have? And so on. To sum up, it is the function that your program will implement or what it can do.

 

Controller = how to present your model to users (Program Logic)

 

Controller is the internal logic of the program. In most cases, you will not be able to see it. It binds the model and view together, and it will process user input. For example, if you press the key to open the gun, the Controller will use internal logic to handle your requirements and display them on the screen. You will see a small plane on the screen hitting the enemy. This is also an example of controller control View display. Therefore, you can regard controller as a bridge connecting m and V.

 

 

View = what you see on the screen (it is your controller's "slave ")

 

Then the view of the plane is: What does your plane look like, whether it has two wings, how many gunshots, or where your plane is on the screen. In short, all the components you see on the screen can be classified as views.

MVC can help ensure maximum reusability of the program. Each MVC element operates independently of each other. By separating these elements, you can build a maintenance and update program.

 

2. Communication Mode between m V C

 

Now let's discuss the communication methods between various elements in MVC.

We divide the program into three parts, but we do not want them to be completely independent, because in that case, our program will be meaningless and functional. There must be some relationship between them, so that they can be organically integrated to implement various powerful functions. This kind of contact is the communication method we mentioned. Let's take a look at the figure below, which is from the courseware of the cs193 course of Stanford University.

 

 

In the figure, there are several lines that divide the three parts into yellow lines, dotted lines, and white solid lines. We think of them as road signs. You can see that there are two yellow lines between m and V. What does this mean? It means that you cannot cross this yellow line, and you cannot cross any direction. On the top of the graph, you can see the white dotted line, which means you can freely traverse it, as long as it is safe. What about the white solid line? It means you can pass through, but you must buy a ticket or pay a toll.

 

Well, if you don't think the previous metaphor makes you understand it, let's talk about something real.

 

First, let's look at the Green Arrow between C and M. The direction of the arrow represents the direction of "initiating a dialogue", that is, C is initiating a dialogue, M is the answer. C can ask m various questions, but M only answers C's questions or requirements, and it cannot actively ask C for anything. Remember that the dotted line is unobstructed, So C knows everything about M. If code is used to explain it, that is, c can import M header files or M interfaces (APIS ). Because C can use M's API, it can demand this requirement from m without authorization.

 

Let's take a look at another Green Arrow, which is between C and V. It has the same meaning as the previous Green Arrow. It means C can communicate directly with v. You can think about it. c wants to put V on the screen, set the V attribute, tell them when to disappear from the screen, and divide them into groups. If C cannot send a command to V freely, the display of the program will be very difficult. Therefore, C can speak to V without restrictions.

 

You may have noticed that there is an outlet (output port) on this arrow. outlet can be seen as a pointer from C to V, which is defined in C. Outlet provides us with great convenience, which enables us to easily and accurately execute orders to V within C. C can have more than one outlet, which makes it more efficient to communicate with v.

 

Can M and V communicate with each other? Do you still remember what the yellow line means? It is completely unavailable, so we do not allow m and V to communicate. This is because we don't want to have too much communication between these three parts. You can think about it. If V has a problem during display, for example, if a graph is not displayed, we have to look for an error, because C can communicate with V, and m can communicate with V, we need to check the two parts. On the contrary, if only C can communicate with V, when an error occurs, we only need to go to C to find the cause. Isn't it easy to find the error? Therefore, we do not allow direct connections between m and V, which is also the reason that there are two yellow lines between them.

 

Good applications must be able to interact with users. Without good interaction, the functions of the program will be greatly restricted. In MVC, V is in direct contact with the user, and the user cannot see M and C. Therefore, the interaction between the program and the user must be implemented through V, but V is only a view, it cannot completely handle user requirements. Therefore, it requires that V must have some means to send information to C and hand over the user interaction requirements. This means is the traffic fee represented by the previous white line. You know that V cannot know everything about C, but it can communicate with C through some "means" and hand over the responsibility for user interaction.

 

Next we will discuss how v sends messages to C. V has three different ways to communicate with C.

 

The first type is called target-action ). It works in this way. C will "hover" a target in its internal structure, which is a red and white target. Corresponding, it will also distribute an action (action, to the view object (possibly a button on the screen) that will communicate with it. When the button is updated, the action will be sent to the corresponding target, in this way, V can communicate with C. However, in this case, V only knows whether to send an action to the corresponding target. It does not know the class in C or what it actually sends. Target-action is a common method.

 

The second method is called a delegate ). Sometimes, V needs to be synchronized with C. You know, user interaction is not just about pressing a button, sliding a slider, but also in many forms. Let's take a look at the delegate yellow arrow in the figure. You can find four small arrows on the Arrow: shocould, did, And will. There is another one that is not marked. The vast majority of the delegate information is in the form of shocould, Will, and did. Corresponding to the English meaning, shocould indicates that the view object will ask a certain object in C, "should I do this ?", For example, if someone clicks a link in a Web View, the Web View will ask "should I open this link? Is this safe ?". This is the account information. What about Will and did? Will is "I am going to do this", did is "I have already done this ". C sets itself as the V delegate, which lets v know that if V wants to know more about how it will be displayed, it will send the delegate information to C. C will coordinate and process the delegate information sent by V. Another point is that each V can have only one delegate.

 

The third method is the data source. You know that V cannot have the data it wants to display. Remember this is very important. V wants others to help it manage the data to be displayed. When it needs the data, it will ask others for help and give it the required data. Furthermore, the iPhone screen is small and cannot display views that contain a large amount of information. The datasource arrow in the figure is similar to delegate. V sends cout and data at information to C to request data.

 

Okay, this is three forms of information that V sends to C.

 

The last question. You can see the white line between M and C, which means M cannot communicate with C directly without restrictions. However, sometimes communication in this direction is necessary. When something in M changes, C needs to understand these changes. How can we let C know m changes? Notification and KVO are good solutions to the problem. They work like this. When something in M changes, they will send a notification to C, "Hey, dude, attention, I have changed ", or they will send a pointer pointing to a change to C, or something else. In short, they work like this.

 

The following is a summary. Cocoa is loyal to MVC, so it is our key start to understand cocoa MVC. I hope this will help you understand it.

 

C-to-M: API
C-V: Outlet
V for C: Target-action, Delegate, datasource
M for C: notification, KVO

From: http://wangwenhao.net/2011/10/20/mvc-in-ios/

 

 

Http://hi.baidu.com/janins/blog/item/1828a9f82f90509bb901a0d0.html?

I believe everyone is familiar with MVC (Model-View-Controller. In iOS development, the MVC mechanism is fully used. I think writing a program on iOS and fully understanding the MVC mode of iOS will help us to organize the program rationally. On the contrary, we don't follow the MVC conventions. The program can be written, but it is waiting for suffering.

Below I will only list one table for some conventions and talk about the IOS support mechanism. I will share it with you:

1. The model cannot deal with the Controller or view. That is, the model does not know who will use it. The model cannot have any reference to the Controller or view. The so-called: Don't call me, I will call you. It is designed for the model. Let's think about it. In general programs, the model is used everywhere, and it is really difficult to maintain who uses it. Then you will ask: Bro, when the data of the model changes, how can I notify the view update? The common mechanism here is the broadcast mode, the radio mode, or the event mechanism. There are two supported mechanisms in IOS: Notification and KVO (key-Value
Observing ). KVO is a core concept in IOS. The simple understanding is that objects that focus on a model data (key) can be registered as listeners, once the value of a key in the model changes, it is broadcast to all listeners. This is the same as binding in flex and javafx.

2. view cannot directly reference the controller and model. It is controlled by the Controller to display data and receive user interaction. We know that data is required when the view is displayed, and we also know that events will occur on The View. If you want to deal with a model directly instead of a controller, you need a mechanism to support it. In objective-C, protocol exists and delegate (proxy mode) is proposed to solve the loose coupling interaction problem between uiview and controller. In addition, IOS also provides the action-Target mode for the Controller to listen to view events. For how to obtain data from the view
The concept of source is actually the application of protocol.

3. Every time an operation screen is pushed to the user, it is best to use a combination of MVC. Do not use a combination of more than one MVC.