iOS componentization is not just the architect's job

iOS componentization was once a hot topic in the industry, but now few people mention it again. There are many articles and ideas about componentization on the Internet. The most classic one is the debate between Casa and Mogujie on componentization. When I think about these articles, I think componentization is such an excellent idea. I think what they say makes sense, and Casa should have given me and other programmers a lot of inspiration in many ideas. Does the debate between the two architects make you truly understand the importance of componentization? Does it resonate with you deep in your heart? I recently saw a project that made me think more about componentization.

[[249145]]

1. Why do we need componentization? What are the benefits of componentization?

Why do we need componentization? After reading many excellent articles, you will definitely ask this question: how much benefit can componentization bring us? As a small company, there are few opportunities to involve componentization. Without work experience in large factories, it is difficult to understand componentization thoroughly. You may think that our business modules are not enough, or that we do not understand its benefits. In fact, the biggest benefit of componentization is that each component and each module may become an app alone with its own life cycle. In this way, it can be divided into different business group modules for processing. I heard that JD.com has a team dedicated to the message module, a team dedicated to the advertising module, and a team dedicated to the discovery module. You will find that if there is no good componentization idea, such multi-team cooperation is very difficult, and it is already difficult to maintain the development iteration of this project. Having said so much, what does componentization look like? Then I will follow my footsteps, learn, analyze, and discuss.

2. The core idea of ​​componentization

The core idea of ​​componentization, which is also the basic framework for componentization, is how to achieve componentization, or how to achieve architecture from multiple levels such as architecture layer and business layer. To achieve componentization, it is actually to build an intermediate conversion tool. You can also think of it as routing, which can realize cross-business data communication through the idea of ​​routing, thereby reducing the coupling of data at each layer to a certain extent. Reduce the coupling of imports at each business layer and other levels.

3. The current implementation of componentization

There are three general ideas for implementation at present:

1. Procotol regimen
2. URL Routing Scheme
3. target-action scheme

Procotol Protocol Registration Scheme

Regarding the procotol protocol registration scheme, few people use it, and few people share it. I also saw it in this project and studied it. Use JJProtocolManager as an intermediate conversion.

 + (void)registerModuleProvider:(id)provider forProtocol:(Protocol*)protocol;  
 + (id)moduleProviderForProtocol:(Protocol *)protocol;

The procotols and services provided by all components are centrally managed by the middleware, and the procotols and services provided by each component correspond one to one.

For example:

In JJLoginProvider: the load method will be called when the application starts, and it will be registered in JJProtocolManager. JJLoginProvider complies with the JJLoginProvider protocol, so that some methods can be provided to the outside world according to business needs.

 + (void) load  
 {
    [JJProtocolManager registerModuleProvider:[self new] forProtocol:@protocol(JJLoginProtocol)];
 }
 - (UIViewController *)viewControllerWithInfo:(id)userInfo needNew:(BOOL)needNew callback:(JJModuleCallbackBlock)callback{
    CLoginViewController *vc = [[CLoginViewController alloc] init];
    vc.jj_moduleCallbackBlock = callback;
    vc.jj_moduleUserInfo = userInfo;
 return vc;
 }

In this way, you can directly obtain the service provider JJLoginProvider corresponding to JJLoginProtocol through JJProtocolManager when you need to log in to the business module. As follows:

 id<jjwebviewvcmoduleprotocol> provider = [JJProtocolManager moduleProviderForProtocol:@protocol(JJWebviewVCModuleProtocol)];
   UIViewController *vc =[provider viewControllerWithInfo:obj needNew:YES callback:^(id info) {
 if (callback) {
 callback(info);
 }
 }];
   vc.hidesBottomBarWhenPushed = YES;
   [self.currentNav pushViewController:vc animated:YES];</jjwebviewvcmoduleprotocol>

URL Routing Scheme

The most classic URL routing solution is Mogujie's routing componentization, which encapsulates the calling method, calling parameters, and callback method into the URL through the URL, and then obtains the method name and parameters by parsing the URL, and finally calls the method through the message forwarding mechanism.

The following is the routing method of Mogujie: (If you want to learn more about it, you can learn about the routing componentization of Mogujie)

 [MGJRouter registerURLPattern:@ "mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
    NSNumber *id = routerParameters[@ "id" ];
 // create   view controller with id
 // push view controller
 }];

The home page only needs to call [MGJRouter openURL:@"mgj://detail?id=404"] to open the corresponding detail page.

Here you can see that we use the URL shortening method to splice the parameters into the URL query part, so that we can parse the scheme, host, path, and query in the URL to get the controller to transfer to and the parameters to pass, so as to push or present the new page.

Parsing scheme, host, path core code:

 NSString *scheme = [nsUrl scheme];//Parse scheme
   NSString *module = [nsUrl host];
   NSString * action = [[nsUrl path] stringByReplacingOccurrencesOfString:@ "/" withString:@ "_" ];
   if ( action && [ action length] && [ action hasPrefix:@ "_" ]) {
 action = [ action stringByReplacingCharactersInRange:NSMakeRange(0,1) withString:@ "" ];
 } 
  
 NSString *query = nil;
   NSArray* pathInfo = [nsUrl.absoluteString componentsSeparatedByString:@ "?" ];
 if ( pathInfo.count > 1) {
       query = [pathInfo objectAtIndex:1];
 }

The core code for parsing query:

 NSMutableDictionary *parameters = nil;
 NSString *parametersString = query;
 NSArray *paramStringArr = [parametersString componentsSeparatedByString:@ "&" ];
 if (paramStringArr && [paramStringArr count ]>0) {
    parameters = [NSMutableDictionary dictionary];
 for (NSString* paramString in paramStringArr) {
        NSArray *paramArr = [paramString componentsSeparatedByString:@ "=" ];
        if (paramArr. count > 1) {
            NSString * key = [paramArr objectAtIndex:0];
            NSString *value = [paramArr objectAtIndex:1];
            parameters[ key ] = [JJRouter unescapeURIComponent:value];
 }
 }
 }
 return parameters;

In this way, we can achieve componentization, but sometimes we will encounter an image editing module that cannot pass UIImage to the corresponding module. Here we need to pass a new parameter in. In order to solve this problem, we can actually throw the parameter directly to the arg processing behind.

 + (nullable id)openURL:(nonnull NSString *)urlString arg:(nullable id)arg error:( NSError*__nullable *__nullable)error completion:(nullable JJRouterCompletion)completion

For example:

      Action * action = [ Action new];
 action.type = JJ_WebView;
           Params *params = [[Params alloc] init];
           // params.pageID = JJ_LOGIN;
 action.params = params;
           NSDictionary *parms = @{Jump_Key_Action: action , Jump_Key_Param : @{WebUrlString:@ "http://www.baidu.com" , Name :@ "小二" }, Jump_Key_Callback:[JJFunc callback:^(id _Nullable object) {
               NSLog(@ "%@" ,object);
 }]};
 // ActionJump(parms); 
             
           [JJRouter openURL:@ "router://JJActionService/showWebVC" arg: parms error:nil completion:parms[Jump_Key_Callback]];
 }

The project I looked at achieved componentization through URL parsing and protocol registration, but it did not register which URL types it supported like Mogujie did.

target-action scheme

The target-action solution is based on the study of Casa master, CTMediator

Casa God believes that

1. It is impossible to express unconventional objects. If you use url componentization, you need to add a parameter to solve the problem when you encounter parameters like UIImage.
2. URL registration is completely unnecessary for implementing component solutions, and the scalability and maintainability of component solutions formed by URL registration will be discounted.
3. Mogujie does not separate remote calls and local calls
4. Mogujie must register the URL responder when the app starts

 //In theory, you only need to open a URL to jump between pages . So for a component, you only need to define "which URLs are supported", such as the details page, which can be done like this
 [MGJRouter registerURLPattern:@ "mgj://detail?id=:id" toHandler:^(NSDictionary *routerParameters) {
   NSNumber *id = routerParameters[@ "id" ];
 // create   view controller with id
 // push view controller
 }];

The componentization of Casa is mainly based on the Mediator mode and the Target-Action mode, and the runtime is used in the middle to complete the call. This componentization solution separates the remote application call and the local application call, and the local application call provides services for the remote application call, which is exactly the opposite of the Mogujie solution.

Calling method:

Let's talk about local application calls first. Local component A calls [[CTMediator sharedInstance] performTarget:targetName action:actionName params:@{...}] somewhere to initiate a cross-component call to CTMediator. CTMediator generates a target instance and the corresponding action selector based on the obtained target and action information through objective-C runtime conversion, and then finally calls the logic provided by the target business to meet the requirements.

In a remote application call, the remote application uses openURL to let the iOS system find an application that can respond to the URL (in the context of our current discussion, this is your own application) according to the scheme configuration in info.plist. After the application receives the URL through AppDelegate, it calls CTMediator's openUrl: method to pass in the received URL information. Of course, CTMediator can also use openUrl:options: to receive the accompanying options, depending on whether the necessary and sufficient conditions for your local business execution logic include option data. After passing in the URL, CTMediator parses the URL and routes the request to the corresponding target and action. The subsequent process becomes the local application call process mentioned above, and finally completes the response.

The routing operation for requests rarely uses the method of recording routing tables in local files. The server often handles this kind of business. In the server field, routing parsing is basically done through regular expressions. Routing parsing in the App can be done more simply by formulating URL specifications. The simplest way is scheme://target/action. A simple string processing can extract the target and action information from the URL.

For example:

 /**
 Here is the target of the login module
 **/
 #import "CTMediator+ModuleLogin.h"  
 NSString * const kCTMediatorTargetA = @ "A" ;
 NSString * const kCTMediatorActionLoginViewController = @ "showLoginController" ;
 @implementation CTMediator (ModuleLogin)
 - (UIViewController *)push_viewControllerForLogin
 {
   UIViewController *vc = [self performTarget:kCTMediatorTargetA action :kCTMediatorActionLoginViewController params:nil shouldCacheTarget: NO ]; 
     
   if ([vc isKindOfClass:[UIViewController class]]) {
 // After the view controller is delivered, the outside world can choose whether to push or present it
 return vc;
 } else {
 // This is where exception scenarios are handled. How to handle them depends on the product.
 return [[UIViewController alloc] init];
 }
 }

 /**
 Login module action  
 **/
 - (UIViewController *)Action_showLoginController:(NSDictionary *)param
 {
   JJLoginViewController *vc =[[JJLoginViewController alloc] init]; 
     
 return vc;
 }

It seems that the target-action routing solution is clearer, but it depends on your needs.

Next, the core code of target-action is:

 /**
 if ([target respondsToSelector: action ])
 Determine whether the target can respond to the action method. If it can, execute this core code.
 The main functions of the core code:
 **/
 - (id)safePerformAction:(SEL) action target:(NSObject *)target params:(NSDictionary *)params
 {
 //// Create a function signature. This signature can be arbitrary, but it should be noted that the number of parameters of the signature function must be consistent with the call.
   NSMethodSignature* methodSig = [target methodSignatureForSelector: action ];
 if(methodSig == nil) {
 return nil;
 }
 // Get the return type
   const char * retType = [methodSig methodReturnType];
 // Determine the return value type
   if (strcmp(retType, @encode(void)) == 0) {
 // Initialize with signature
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
 //If this message has parameters to be passed in, then you need to set the parameters as follows. Note that the atIndex index must start from 2. The reason is: 0 1 The two parameters are already occupied by target and selector
       [invocation setArgument:¶ms atIndex:2];
 // Set the selector
       [invocation setSelector: action ];
 // Set the target
       [invocation setTarget:target];
 //Message call
 [invocation invoke];
 return nil;
 }
   if (strcmp(retType, @encode(NSInteger)) == 0) {
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
       [invocation setArgument:¶ms atIndex:2];
       [invocation setSelector: action ];
       [invocation setTarget:target];
 [invocation invoke];
 NSInteger result = 0;
       [invocation getReturnValue:&result];
 return @(result);
 }
   if (strcmp(retType, @encode(BOOL)) == 0) {
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
       [invocation setArgument:¶ms atIndex:2];
       [invocation setSelector: action ];
       [invocation setTarget:target];
 [invocation invoke];
 BOOL result = 0;
       [invocation getReturnValue:&result];
 return @(result);
 }
   if (strcmp(retType, @encode(CGFloat)) == 0) {
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
       [invocation setArgument:¶ms atIndex:2];
       [invocation setSelector: action ];
       [invocation setTarget:target];
 [invocation invoke];
 CGFloat result = 0;
       [invocation getReturnValue:&result];
 return @(result);
 }
   if (strcmp(retType, @encode(NSUInteger)) == 0) {
       NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:methodSig];
       [invocation setArgument:¶ms atIndex:2];
       [invocation setSelector: action ];
       [invocation setTarget:target];
 [invocation invoke];
 NSUInteger result = 0;
       [invocation getReturnValue:&result];
 return @(result);
 }
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Warc-performSelector-leaks"  
 return [target performSelector: action withObject:params];
 #pragma clang diagnostic pop
 }

Summarize:

Based on the obtained target and action information, CTMediator generates a target instance and the corresponding action selector through objective-C runtime conversion, and then finally calls the logic provided by the target business to meet the requirements.

Here are three ways to implement Git's address code:

https://github.com/lumig/JJRouterDemo

Easter Eggs:

 // url encoding format
 foo://example.com:8042/over/there? name =ferret#nose
 \_/ \______________/ \________/\_________/ \__/
 | | | | |
 scheme authority path query fragment
 scheme://host.domain:port/path/filename
 scheme - defines the type of Internet service. The most common type is http
 host - defines the domain host (default host for http is www)
 domain - defines the Internet domain name, such as w3school.com.cn
 :port - defines the port number on the host (the default port number for http is 80)
 path - defines the path on the server (if omitted, the document must be in the root directory of the website).
 filename - defines the name of the document/resource