This is my original, reproduced please indicate the source: juejin.cn/post/703216…
purpose
As the project develops, the calls between functions become more and more complex
Here is an example of the logic of buying goods
From the diagram, the problem is that there are many jumps between services, and they are messy. There is also when jumping the same page, jump to take the same parameters, how to ensure? If the code is scattered across the business hopping will inevitably be maintained everywhere.
That’s where routing comes in.
In addition, there is another advantage of good routing, which is the back end or front end. They uniformly handle the jump according to the routing protocol, so the APP can not consider the jump between services.
Here is a jump diagram with a routing module.
That’s clear.
From the diagram, routing, he is mainly responsible for the business jump, jump from one page to another page and so on.
The idea of realization
In order to jump, you need to know the way. So in a sense, routing needs to know where you want to jump to, and what input parameters you need to go to.
So you have to have a key, a map to a ViewController, and then whatever input the ViewController needs, it brings in.
A common approach in the industry to solve this key problem is to have a routing table
- For example, to maintain a PList file, maintain the corresponding key-mapping controller in the PList during development, and load it into the memory once during operation. Then when the route wants to jump, it just needs to look up the table to jump.
- Or at runtime through business registration, each business registers the key to the route, maintaining a routing table in memory.
You can do it either way. So it looks something like this.
| key | value |
|---|---|
| to_home_page | HomeViewController |
| to_buy_page | BuyViewController |
| . | . |
He has to solve three types of jump logic
- Through back-end delivery, the App can open a native or Web page directly
- Push messages, for example, can be clicked to take you to a native or Web page
- For example, an item card is returned from the back end, and clicking on the item takes you to a native or Web page
- For example, on an active page, click a button to go to a native or Web page
- For example, a button on a native page that you click to go to a native or Web page
There are only two kinds,
- One is called remotely,
- One is internal app calls.
The so-called remote call is the jump ability provided by app, allowing calls outside. Furthermore, it can be opened and called by other apps, such as wechat sharing and payment. The relative internal call is the jump from page A to page B within the APP.
Therefore, for the above uses, naming can be distinguished, such as internal call with native:// as the beginning, indicating internal call. External to add weixinapp:// (with the app name is easier to understand the caller), or not, after all, can be directly compatible with www.baidu.com such a web page
The reason for clear distinction is that routes can be used for unified permission management. For example, external calls can be opened directly with one check, and internal calls can be opened with another check. In particular, you need to control the permissions of internal calls to ensure that they are really your own APP calls so that no one can open your internal page just using URL Schemes.
Thinking of this, is it possible to add a variety of prefixes? The answer is definitely yes, depending on the business of different companies. I’m just going to add two. As follows:
| key | value |
|---|---|
| native://to_home_page | HomeViewController |
| native://to_buy_page | BuyViewController |
| http | WebViewController |
| https | WebViewController |
| . | . |
It says,
- When the key is native://to_home_page, go to the home page and open the HomeViewController page.
- When the key is HTTP. I’m going to go to the page, and I’m going to turn on the WebViewController page rendering.
Seeing this, the definition of the route comes out. Unified entry and transfer, such as:
XXRouter.push(jumpParams: [:])
Then call the above routing table as follows:
XXRouter.push(jumpParams: ["to":"native://to_home_page"]) // Go to the home page
XXRouter.push(jumpParams: ["to":"http://www.baidu.com"]) // Open the page
XXRouter.push(jumpParams: ["to":"https://www.baidu.com"]) // Open the page
Copy the codeIf you want to pass parameters, that’s it.
XXRouter.push(jumpParams: ["to":"native://to_home_page"."name": "Name"])
XXRouter.push(jumpParams: ["to":"http://www.baidu.com&a=1&b=2"."name": "Name"])
XXRouter.push(jumpParams: ["to":"https://www.baidu.com&c=3&d=4"."name": "Name"])
Copy the codeFinally, we have the definition of the last route.
In the next part, we’ll look at a routing implementation. Swift Routing component (2) Implementation of routing