Why not just open the H5 in the browser and jump to the app?

Apps can provide more services to H5 through JsBridge than browsers.

For example, the id of the device, SUCH as DID, to avoid repeated login and other functions.

Luckin’s app, for example, has a free first cup of coffee for newcomers. When the same phone, you change the number to register login, the activity will not work. This is the use of device ID to avoid unlimited prostitution. If only in the browser, you cannot get a device ID to identify the user.

URL Schema (ios+ Android)

Form: scheme: / / host/pathname? query

Snssdk143 (android)/SNssdk147 (ios) host: Is the location of the app, such as home /detail /webview. Pathname: is further subdivided in host. Query: can carry through parameters to indicate the source information

When the browser calls up app, set host to webView and Query to the URL of the page, and the specified H5 can be opened in the specified app.

Universal Link (ios9 and above)

Universal Link: Looks like a normal HTTPS Link.

On aN ios device, if the corresponding APP is installed in the phone, it can be directly activated. You can also place the corresponding H5 page in this link to guide the download.

Schema VS universal Link

Universal Link performs better when the app fails to be invoked. When schema is used, if the user does not install the corresponding app, the Android device will not respond, and the ios device will have a system error pop-up. With universalLink, however, if the call fails, it will automatically jump to the App Store and guide the user to download.

implementation

Href = schema/uviversal link

Now that ios is 14, we’re basically ignoring ios9 below. We believe that on Android there is schema and on ios there are schema+ Universal Link.

A tuning up

  1. In android, not directly to the current revision of the current window href, but create an iframe nodes, the nodes of the href is set to the corresponding link, and the visibility of the node set to hide, it won’t affect the visible change of the current page, and try to tune up the app (href if directly modify the current window, The current page has already jumped regardless of whether the call succeeds or not.

  2. In ios, you cannot create an IFrame node.

    const ifr = document.createElement('iframe');

    ifr.src = 'Call up a page's schema';

    ifr.style.display = 'none';

    document.body.appendChild(ifr);

    setTimeout(function(){

        document.body.removeChild(ifr);

    }, 3000);

Copy the code

Adjust the detection

The browser has no way of knowing if an app is installed locally, but it can sense if the app has been successfully invoked.

  1. One is through the browser property visibilityState, the current page is hidden when hidden, visible when visible.


window.setTimeout(function(){

    document.body.removeChild(ifr);

    if(document.visibilityState === 'visible') {

        window.location.href = 'Download link'

    }

},2000)

Copy the code
  1. It is inferred that the app is awakened by the feature “browser is cut into background, timer will be extended”.
const openTime = +new Date(a)

window.setTimeout(function(){

    document.body.removeChild(ifr);

    if((+new Date()) - openTime < 2500) {// However, the browser will delay after successfully setting up, and the time difference is greater than 2.5s. If the time difference is not greater than 2.5s, the browser will consider failure and enter failure processing. Here is the jump to download link

        window.location = 'Download link';

    }

},2000)

Copy the code
  • Why 2500ms, not 2001ms? Setting a timer for 2s does not necessarily mean that the method will be executed after 2s, but rather that the event that triggered the function will be attached to the end of the event queue after 2s, and that it will be executed only after the current stack is emptied + the function that preceded it. Therefore, even if the timer is not delayed, the time difference calculation may be greater than 2000ms, so relax to 2500ms

But in tests, the second method was unstable, with occasional millisecond delays on computers and almost none on phones. Is not available. So I chose the first option.

Default setting failed processing

  1. Set a time interval (such as three seconds) after initiating the app startup operation. If the visibilityState of the current page is hidden, it indicates that the startup is successful; otherwise, it indicates that the corresponding APP is not installed, and jump to the download link.

  2. However, the visibility of the page is not completely reliable across browsers. For example, in THE WEBview of QQ, the APP was successfully activated within 2s, but the visibilityState of the previous page appeared for more than ten seconds before it became hidden.

  3. In addition, when the APP is activated, the system will have a popup window, “Whether to open XXX”. Often, the timer has been triggered before the user clicks it.

    In other words, if the solution of “download the page without changing the browser visibility within 3s” is used, “the user installs the corresponding app and successfully initiates the call, but still jumps to the download page.”

Custom failure handling

Because of the above, you can customize a handle for a call-up failure. For example, a popup window is given to ask the user whether to jump to the corresponding download page, and the user can download it after confirming.

Host environment difference

The current host environment naturally does not want users to jump out, so some software with a large number of users have blocked this jump link. We tested the webviews of the top three browsers (UC Browser, QQ Browser and Baidu), QQ, wechat and Weibo respectively on ios and Android, and found that:

  1. In Android, wechat/Weibo cannot use schema to wake up apps
  2. In ios, wechat/QQ/QQ browser/Baidu cannot use schema to wake up app; Wechat/Weibo/UC browser cannot use Universal Link to wake up the APP.
  • How to distinguish the host environment? You can use navigator.userAgent to obtain the user’s operating system and browser type. For example, on ios, QQ browser ua: Mozilla/5.0 (iPhone; CPU iPhone OS 12_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, Like Gecko) Version/ 12.0mqqbrowser /10.5.1 Mobile/15E148 Safari/604.1 QBWebViewUA/2 QBWebViewType/1 WKType/1

Jump success rate detection

Dot the server before jumping, and pass through a unique identity through the URL. After jumping to the corresponding page, accept the logo and click again.

You can monitor whether each jump is successful.