View decoupling in mobile App development

View decoupling in mobile App development
In the past few days, I am working on downcoupling IOS code. By the way, I am nagging a few questions about View decoupling in development.
First, we should first find the role of View: View should only care about the front/back View, font attributes, layout characteristics, x/y/width/height and other pure visual attributes. You should not worry about data loading, modification, event response, and other Model and Controller concerns. Of course, it also includes custom views.


Next, we will discuss how to reduce the impact of View coupling on the overall architecture in the development of this role.
1. View initialization and attribute settings should have their own owners and should not be placed in the Controller. Of course, this work may be replaced by XML layout in Android or Xib in IOS. The Controller is only responsible for obtaining the reference of the View and setting the default data, and installing Listener and other operations.
2. Data Provision and update and refresh should be triggered by the Controller. If the data is complicated, such as list and grid, add the Adapter layer to decouple the Model and View.
3. Events should be triggered through Listener to decouple views from controllers. Do not directly write the logic corresponding to events into views, which will affect the reusability of views and make the code difficult to maintain.
4. Solve the screen adaptation problem in the View. Do not do it in the Controller. For example, you can use XML in Android to Achieve flexible layout, or use AutoLayout in IOS.


Finally, let's talk about the actual operation.
The XML layout provided by Android is forced decoupling in disguise, so that we seldom mix other code in the View during use. We only need to note that when the View Model is complex, add the Adapter layer for decoupling.
In IOS, the commonly used code for generating a View due to historical reasons may generate a View in the Controller, set the View attribute, and implement functional logic in the View. MVC coupling is serious. Given that Storyboard has many restrictions on the Controller, we recommend that you provide the View layout through Xib in a large IOS project and map the View instance to the Controller through IBOutlet, load data through the Controller and install Listener. Do not show Code that operates the visual attributes of a View in the Controller.