Mobile terminal routing layer design

What is the mobile routing layer?

The concept of routing layer on the server side refers to the hierarchical parsing of URL requests, which distributes a request to the corresponding application handler. The routing layer on the mobile side refers to the logical layer that distributes and processes access requests such as page access within the App, H5 and App access, and access requests between Apps.

Problems that need to be solved at the mobile routing layer:

1. Provides remote access to external applications and implements cross-application call responses, including H5 application calls, other App application calls, system access calls, etc.
2. Definitions of native pages, modules, components, etc. are collectively referred to as resources. Under the premise that cross-application calls and business performance implemented at different ends of the routing layer need to be consistent, resources need to be defined. When routing provides internal request distribution, it can provide functions that do not rely on external resource definitions.
3. How to use uniform identifiers to represent resources in external calls
4. How to uniformly define the access request process on the mobile side to achieve uniformity between the mobile side and the web side
5. How to better integrate iOS and Android's system access mechanisms, App link protocols, web-side routing mechanisms, and front-end development specifications?
6. How to be compatible with the App page navigation mechanism of various platforms (Android, iOS)
7. How to solve the security access problem
8. The mobile terminal is dynamically configured on the client
9. Scenarios where mobile routing is used:
10. Interaction between H5 pages and App native pages, modules and components
11. Mutual access between apps
12. App internal page jump, module scheduling and component loading, etc.
13. The push and notification system removes hard-coded logic, dynamically accesses native resources, and better supports dynamic page access and logic execution through notifications and push.
14. Extension and other dynamic calls to the main App's resources
15. App implements more complex architecture MVVM or VIPER architecture, providing the ability to eliminate business interdependence
16. Engineering transformation for componentization, isolating each business to create separate components

How to define resources externally

When routing provides external resource request forwarding, it is necessary to define resource definitions that are purely dependent on the business because it is necessary to take into account the request expression methods of other applications, such as access requests from H5 applications or other App applications.

For example, a H5 product details page is shared by a user. When other users see the page of this H5 application and click on it, if the user has installed the App corresponding to this H5 product details page, they should jump to the native product details page of the App. If not installed, the H5 page should be loaded. In this process, the H5 page is identified by a URL, and the URL should also be matched to the native page of the App. However, it should only rely on the business identifier and not the code implementation of the App. For example, the product details page of the App on the iOS side is called DetailViewController, and the URL cannot contain this name. The Android side may be called DetailActivity. If it does not rely solely on the business, the H5 application will resend different resource definition URLs according to the platform, which will cause hard coding problems. The H5 application must rely on the implementation logic of the App. If one day, the page code implementation of the native App becomes GoodDetailViewController, all H5 applications that rely on the resource identifier of DetailViewController will have to be changed, and problems will arise. Therefore, the design of the routing layer should be able to map the resource definition in the App according to the business definition.

Often when designing the routing layer, we focus more on the details of communication behavior and how to improve the performance of a specific communication mechanism, often overlooking the fact that changing the application's interaction style can have a greater impact on overall performance than changing the protocol.

The so-called resource is an inseparable service provided by an application. From this perspective, the resources of an App are entities that can be obtained and accessed. They must be well represented. In some necessary cases, they must be unique identifiers to represent the services provided by an application. We prefer to use URI to represent resources, because there is no resource representation method that spans iOS, Android, Web backends, and H5 applications on the mobile side. URI is a universal representation method for resources in the web service model, including the universal link (universal link) that Android and iOS will mention later. It also borrows the concept of URI. It is recommended to use URI to represent the resources involved in the App routing layer. At the same time, this layer should be structured in the RESTful style. The reason is that the pages, components, or a whole set of functional services of an App are very complex. Compared with H5, there are more and more complex interactions. Compared with the backend, there is a more demanding network environment and technical considerations of multiple devices and platforms. Therefore, when marking resources across multiple platforms and versions, URI can better represent a resource entity rather than the form of resource expression.

Both Android and iOS systems support URL Scheme, so resources are usually marked like this:

 AppScheme://path
 //For example, QQ app:
 mqq://
 //Alipay:
 Alipay:

If the protocol is Http or Https, it indicates a Web application or an H5 application, and your App is also an application of the same level as WebService, then the protocol part of the URL should be the unique identifier of the App, and the host and path parts require us to redesign them in a RESTful style.

The key point is how to mark resources. For example, to represent the login service in an App, it can be represented as:

 AppScheme://host/login

Host is the host part. In general WebService, it is usually the mark of a larger business line in terms of business performance. For example, in https://news.sina.com.cn, the host part is news.sina.com.cn, which marks the business line of Sina News. Your business line should also be clear in the App. If the main UI framework of the mobile App is a Tab column, then each Tab column is the division of your business line, which is similar to the navigation bar of the WebService application. App resources are mostly pages or interactive components, which are more related to the UI. If you have four Tabs: Home, Products, Discover, and Mine, then we can define them like this:

 AppScheme:// index /
 AppScheme://goods/
 AppScheme://discover/
 AppScheme:// user /

Of course, there can also be additional definitions. For example, if the App has an API service, and the API provides a service identifier for implementing pure data synchronization, then the URL can be designed as:

 AppScheme://api-asycn/collections? action = 'insert' &value= '***' &&userUoken= '*******' &&source= "https//***.***.com/collection.html"  

Since the RESTful style emphasizes URL resource identification rather than behavior representation, "AppScheme://api-asycn/collections" is a good resource identification, indicating an entity of a collection function. The GET method parameters after "?" are actually a last resort, because there is actually no entity of the Web http request. Therefore, we can only use GET parameters to replace the Accept and Content-Type fields emphasized in the RESTful style to indicate the behavior description of the presentation layer.

Of course, descriptions such as action and value can be divided according to business, but the key is to use parameter expression.

iOS and Android system access mechanism and unified link protocol

Apple's URL Scheme has a long history: Apple URLScheme, the Android platform also implements this function, allowing apps to call declared services from each other under the premise of a sandbox mechanism. Since URL Scheme does not have a return callback mechanism, the author of the famous App Drafts, Marco Arment, Justin Williams and others developed x-callback-URL to make a unified jump protocol: x-callback-url, which will not be described in detail here.

Using the URL-Scheme mechanism, the following unified link protocol can be defined:

1. The protocol part is used to mark the App application
2. The host part is used to mark the business line or the divided service entity provided by the application. For example, index and discover are business lines, api-asycn is the API provided to the outside world, and pushService is the push service within the App.
3. The path part can be the mark of the subdivided page, component or service
4. Some parameter definitions are necessary, such as action to mark the action, for example, you can use get to mark acquisition and insert to add, userToken to represent a secure user token, and source to represent the source. Of course, userToken and source are parameters that need to be parsed and verified by the routing layer, while action is a business-related parameter, which needs to be distinguished in detail when designing the routing.

Unified access request process

route flow chart.png

The entire unified access request process is shown in the figure. There are some explanations about the final response return:

In the WebService work stack, http request and response have standard protocol specifications, while the routing layer of the App only applies URI resource identification and RESTFul style interaction. There is no standard request and response structure. This part is implemented inside the App. The response has three important elements that the external calling system cares about: resource status code, return value and error. The routing layer needs to return these three elements when responding to external calls.

Routing layer logical structure

[[182243]]

App Route logical structure diagram.png

Routing layer security

The security of the routing layer includes two aspects:

1. When cross-application, you need to be careful about injection attacks and encrypt sensitive parameters to prevent tampering. At the same time, you need to pay attention to the routing layer should provide a mechanism to achieve risk control
2. When crossing business systems, it is necessary to enable the session access mechanism to implement routing layer authentication through tokens or session sessions.

Routing layer implementation

Please look forward to the next article: "Building iOS Routing Step by Step"

Extra: Discussion on App Islands, API Economy and App Openness

What is an App Island?

Apps in mobile operating systems generally use a sandbox mechanism to strictly limit access rights. Apps are not connected to each other. Users tend to install a large number of apps. For example, Dianping is used to find places to eat, WeChat is used to chat, and Amap is used for maps, etc. So let's imagine a world without URL Scheme. You find a good place to eat on Dianping, and then you need to switch to Amap to find out where it is, and then write down the address in your mind and send it to your friends on WeChat. In such a process, many apps cannot transmit information or collaborate with each other, and each app becomes an information island, which brings great inconvenience to users. Apps that implement URL Scheme are generally from large companies with over 100 million users, bringing convenience to hundreds of millions of people.

Breaking down app silos

In essence, URL Scheme is supported by the operating system. In other words, to break the App island, you must pass the operating system. Both third-party developers and Apple and Google are working hard to break the information island.

Apple and Google supported universal link in iOS9 and Android M respectively to break down the barriers between H5 applications and native applications.

Apple breaks down the information barriers between native applications in the iOS operating system through Spotlight in-app search, AppGroups, AppExtension, ShareExtension and SiriKit.

Google hopes to achieve unification by replacing native applications through PWA.

Third-party developers are also actively promoting this trend. For example, the author of the famous App Drafts mentioned above, together with Marco Arment, Justin Williams and others, developed x-callback-URL to create a unified redirection protocol: x-callback-url, hoping that most App developers can respond to the call and develop better.

Some domestic deep link developer platforms include DeepShare – Share your App with the world, the open source onestep of Hammer smartphone, etc.

As a developer, building a secure, efficient and open router not only meets the needs of the technical architecture, but also contributes to breaking the App silos and better developing the mobile ecosystem.

What is API Economy?

The API economy is the sum of economic activities generated by APIs. At the current stage of development, it mainly includes API business and commercial transactions in business functions, performance, etc. conducted through APIs. The API economy is the main force driving digital transformation in various industries today (retail, finance, Internet of Things, medical care, etc.). ———Baidu Encyclopedia

Why do we need to talk about API economy here? We all know that the first priority of economics is the principle of efficiency first. Just like the App island we talked about above, in the increasingly convenient mobile era, it actually reduces the efficiency of information sharing and increases the user's operating costs, which will hinder the activity of users on this platform, and the possibility of upper-level use of mobile platforms will be limited. For example, QR codes and NFC solve the problem of information sharing between POS terminals, merchants and payment apps, leading to a prosperous offline payment economy. In the same way, if the APIs between various systems, whether App, WebServices or other applications, can be opened, it will form a scale effect of information sharing on the platform or industry, and will form a healthy development.

As an App developer, you need to implement the routing layer to support calls across applications and to release the API you want to develop.

If the backend services of an App can open APIs together with the App, it will be more advantageous. For example, if WeChat opens the WebService API interface of collection and the WeChat App also opens the URLScheme collection interface, then users can seamlessly collect all content anytime and anywhere in the browser or on the mobile phone, which greatly facilitates users.

App Open Discussion

This session mainly discusses what to pay attention to when opening:

1. App type (determine whether to open)
2. Routing security (determines the degree of openness)
3. Opening time

It is not finished yet. I hope you can leave more comments and discuss it together.