iOS Development - Abstract Protocol of App Architecture

From the perspective of architectural design, an end, especially a mature end, should have its own specifications, ranging from page jumps and service requests to specific business functions such as generating orders, canceling orders, and viewing orders. On the one hand, after formulating a unified protocol, it can not only constrain the development behavior of developers in each business line, unify the code style, but also enhance the cooperation and cohesion of team members. On the other hand, after the unified development behavior, it is very helpful for adding new functions, fixing bugs, querying problems, etc., which greatly improves development efficiency.

[[214533]]

One of the most important functions of the App Architecture Group is to unify the App architecture, allowing business developers to shape end products in a unified architecture, with the mission of improving business development efficiency and ensuring business stability. Based on this principle, we have been exploring various skills related to App architecture over the past year. I have found that the protocol is a key technology that best reflects the significance of App architecture. Using and promoting the protocol well can double the efficiency of business development.

Generally speaking, the protocol types in an App can be arbitrarily divergent. As long as they can be reused, you can use the word "protocol" to describe them. Of course, we are all people with aspirations, and we should create some more general, more abstract, and more reusable protocols. For example, the url scheme in the iOS SDK is such a typical example.

iOS URL Scheme

URL Schemes is a mechanism provided by Apple to jump to system applications or other people's applications. It can also transfer data between applications to implement some specific functions. You can understand the URL of an iOS application in the same way as you understand the URL of a web page.

For example, WeChat’s URL scheme

 weixin://

WeChat Moments URL scheme format

 weixin://dl/moments

Doesn’t it look convenient?

In other apps, you can jump to the WeChat App (if installed) like this:

 NSURL *url = [NSURL URLWithString:@ "weixin://" ];
 [[UIApplication sharedApplication] openURL:url options:@{} completionHandler:^(BOOL success) { 
          
 }];

Each application can create one or more url schemes of its own. You only need to configure the info.plist file, and then communicate between apps through the App Management Center [UIApplication sharedApplication].

Similarly, we can apply this idea to other abstract modules. In each abstract module, we use a protocol to specify its usage rules and supported functions. When it is open to the caller, as long as it follows the protocol rules and uses the API interface provided by the abstract module, it can call the module or use the services it provides.

From this, we can draw the following conclusion: To abstract a module using a protocol, two important components are needed: protocol + protocol management center.

General Protocol

 scheme://service/actor?params=\{\ "xxx\" :xxx\}&origin=xxx

In the App architecture, the page navigation framework is a very important component, which directly determines the page organization and style of the current App. A good page navigation framework can also allow the business side to have the best new page construction and page jump experience. From the perspective of the protocol, we can agree on a page jump protocol as follows:

Page jump protocol

 page:// action ?params=\{\}&origin=xxx
 // Jump to native page
 page:// goto ?params={ "page_name" : "xxxx" , "data" :{ "xxx" : "xxx" ,...}, "navi_type" :0|1, "anime_type" :-1|0|1|2|3|4, "success_callback" : "xxxxxx" , "failure_callback" : "xxxxx" }&origin=xxx
 // Jump to h5 page
 page://act_web?params={ "page_name" : "xxxx" , "data" :{ "xxx" : "xxx" ,...}, "navi_type" :0|1, "anime_type" :-1|0|1|2|3|4, "success_callback" : "xxxxxx" , "failure_callback" : "xxxxx" }&origin=xxx

The APIs that Manager needs to provide include:

 // Jump to native page
 // Jump to h5 page

Service Request Protocol

 // @TODO can continue to split
 service://modulename/servicename?params={}&origin=xxx

Bridge Protocol

 // bridge is a specific scheme, bridgename is the api supported by the bridge js library
 bridge://bridgename?module=xxx&method=xxx&args=\{\}&origin=xxx