Today’s top story: A miscellany of iOS architecture design

At present, there are more and more people in the development team, and the business requirements and functional requirements are increasing after the operation of the application. In the absence of a good architectural design, it will be more difficult to maintain. Therefore, architectural design is an issue that has to be considered in the application development.

This is a very simple piece of code that starts the App, initializes the Applocaltion object, and then distributes various events to the implementation API. Behind this code is an infinite loop of RunLoop, which drives the entire App on the main thread to process UI events and distribute them to the corresponding API.

Without API encapsulation and UI Kit architecture, it would be cumbersome to implement a simple button in main.

In the final analysis, the purpose of architecture design is to lower the threshold of business development, make business development easier, and make engineering code easy to understand and maintain.

If you want to do engineering architecture, you must first pursue code. DRY and Kiss are two principles that you should be familiar with. DRY means Don’t repeat yourself. Kiss — Keep It Simple, Stupid — architecture design is not about cool and complexity but about making engineering architecture Simple and easy to understand, hiding complicated details and providing easy-to-use apis.

The Solid principle was proposed for object-oriented programming, and many of the things in the principle are important even now when we reflect on some of the problems of object-oriented programming.

The single function rule. Do not consider implementing a function that is unrelated to it in a module. For example, a class that handles both String MD5 and image decompression is a clear violation of the single function rule. Further, in fact, in the method should not deal with too many things.

Open and close principle: when designing modules, we should consider the closure of extension development and modification. The simple understanding is to refine the invariant logic, encapsulate the stable part into the core logic of the module, and inject the extensible part.

The Richter substitution principle means that all subclasses can replace the superclass, but generally we do not break the superclass logic through subclasses.

The principle of interface isolation is that the client should hide unnecessary details and isolate those parts from relying on them to make the API dependencies more concise.

The dependency reversal principle, which means that high-level modules should not depend on low-level modules, is a false proposition, because once a high-level module depends on a low-level module, it is not a high-level module. If a high-level module does depend on something, it should be abstract.

The principle of least knowledge is that the less a developer knows about a module when using it, the better.

These six principles are all about two things over and over again. One is to design an API that is easy to understand, and the other is to establish reasonable dependencies.

Based on the above principles, predecessors have summarized some methodologies, such as MVC, MVVM, and Viper, which are actually the experience of module split role design. Of course, these are in THE GUI layer, but in other layers can also have their own experience of role split.

What I’m most excited about in MVVM is the role of the ViewModel, because the ViewModel is smaller than the Controller in Apple’s MVC design, but it also handles business logic, and when the business logic is broken down sufficiently small and scattered, those parts are more likely to be reusable.

The ViewModel is actually the shadow of the View’s data layer, and the amazing thing about it is that the shadow can be changed and mapped to the entity. In this process, the ViewModel abstracts UI data and then binds it to properties on the UI.

Another important part of the GUI is the ViewController. Although we want to break MVC, Apple’s UI Kit is designed based on MVC, and the ViewController is given an important role in controlling the page jump and configuring the ViewModel and View bindings.

LoginView takes two Textfiles and binds their text parts to username and password, respectively, so that the data in the ViewModel layer is synchronized as the user acts on the UI. Then the LoginView’s LoginButton event is handled in the ViewModel. When the LoginButton event is triggered, the ViewModel can handle a series of events outside of the UI layer.

If you actually implement it based on the previous design, without the introduction of third-party assistance, you will find that it is very complicated. So in order to make it easier to develop functionality, you need to bring in a third party or refine something yourself.

The first one can be refined is the Common UI. For example, for controls with similar styles, Common code can be refined as the Common UI to achieve the purpose of component reuse. When the model is shared after the login is processed, you can encapsulate an AccountManager to trade the model to the server, which can then be used elsewhere to obtain tokens or user information.

Binding on the UI Kit is not easy. You need a framework like ReactiveCOcoa or RxSwift to bind the View to the ViewModel, deserialize the model, etc.

After such a design, the hierarchical structure of the entire App has been preliminarily formed. The bottom layer is the App function, and on top of that is the App general business layer, which provides components and modules that can be used mutually. A lot of the things in the iOS generic layer that go up from there can be used in other iOS development.

Usually a company will have several apps, and some common logic in the App may be available to other apps as well. After MVVM design, ViewModel and Model have been decoupled from App UI, ViewModel can be easily lifted up a level for the entire company to use. At this time, the entire architecture will have an additional corporate common business layer.

In the whole process, MVVM guides the separation of UI and business logic components. The decoupling of UI and business logic makes the login function of different apps have common components, and makes binding, network request and data deserialization easier to realize through rich iOS common layer components.

An important result of the architecture design is that the three common layers have rich tools and modules, so that most business development can be achieved by combining the common layer’s module tools.

Designing a good module begins with understanding design principles, knowing when to make bad dependencies, and sticking to those principles. Also understand the common module design methods, such as MVVM in-depth understanding of THE GUI layer logic to do a good split. The last and most important point is to constantly reflect on the improvement, in fact, when there is a pit to think about why the pit.

To implement good design principles or good design on a project, you first need to establish a proper engineering document structure and know where to put your packaged components. Also, reach a consensus on the design of the team’s architecture.