background

Recently, I am working on a project related to community interaction, mainly on the client side and supplemented by the web side. There is an important business requirement for intra-app sharing elsewhere.

The main process of this scheme is as follows: The APP is shared to a third party app, the third party can directly open the web page, and the interactive operation of the web page is diverted back to its own APP.

  1. The first step is easy to achieve by sharing app to third-party applications. At present, there are many ready-made implementation schemes on the market, including third-party application providers directly provide complete SDK call schemes, which can be configured directly when we develop ourselves.
  2. The second step is actually very simple, that is, our web front-end developed pages, the APP side to share the time to generate a web address, the third-party APP directly open the web page;
  3. The third step is the most troublesome. The main problem is the limitation of third-party applications mentioned in the introduction, which is also the main purpose of this article.

Web pages wake up APP. The carrier is web pages, and what is aroused is APP. Normally, we only need to connect the protocol of APP. That means that under normal circumstances, web front-end developers only need to docking the Android and iOS two ecological environment of the agreement, that is to say, two sets of solutions.

In fact, most browsers and apps have their own set of specifications because of security restrictions on the web side. For example, although wechat can open web pages, most of the web protocols are banned by wechat, and the original solutions in the browser are prohibited to be re-developed in wechat ecology. It is very complicated from account application, permission opening, label development and so on.

At present, we can think of Android, ios, wechat, QQ and Weibo, each of which has its own closed environment and needs independent development.

Original plan

First of all, let’s mention the native program. Native means the program supported by the browser itself. Safari, Chrome, Xiaomi browser, Sogou browser and other common browsers on the market are basically supported.

URL scheme

Just as each website has its own independent URL, we can also define an independent prefix for each app and use a unique identifier to locate the APP, which is the URL scheme.

For example, weixin:// points to the wechat app. When we visit this address in the browser, the wechat app will be invoked, and we can carry parameters.

Some function (application) | scheme: / / [path]? [query] | | need application identification function parametersCopy the code

This is the complete structure of a URL scheme.

Of course, direct input in the web page is not open, because the browser will recognize it as a string of characters, can be triggered by JS, in the page running window.open(‘weixin://’) can jump to wechat

Intent

Google official syntax, android platform only, structure as follows.

intent:
   HOST/URI-path // Optional host 
   #Intent; 
      package=[string]; 
      action=[string]; 
      category=[string]; 
      component=[string]; 
      scheme=[string]; 
   end;
Copy the code

This is a rare scenario, and the final format is to generate a string of URL addresses, which, like above, essentially accesses the address and invokes the app.

Compared with URL scheme, its biggest advantage is that it provides the jump URL address of wake up failure, for example, when the user has not installed the software, we can jump to the store download page.

Universal Link

Universal Link is a new feature released by apple in WWDC2015 and is not supported until iOS9. It opens the APP via a traditional HTTP link.

Universal Link is a very good solution. When using it, we just need the ios client to generate a JSON file, write the configuration items in it, and then the server to put it under our domain name, and then when we visit the website, we can automatically wake up the app. We don’t need to do any extra operations, and the experience is great.

Similar to the Intent provided by Android, the user is also redirected to the App Store details page if the Intent is not installed.

The disadvantage is that it only supports the ios native browser, and it is also limited to use in wechat and other software.

Third-party Solutions

Third party ecosystems are closed, so we have to develop extra

WeChat

For the configuration required to get started, please refer to the previous article I posted

Wechat wake up app itself is quite simple. After configuring the environment, we just need to introduce the wX-open-launch-app tag. The code is as follows.

<wx-open-launch-app id="launch-btn" appid="your-appid" extinfo="your-extinfo" > <script type="text/wxtag-template"> <style>.btn { padding: </style> <button class=" BTN "> </script> </wx-open-launch-app> <script> var BTN = document.getElementById('launch-btn'); btn.addEventListener('launch', function (e) { console.log('success'); }); btn.addEventListener('error', function (e) { console.log('fail', e.detail); }); </script>Copy the code

The document looks quite simple. When you use it, you just need to wrap a layer of wechat open label on the wake button according to the document.

It’s really complicated to use. For example

  • The requirement is that all interactive buttons on the webpage need to wake up the APP after clicking, so does that mean that all interactive buttons need to encapsulate a layer of wechat components?
  • Encapsulation is fine, but we also have native browsers, other environments, and if we do this for each environment, or if we do this once, will the code get really messy?
  • And many projects are completed development, later need to be connected to wechat to share, can not let the developers one by one to change the label, reconstruction of the project?

At the beginning of the project development, I reserved a JS event, and the most ideal thing is to invoke it by function, but after a long time of research, I found it impossible, so I must have an alternative plan.

At present, the planned scheme is that after the user clicks the interactive label, a modal box will be set up through the embedded unified event. We only need to write the wechat call label in the modal box once, and put all the logic in one place, so that it can be directly reused even if other environments such as QQ are connected later. After weighing the compromises, it is necessary to choose the most reasonable plan.

Extended information

1. Wechat open label

2. APP function of webpage hopping within wechat