What's happening with IOS app 2: How to build the right framework

The "iOS app development" series of articles from a more macroscopic point of view, not only limited to specific features, interface implementation, but the combination of NetEase cloud letter IOS Development owner years of experience, from the perspective of how to optimize the existing code, in-depth analysis of how to create more appropriate specifications and frameworks for IOS app development .

Recommended Reading

What's happening with IOS App 1: How to build the right specification

A suitable framework is not a silver bullet, and it seems to me that the problem that the framework solves is never: with the framework, the project can go on very correctly. What a good framework can do is simply to reduce the complexity of common problems and reduce the likelihood of errors. Personally think a good iOS app framework should have the following features:

Define a clear hierarchical structure

On the transverse side, each module is independent of each other and communicates only through a limited number of interfaces. The ideal state is that other modules are pluggable except for the core modules. Vertically, the relationship between the various levels is clear, and there is no reverse dependence.

The horizontal module generally relies on business requirements and is often defined as a variety of service or manager. A good practice is to have a unified Service manager responsible for the corresponding serivce loading, unloading, monitoring and distributing app-level notifications to the appropriate service, such as front-end switching, receiving memory warnings, and so on. In this way, it is easy to achieve the above-mentioned module pluggable, on the other hand, it also guarantees the consistency of the common characteristics processing. Well done in this respect, all the basic modules are inherited from Mmservice and managed by Mmservicecenter. Of course, the header file from the dump can also find some management disorders, such as some viewcontroller are inherited from the mmservice.

L Vertical Hierarchy Division basic individual apps will not be much different, generally can be divided into three levels:

Presentation Layer (Presentation layer) , responsible for managing UI and Uiviewcontroller.

Logical Layer (Business/service Layer), responsible for the definition and forwarding of logical data, play a connecting role.

Data Access Layer (Data Access Layer) , responsible for specific API Construction, network requests, data persistence, and more.

Each layer uses a single-layer or multi-tiered structure within the complexity of the business logic. Taking data access layer as an example, it can be subdivided into network layer and persistence layer. In general, the presentation layer (UIView and Uiviewcontroller) is presented directly using the model provided by the logic layer, but in some scenarios it is often necessary to have the same interface display for different model (such as our app, the session interface, the collection interface, The question function needs to show the picture, but the model definition under the three modules is not consistent, which requires adding additional viewmodel layers for bonding the presentation layer and the logical model.

Adherence to solid principles and careful use of design patterns

This is a cliché topic, is not unique to iOS development, to start talking about a few days and nights, do not repeat.

Define your own UI base class: Uiview,uiviewcontroller,uitableviewcell

The benefit of this is self-evident, that all sub-View,controller,cell can easily inherit the common behavior of the base class, style. But also will introduce the very big management risk: The group member always can not withstand the temptation to the base class plug various not universal characteristic, causes the base class authority and authority the infinite expansion. The Daji class not only increases the difficulty of the group members ' understanding of the code, but also increases the difficulty of troubleshooting when problems arise. In this respect, the Uiviewcontroller base class design is extremely unsuccessful: Mmuiviewcontroller This kind of bald file has hundreds of lines.

Provides easy-to-use tool classes

Some easy-to-use tools often become an integral part of the framework, solving local problems quickly and easily without introducing too much complexity. Nstimer's retain cycle is a very easy-to-fall pit, so providing a Nstimer package based on block or weak delegate is a good choice. The use of KVO easy to take place add and remove the unworthy call, then introduce the thobserversandbinders or FB Kvocontorller. When some core modules need to be dependent on multiple modules, introducing XMPP-like gcdmulticastdelegate can be easily decoupled.

A good example

In the dark days of using C + + in previous years, one of the things I used to think about was how to limit and circumvent some errors at the API level. For example, the task thrown into the thread pool must be the allocated object on the heap, so how to force the incoming pointer to the heap address instead of the stack address? This silly question is largely non-solvable, and sometimes the solution is an unusually awkward one. And now I am more convinced of the possibilities offered by the broken window theory: To do a demonstration, and everything will come to a ripe future.

You can poke those things that the IOS app has developed. 1: How to build appropriate specifications review the first article of the series, and welcome everyone to actively express their views and discuss with us.

What's happening with IOS app 2: How to build the right framework