Model-View-ViewModel for iOS [translation], viewmodel
If you have been developing iOS applications for a period of time, you must have heard of Model-View-Controller, that is, MVC. MVC is the standard mode for building iOS apps. However, recently I have become increasingly tired of some shortcomings of MVC. In this article, I will review what MVC is, describe its shortcomings, and tell you a new way to build your app: Model-View-ViewModel. Come up with your buzzword bingo card (bingocard, a game card-Translator's note) because we are about to make a paradigm shift.
Model-View-Controller
Model-View-Controller is an authoritative paradigm used to organize code. Apple even said so. In MVC, all objects are classified as a model, a view, or a controller. The Model holds data, and the View displays the interface for user interaction, while the view controller mediated the interaction between the model and view.
In, view notifies the controller of user interaction. View controller updates the model to reflect status changes. Model (usually Key-Value-Observation) notifies the controller to update the view they are responsible. Code of most iOS applications is organized in this way.
The model objects are usually very simple. Most of the time, they are Core Data managed objects, or avoid using Core Data, which is another popular Data model layer. According to Apple's documents, the model includes the business logic of data and operation data. In practice, the model layer is often very thin. In any case, the business logic of the model layer is dragged into the controller.
A view is usually a set of UIKit controls (component, which is translated as a control according to your preferences) or encoded. When you enter. xib or Storyboard, you will find that an app, Button, and Label are composed of these visualized and interactive controls. You know. View should not directly reference the model and reference the controller only through the IBAction event. The business logic is obviously not classified into the view, and the view itself does not have any business.
There is also a controller. Controller is the app's "glue code": coordinates all interactions between the model and the view. The Controller is responsible for managing the view hierarchies of the views they own and responding to the loading, appearing, disappearing, and so on of the views, at the same time, it is often full of the model logic that we do not want to expose and the business logic that we do not want to expose to the view. This leads to the first question about MVC...
Heavy View Controller
Because a large amount of code is put into the view controller, they become quite bloated. In some iOS view controllers, thousands of lines of code are not unknown. The prominent situations of these overweight apps are as follows: the heavy View Controller is difficult to maintain (because of its large scale); it contains dozens of attributes, making their status difficult to manage; following many protocols leads to obfuscation of the protocol response code and the controller logic code.
Heavy view controller is difficult to test, whether it is manual or unit testing, because there are too many possible states. Splitting code into smaller modules is usually a good thing.
Lost network logic
The MVC definition used by Apple is as follows: all objects can be classified as a model, a view, or a controller. That's all. So where can I put the network code? Where should I place the code for communicating with an API?
You may try to put it in the model object, but it will also be tricky, because the network call should be asynchronous, so if a network request has a longer lifecycle than the model that holds it, things will become complicated. Obviously, the network code should not be put in the view, so only the controller is left. This is also a bad idea, because it increases the problem of heavy View Controller.
So where should we put it? Obviously, the three major components of MVC are not suitable for such code at all.
Poor Testability
Another major problem with MVC is that it does not encourage developers to write unit tests. As view controller integrates view processing logic and business logic, unit tests that separate these components become a daunting task. Most people choose to ignore this task, that is, they do not perform any tests.
Define a fuzzy "Manage"
Previously, I mentioned that view controller can manage the attempted hierarchies. view controller has a "view" attribute and can access any sub-views of a view through IBOutlet. This is not easy to scale when many outlets exist. In a sense, it is best not to use the child view controller to help manage subviews ).
Where are the key points? Should the business logic entered by the user be classified as controller or model?
There are many vague standards here, and it seems that no one can reach an agreement completely. It seems that in any case, the view and the corresponding controller are tightly coupled. In short, they will still be treated as a component.
Hey! Now I have an idea...
Model-View-ViewModel
In the ideal world, MVC may work well. However, we live in the real world. Now that we have explained in detail the problems of MVC in typical scenarios, let's take a look at an alternative: Model-View-ViewModel.
MVVM comes from Microsoft, but do not stick to it. MVVM is similar to MVC. It formally standardizes the nature of tight coupling between views and controllers and introduces new components.
In MVVM, view and view controller are formally linked. We regard them as a component. The view still cannot directly reference the model. Of course, the controller cannot. Instead, they reference the view model.
View model is an excellent place for Putting user input verification logic, view display logic, initiating network requests and various other code. One thing should not be classified as view model, that is, reference of any view itself. The view model concept applies to both iOS and OS X. (In other words, do not use # import UIKit. h In the view model)
Because the presentation logic is placed in the view model (for example, the value of the model is mapped to a formatted string), The view Controller itself will not be bloated. The best way to start using MVVM is to put a small part of the logic into the view model, then, when you gradually get used to this paradigm, migrate more logic to the view model.
The iOS app using MVVM is highly testable. Because the view model contains all the presentation logic and does not reference the view, it can be fully tested by programming. Although many hack technologies are involved in testing the Core Data model, apps written using MVVM can perform full unit tests.
In my experience, using MVVM will slightly increase the amount of code, but in general it will reduce the complexity of the Code. This is a cost-effective transaction.
Looking back at the MVVM illustration, you will notice that I have used fuzzy vertices "Y" and "update", without detailed instructions on how to do this. You can use KVO, just like MVC, but it will soon become difficult to manage. In fact, using ReactiveCocoa is a better way to organize various parts.
For more information about how to use MVVM with ReactiveCocoa, read Colin Wheeler's excellent write-up or check out my open-source app. You can also read my ReactiveCocoa and MVVM books.
Original article link
Model-View-ViewModel for iOS by Ash Furrow
Additional reading
[1] http://wearebase.com/an-introduction-to-mvvm-and-reactivecocoa-on-ios/
[2] http://blog.sunnyxx.com/tags/Reactive-Cocoa-Tutorial/
[3] http://objccn.io/issue-13-1/
[4] http://limboy.me/tech/2014/06/06/deep-into-reactivecocoa2.html
[5] https://github.com/ReactiveCocoa/ReactiveCocoa
Appsync for iOS50 + download
Enter cydia, click search, and enter Appsync for iOS5.0 +. Remember to add Wei Feng source.
If DEB is used, go to Weifeng to find it and put it in the automatic installation directory of Cydia.
Pspsimulator for ios
The iphone simulator is updated slowly. We recommend that you use Android or PC. Search ppsspp for the simulator. Use the question to post it for help