On the Necessity of PAGELINK and the necessity of PAGELINK

On the Necessity of PAGELINK and the necessity of PAGELINK

At the same time published in the old Code agricultural personal blog, welcome to visit: http://www.koulianbing.com /? P = 9

Generally, the PageLink mechanism in the App has several notable advantages: for example, increasing operation flexibility and page openness, facilitating effect tracking and decoupling between reverse push modules, reduce dependencies between sub-projects.

The Client Always has several core business acceptance pages, which are the home site for displaying information to users and the user acceptance pages for operation activities and message pushing. Such as the personal homepage of Weibo, the product/store details of shoutao, and the public account homepage. We usually open them to operations, or even third-party applications. At this time, it was PageLink's turn to play. Normalize the page positioning by URI. The URI distribution center accepts the URI and opens the target page. When launching new activities, operators can use URIs to configure the event acceptance page to flexibly control the jump path.

In addition, we can also assign a unique ID for each jump to track the effect of each operation activity horizontally, such as click and conversion rate. Digitize the entire activity.

While standardizing the page URI, the technology also decouples the jump between pages during development. Only when the input parameters are simplified and standardized can the Query in the URI be used as the input and provide the required key parameters.

During the use of PageLink, we can also extend it to execute the Action on the basis of page Jump. For example, play the page sound, trigger network requests, and call. All actions are composed of schema: // host/Action? QueryKey = queryValue. Decouples modules and services in the software, draws a line, and finally organizes actions to form interactions.

As our projects become larger and larger, there are more and more participants and it is inevitable to split them into different sub-projects. At this time, it is very painful to directly reference code between different business teams, both internal consumption and communication costs will go up. Can you imagine that a team of people accidentally modified a method, so that everyone could not compile it, and then every one was in the Development Group?

Here are two implementation details.

One is that the number of actions increases with the number of App versions. This requires version management and forward/backward compatibility to avoid stability issues.

In addition, in the definition of queryKey and queryValue, it is best to use literal characters for representation. To see the meaning of the document, do not use the index value in the program. Suppose we define a URI in the AppStore to indicate that we want the program to jump to the details page and locate the second "comment" Tab, we recommend that you define the query as subTab = comment, this is easy to understand. If you are a user, you do not want the developer to define it as follows: subTab = 2 (indicating the second Tab). In this way, the user is not named, and on the other hand, when the page information structure is restructured, for example, "comment" is changed to 3rd tabs in a new version, you can certainly imagine how painful it would be to write code.