iOS componentization solution (Part 2)

Overview

This is the second article of iOS componentization solution-summary. In this article, I implemented a demo of the Target-Action solution and compared it with the protocol solution introduced in the first article.

If you haven't read my first article on protocol componentization, you can download the demo provided in that article first, which will help you understand the details of this article and the business scenarios implemented in my demo.

Target-Action Solution

It is an international practice to upload the demo first (just download the main project. If you don’t understand, you can download all the business modules. Casa also provides an official demo. I provided a portal in my first article)

The following link can be used to view the original text.

• Target-Action Solution Main Project
• Target-Action solution product details business Category component address
• Target-Action solution product details business module address
• Target-Action solution confirms the order Category component address
• Target-Action solution confirms the order business module address
• Target-Action solution CTMediator address Because Casa did not make CTMediator a public library, I directly copied it and made it my private library.

Implementation

I won’t introduce how to make modules into private pods here. If you want to know, you can read my first article on componentization. I will only take the order confirmation module as an example.

The order confirmation module is a separate project. In order to avoid other modules calling the order confirmation module and importing the entire module, a private component of the order confirmation business Category is created as shown below.

TAConfirmOrderBusinessCategory is the entry point for the confirmation order module to provide services to the outside world. Our business scenario is that the product details module immediately purchases and enters the confirmation order module. After the confirmation order module submits the order, it returns to the product details module and is notified that the order is successful. Therefore, the input parameter in the above figure provides the ConfirmComplete Block. The following figure is the implementation in TAConfirmOrderBusinessCategory.m

 #import "CTMediator+TAConfirmOrder.h"   
  
 @implementation CTMediator (TAConfirmOrder) 
  
 - (UIViewController *)confirmOrderViewControllerWithGoodsId:(NSString *)goodsId goodsName:(NSString *)goodsName ConfirmComplete:(dispatch_block_t)confirmComplete
 {
    NSMutableDictionary *params = [[NSMutableDictionary alloc] init];
    params[@ "goodsId" ] = goodsId;
    params[@ "goodsName" ] = goodsName;
    params[@ "completeBlock" ] = confirmComplete;
 return [self performTarget:@ "TAConfirmOrder"   action :@ "ConfirmOrderViewController" params:params shouldCacheTarget: NO ];
 } 
  
 @ end  

OK, TAConfirmOrderBusinessCategory is implemented. Let's take a look at the TAConfirmOrder module. A Target_TAConfirmOrder is defined in the module. The specific implementation is as follows

 @interface Target_TAConfirmOrder : NSObject 
  
 - (UIViewController *)Action_ConfirmOrderViewController:(NSDictionary *)params; 
  
 @ end   
 
 @implementation Target_TAConfirmOrder 
  
 - (UIViewController *)Action_ConfirmOrderViewController:(NSDictionary *)params
 {
    TAConfirmOrderViewController *confirmOrderVC = [[TAConfirmOrderViewController alloc] init];
    confirmOrderVC.goodsId = params[@ "goodsId" ];
    confirmOrderVC.goodsName = params[@ "goodsName" ];
    confirmOrderVC.confirmComplete = params[@ "completeBlock" ];
 return confirmOrderVC;
 } 
  
 @ end  

Since TAConfirmOrderBusinessCategory and TAConfirmOrder are two projects, how does category call Target_TAConfirmOrder? It's actually very simple. I think most people who read this article know that it's nothing more than NSClassFromString, performSelector and other methods. If you don't know, you can read the source code.

So far, I haven't posted any architecture diagrams or explained the principles. I just posted some code and explained how to implement it. Why? In fact, the principle of componentization is very simple, much easier than learning UITableView. My demo is the principle. If you still don't understand it, you can google it yourself or ask questions in the comment area.

Target_Action VS Protocol Solution

1. Is registration required?

• Target_Action scheme does not require registration
• The Protocol solution needs to be registered with CRProtocolManager at startup

Target_Action makes good use of the runtime feature to reduce the registration step, but it is a bit awkward for students who are about to switch to Swift.

In the Protocol solution Demo provided in the previous article, the instance object rather than the Class is registered with the CRProtocolManager. This will indeed cause memory resident, but it is harmless. Students who are familiar with runtime should know that the first call to a class or object method will construct a class object, so whether you register with the Class or the instance object, the memory occupied by an instance object without any property is very small. Of course, you may ask why you register an instance instead of a Class since they are almost the same. The registered ServiceProvider instance object can record some status in some cases. Of course, this only occurs in very rare cases. If you really want to use the ServiceProvider as a singleton object, I still strongly recommend registering the Class.

However, I don't think there is any logical problem with ServiceProvider needing to register with the middleware. The only difference is that it can be omitted or not.

2. Dependencies

The product details module in the Target_Action solution relies on the TAConfirmOrderBusinessCategory component to obtain the service of the order confirmation module

In the protocol scheme, the product details module needs to rely on CRConfirmOrderServiceProtocol to obtain the instance object of the service provided through the CRProtocolManager component. At the same time, the order confirmation module also relies on CRConfirmOrderServiceProtocol to register the service

At first glance, the dependency of the Protocol solution seems to have invaded the business because both the caller and the implementer depend on CRConfirmOrderServiceProtocol. In fact, CRConfirmOrderServiceProtocol should be part of the order confirmation module. It is separated only to avoid the caller from directly referencing the implementer. This dependency should be reflected in the architecture diagram as a dotted line instead of a solid line. Imagine if the Target_Action solution does not use runtime, then BusinessCategory also needs to directly depend on Target. The dependency on CRConfirmOrderServiceProtocol can also be resolved by using NSProtocolFromString in runtime, but it will cause a certain amount of hard coding that is not elegant enough. (By the way, although runtime brings some unexpected effects to our development in some specific scenarios, runtime skips compiler checks, and sometimes it is difficult to troubleshoot bugs, so it should be used with caution)

In the Protocol solution, the product details module depends on both CRConfirmOrderServiceProtocol and CRProtocolManager, while in the Target_Action solution, the product details module only depends on TAConfirmOrderBusinessCategory. The dependency relationship is as follows

The Protocol solution relies on the two horizontally, while the Target_Action solution relies on them vertically. Target_Action is better designed.

3. Readability, hard coding

Target_Action packs the general parameters into a dictionary in Category, and unpacks the dictionary into general parameters in Target, which causes a certain amount of hard coding. However, in real development, the categories provided by each module are usually written by one person, so the impact is minimal, but it brings some inconvenience to other people who read the code. Even when the same person writes Category and Target, he needs to switch between the two projects to check the function names previously defined in Target.

The 0 in the Protocol scheme is hard-coded for better readability.

Here I would like to mention the Url registration scheme. I think the biggest problem with the Url registration scheme is that it has a lot of hard coding, poor readability, and poor maintainability. It is highly dependent on documents, and someone needs to constantly supervise the update of documents. I think many students have a deep understanding of this. The interface documents of the first version of each project are relatively detailed and comprehensive. With the iteration and update of the version, some fields are added to a certain interface. Usually, the backend developers forget to update the documents. Maybe they are busy, or even some students are too lazy to update the documents. Generally, at this time, QQ or other communication tools are used to inform the client developers which fields have been added and what the fields mean. After a long time, the client developer forgets the meaning of the field or another developer takes over. He doesn't know what the meaning of this field is. He first looks through the previous chat records. If he can't find it, he looks at the interface document. The document is still version 1.0... Oh... I go...

Summarize

Combining the above 3 points, Target_Action is better. Our company is currently using the Target_Action solution. If any students have plans to switch to Swift language development, I recommend the Protocol solution. In fact, no solution is perfect. The specific adoption must be combined with your own business and the overall quality of developers. If you are still undecided, Alibaba has open-sourced a module decoupling framework BeeHive (protocol registration). You should move closer to the big companies. I will not provide a demo of the Url registration solution because its readability, maintainability and the shortcomings of conventional parameter passing made me give up it. However, the Url registration solution can solve bugs well with the server's routing, provided that your module must be developed in one set of Native and one set of H5 (or RN and Weex)

Division of supplementary business modules

Many students know about componentization, but don’t know how to divide business modules. I will take some examples of JD App as shown in the figure below.

After each module is componentized, it is a separate project. Maybe there is only one ViewController in many projects. This is also a reasonable division. For example, for product details, many modules (clothing city, JD supermarket, global shopping...) will call the product details module. It is unreasonable to force the business in the product details module into any project (clothing city, JD supermarket, global shopping...). The same is true for order confirmation. Componentization is to cut the business vertically, specifically to the network module in a certain business module, and the division of the database module is horizontal.

Preview

I found that many students have a wrong understanding of MVC, which makes the controller bloated and difficult to maintain. In the next article, I will write my understanding of MVC into a Demo. This Demo will be a module with a relatively large business (so it will take a little longer. After all, I have to work on company projects during the day, and I have several personal projects to maintain). The division of responsibilities will be very clear in this Demo, so stay tuned.