On the necessity of Pagelink

The original text is also published in the old yard of the personal blog, Welcome to visit: http://www.koulianbing.com/?p=9

In general, the pagelink mechanism within the app has several notable advantages worth doing: for example, to increase operational flexibility, page openness, benefit tracking, decoupling between modules, and reducing dependency between sub-projects.

Clients always have a few core business to undertake the page, is to give users to show the home of information, but also operational activities, message push user to undertake the page. such as Weibo's personal homepage, hand-picked goods/store details, the public account homepage, etc. Usually we open them up to operations, even three-party applications. At this time, it was Pagelink's turn to play. The page positioning is URI-normalized, and the URI's distribution center accepts the URI and opens the target page. Operation students in the new activities, you can configure the active page by URI, flexible control of the jump path.

In addition, we can give each jump a unique ID, tracking the effects of each operation, such as click, conversion rate, etc. Data of the entire activity.

The page URI normalization, but also the technology in the development of the jump between the page decoupling. Because only the input parameters are simplified and standardized, the query in the URI can be entered to provide the required key parameters.

Pagelink in the process of use, we can also expand, on the basis of the jump page to further enhance the execution action. For example, play a page sound, trigger a network request, call, etc. All action is represented by the Schema://host/action?querykey=queryvalue form. Decoupling the modules and services in the software, dividing the boundaries and finally organizing the interactions by action.

As our projects get bigger and larger, and as people become more involved, it's inevitable to split up into different sub-projects, where direct code references between different business teams can be painful, and the costs of internal friction and communication will go up in a straight line. Can you imagine a team of people accidentally modifying a method that causes everyone to compile and then each squalling in the development group?

Here are two things to realize in detail.

One is the number of actions as the app's version continues to grow, this needs to be versioned, as well as forward/back compatibility, to avoid any stability issues.

In addition, in the definition of Querykey and QueryValue, it is best to use a literal character to express, to do see explanatory, do not put the index values in the program to use. Suppose we define a URI in AppStore and want the program to jump to the detail page and navigate to the second called "Comment" tab, then query is best defined as subtab=comment, so it's easy to understand the wording. If you are a user, you do not want the developer to define this: subtab=2 (for the Second tab), so that the user does not name so, on the other hand, when the information structure of the page is refactored, such as "comments" in a new version of the 3rd tab, You can imagine how painful it would be to write code.

On the necessity of Pagelink