An explanation of MVC pattern inside iOS

An explanation of MVC pattern inside iOS

MVC is a design pattern inside iOS that is also a lot of programming, M is Model,v is View,c is controller. The MVC pattern is very much used in iOS development.

The following is a translation of the MVC pattern within the Stanford University iOS development

The main purpose is to divide all the objects into 3 camps, model camp, view camp, or controller camp.

Model (The purpose of the app)

For example, you want to play a game of flying, then this is the space of the ship's location, what aircraft, how many machine guns per ship, how much armor and so on. This is what the model does, and the plane's position on the screen is not related to the model.

The role of model is to show the model in front of the user, which acquires the spacecraft's position in space and then calculates how it is displayed on the screen.

This is how Controller,controller controls how the model is displayed on the UI.

View is the controller in the servant, view is the tool used by the controller. We try to generalize the objects inside the view camp as much as possible.

Like buttons, sliders, etc., these are Apple's own. The controller uses these generic view to do what the model needs to do, and the view should be very generic. Because there are a lot of view on the system, there are functions related to the application to control the view. We need to be more advanced to understand and use these features using a common view.

The controller sends a message to model 100% is allowed, the arrow is Green Arrow, Controller can ask model any problem, controller knows anything about model, Because the controller is used to display the model on the screen, all it has to have full access, the arrow is unidirectional, so only the controller knows model, which is like a traffic sign, from controller to model is a white dashed line, So you can always cross over, wait a minute, we'll see this dashed line is not always virtual. So what is the communication between controller and view? Also the green Arrow, Controller is the model is displayed on the screen, so it can do anything to view. For example, set a logo, let the view do something, arrange the view on the screen, data communication, so this road is also a white dashed line, you see that word outlet

    outlet is an expression used to represent a controller's attribute to the view communication, so we're going to create a outlets to view in the controller, what about the model and view? The purpose of this course is that they will never communicate with each other. I'm sure you all understand why the model doesn't communicate with view, because model and user interface are irrelevant, you can have a model of a spaceship shooter, and then control it through view, move the ship to XYZ, shoot, you can do that, though rather stupid, but you can do it. So the model is completely UI independent, you should all understand that model should not communicate with view, and some people say that I have some custom view, the master model, so I can display the model. This may sound appealing, but this is not a good idea for the reason-reuse. Because you have the view and model together, the model changes after the view will be rewritten, view can not be reused, the model can not be used by other UI, such as the ipad out, because the screen size of the cause of the need for a new UI, you have to rewrite the entire view, It is better to put this part in the controller, to build some more general view objects, and another reason is that if the view and model communication, then everyone can now communicate with model, view and model communication, controller and model communication, Model is a little hold, if only the controller and model communication can easily figure out what the program is doing, so the view is excluded, view is only controller's servant, let controller to communicate. Therefore, in this course will never happen to the view and model mutual communication situation, double solid line if you cross the line I will give you a ticket. Can view allow communication with controller? The answer is yes to some extent, so the line is yellow. The communication between view (Universal) and controller (detailed control on how to display model) is not visible, and view does not know who is talking to, but has a good architecture. So in Xcode we can have a good organized connection between view and its controller. So, the method that the view communicates to the controller, has the structure method, one is called the target action. The target action is simply that the controller draws a target and then puts an action into its view. When a view has something, such as a button being slid by a slider, it takes the actIon sends the target, and the controller knows the button is pressed. This is the mechanism for the view to communicate with the controller, and the view returns what happened to the controller. But the view does not know much about the controller, it simply sends the target action. In fact, there are more complex communication between the view and controller-for example, the view and controller are kept in sync, so often the view has to tell the controller what happened, this is the did on the graph, or what is going to happen, this is will, Or ask the controller if I allow anything to happen, so these will,did,should are the questions that the view asks. The reason for this is because the controller set himself up as a delegate, with the agreement, and hopefully you all know what the agreement is, we'll talk about it in Obj-c, set up a protocol, go back and forth to do should at once, and view the controller that does not need to know which class to respond to. Delegation is another method of view and controller communication, and another important thing is that view is not the owner of the data it displays, which is important: So in red, you have to understand that view has no data, the view is just a plane that shows the data, A platform to display information, view no entity variables will not be stored, only point to their pointers, so your ipod library 1000 songs will not be the entity variable view, this design makes, such as view does not go to manage the database, with the new ipod song library, this is not the view of the job, Instead of a controller or model, how does it get data if the view doesn't own the data it's displaying? A similar delegation method, it has some protocols, such as the data at and count here, which is very useful for a table, the table can ask how many things, such as 5000, I have 100 to 150 of the data, I want to use to display, So the view goes to request data on demand, which is very efficient, if the other side knows how to manage a huge database, but only to extract a few of them, because there are 10,000 songs on the ipod, but only 7 on the screen display. You want this function, but do not write it in a view, the view is used to display, the controller amount of the model to provide efficient information, similarly, the view will have a data source settings, controller will respond to the data source, note that The delegation of the data source is always the controller, or the controller's specifiedThree-way, but impossible is Model,controller's job is to pass the model information to the view and respond to all the delegation. Because it can get the data in the model, decide how to display it on the screen, that's its function, so it's going to take part in this loop, you might need these data at and count methods, maybe just a line of code, ask what the model data is, then model gives you the data, Even if this is a line of code, also need controller to participate, because this is the controller's work, get model display on the screen, I repeat the 5 series, this is the controller's work in iOS development This is very important, you have to give him the opportunity to do his work, Never cross the line between the view and model, and one more thing, can the model be spoken to the controller? This is obvious, certainly not. Model is UI independent, can not be called to controller, this is the controller's work to display the model with view, then when the model of something changed, you want to update the controller when the time to do? You have a database, someone wrote something in the database, like the other players in your spaceship game attacking your ship, and now the model changed because the ship was injured.

In iOS we implement the method is to use a radio station like the information broadcast mechanism, there are 2 mechanisms to inform the key data monitoring, when the model changed, it is broadcast in the broadcast stations, Controller received, and then go to model something changed. This is completely invisible, synchronous, and here the KVO can also be used for view and controller but not view and Model,view there will be no model-oriented broadcasts, and the view and controller will broadcast to each other. The model broadcast is very useful, because it is invisible, but there are restrictions, can only notify the objects allowed to communicate what happened, now we have all the communication mechanism between the camps, we want to build a complex application. Complex applications are not just a controller. View may have 100 controller at least more than 10 control a lot of view, such as login interface, click on what out of the table, and then point out what else, a variety of view by controller management, how to do complex applications? The answer is to synthesize the MVC group, and you can see that some controller's view is another MVC, like this one in the middle, it has 3 MVC view, so it's common that you press a button in a view, and another MVC shows the data, A good place for this figure is that all arrows only pass through the specified bounds. You see any part of it, you know what this part is for, a model with only one controller

An explanation of MVC pattern inside iOS