IOS Wkwebview Web Development Adaptation Guide

IOS Wkwebview Web Development adaptation Guide

iOS clients will gradually upgrade to the Wkwebview kernel by March 1, 2017, requiring web developers to check and adapt the site in advance. If you have any questions, you can consult us at the end of the article.

background

Wkwebview is a new component introduced by Apple in iOS 8 to provide a modern web browsing control that supports the latest WebKit features, getting rid of the old, old, and dumb, especially the memory-intensive problems of the past UIWebView. It uses the same nitro JavaScript engine as Safari, greatly improving the speed of page JS execution.

Switching Methods

The iOS6.5.3 version began to enable developers to manually switch between Wkwebview and UIWebView, enabling developers to adapt Wkwebview in advance.

To manually switch the entry:

On the Session list page, click the "plus button" in the top right corner, select "Add Friends" in the menu, enter the string in the search box to add a friend interface: ": Switchweb", then click the Search button in the lower right corner of the keyboard. After successful switchover, you will be prompted that the kernel you are currently using is UIWebView or Wkwebview.

Check Switching method:

After you successfully switch to Wkwebview through a command, you can verify that the current Web page is using the Wkwebview kernel in the following ways.

Any entrance into any Web page, after the page loaded successfully pull the page down (or click on the top right corner of the page menu button) to display the address bar, when the address bar with "This page from" is the current use of Wkwebview, if "page by" is the use of UIWebView.

How the page determines which WebView kernel is currently in use:

The WebView kernel currently in use can be judged by the injected Window.__wxjs_is_wkwebview variable in the page. iOS6.5.3 and its subsequent version Window.__wxjs_is_wkwebview true are UIWebView when using Wkwebview, false or "undefine".

Front-end adaptation focus points

The first principle of adaptation: if it is not possible to differentiate between new features of Wkwebview or internal logic that causes problems with existing pages, test pages can be tested separately in Safari and in the Wkwebview kernel to quickly locate the cause of the problem.

Adaptation Guide

After switching to Wkwebview, the webview behavior in the safari remains high consistent with the only difference being that Jsbridge related scripts are injected into WebView. So the focus of adaptation needs to focus on the following areas:

One: the page function is normal

Two: Page screen adaptation is normal three: the page behavior is normal (such as when the user click the Back button when browsing the page to return to the previous page logic is normal)

IV: Whether the syntax used by the page is compatible.

V: Jssapi is normal and perfect work.

Six: Focus on whether the logic related to cookies and localstorage is normal.

Seven: If the server has a set return Cache-control cache validity time, you need to check whether the relevant logic is normal.

Under normal circumstances, your page does not need to do a special adaptation, but if your page involves the following several affected logic, you need to adapt and confirm according to the adaptation recommendations.

JSAPI related adaptation

One: Cache will no longer be supported

Change: Cache Jsapi will not be supported in Wkwebview.

Adaptation recommendations: All developers using this API can remove page-related logic.

Two: Page preview image via Localid

Change: 1.2.0 The following versions of JSSDK no longer support previewing a picture by using the LOCALLD returned with the Chooseimage API as an "IMG src=wxlocalresource://50114659201332".

Fit recommendations: Upgrade JSSDK directly to the latest version of 1.2.0 to help you automatically adapt the page. (currently JSSDK online version is 1.0.0 and 1.1.0, newer version is 1.2.0, https://res.wx.qq.com/open/js/jweixin-1.2.0.js)

Three: There is the use of JSSDK, and the use of Wx.config for permission to pay attention to the failure of Jsapi call

Change: Wkwebview internal implementation of the changes in our domestic page JSAPI Rights Management has made a certain logical adjustment, there is a very small likelihood that the previously authorized normal JSAPI Get permissions are not normal, resulting in the call Jsapi failed.

Recommendations for adaptation:

1. Ios6.5.1,wkwebview is known to have the following issues in this release: The page uses HTML5 's history API pushstate;      Popstate; Replacestate such as Control page navigation (typically such as a single application page), while using JSSDK wx.config for JSAPI authorization, this time there will be a large probability jsapi because of the failure to invoke the problem. In 6.5.1, if possible, you can use the Anchor hash technique to replace the history technique to resolve this issue.

2. iOS6.5.2 and later versions, will not have the above problems, but not 100% to confirm the use of the history or hash technology to change the page navigation address of the page does not have such a problem, still need developers to pay attention to such issues.

Cookie and Localstorage settings related

A: After exiting the account, all cookies and localstorage will be emptied.

Second: The page function relies on cookies, or has related logic that involves cookies
Wkwebview internal implementation changes will affect the current page cookie-related logic.

Change 1: Cross-domain Access cookie
Issue Description: When you access a page A, if page a references another resource for page B (pages A and B are different domains), then page B is considered a third-party page. If you set a cookie in page B, you will hit the security policy that prevents third-party cross-domain settings cookies from Wkwebview, causing the problem to occur.
Recommendations for adaptation:
In Wkwebview, the third-party settings cookie is blocked by default across domains. All the information passed through the cookie can be stored through the business background, and then the Access_token plus password corresponding to the page is stored, and then the information between pages is passed through the access_token of the URL.

Change 2: The native level of the network request does not read the cookie set in Wkwebview, even if the domain name is the same.
Problem Description: If the page's resource or picture store server relies on a checksum cookie to return the data, after switching to Wkwebview, the Web request originating at the native level will not be set to the full extent of the cookie when the internal-long press is saved, or when you click the Preview large image. Causes the picture to be saved or failed to preview.
Recommendations for adaptation:
Static resource cookie free is recommended. If there is information that needs to be passed, the information that needs to be passed through the business background can be stored, and then the Access_token plus password corresponding to the page is stored, and then the information is passed through the access_token of the URL in which the business is added.

In addition to these two cases, developers do not have to worry about the loss of cookies in other cases, all requests will bring a full cookie.

Page Video Small window playback

Change: In iOS6.5.3 and later versions, WebView supports small window playback by default.

Developers need to pay special attention to small window playback requires a front-end adaptation of iOS10 and iOS10 below the lower version

Fit recommendations: You need to set the video tag exactly as follows to be compatible with different iOS versions

<video Webkit-playsinline playsinline> </video>

Wkwebview page behavior is exactly the same as safari, which causes the page to rely on logical invalidation or exception of UIWebView page behavior: (can be verified in Safari and Wkwebview based on the business logic, respectively, after the test page is implemented)

One: Safari or Wkwebview does not re-execute script and Ajax (and does not trigger page reload) after page a jumps to page B and then returns to page A.

Two: In Safari or Wkwebview, the Resize event of jquery will be triggered when the page pops into the keyboard, but not in UIWebView.

Three: In Safari or Wkwebview, the window unload event can only be triggered by a refresh, exit the page, or jump to another page.

Four: In Safari or Wkwebview, in rare cases, some specially implemented page click events are invalidated.

If any of the above issues are involved or encountered, the compatibility with Safari will prevail.

Other questions

One: When a page custom overloads a standard method or function, you need to ensure that there is no conflict with the Jsbridge-related methods in the injected WebView, otherwise it will cause the page to behave abnormally.

Second: It is strongly recommended that you do not set HTML pagefile (except HTML-type pages, other resources or scripts referenced by the page as appropriate for your business) without ensuring that the page cache policy and logic are fully consistent with the server logic. Cache-control properties.

Typical cases:

If the first access page a.html server 302 jumps to a1.html?uid=111 settings cache-control:max-age=60, this a1.html uid parameter is 111 of the server setting (A1.html has been cached by the client at this time). The second visit page a.html, the server also 302 jumps to a1.html?uid=222, but at this time the UID parameter of the a1.html page is 222, the client with parameter full link to ask the server cache is available, the server returns cache 304 available, However, the client-side cache of the a1.html full link with the UID parameter is 111, so the data is not found locally, loading the page will fail.

Contact Us

If you have any problems with the adaptation process, you can send an email to [email protected]. Please provide a detailed description of the problem, it is strongly recommended to attach a link to the question page and tell how to reproduce your question.

IOS Wkwebview Web Development Adaptation Guide