Safariservices, and the new changes on iOS 9 WebKit

Sfsafariviewcontroller

The app can choose UIWebView and Wkwebview to showcase Web content. However, in some cases, the app wants to use a safari-like browser framework to open the Web page, and instead of rewriting the Address bar toolbar itself, then Sfsafariviewcontroller is the best choice, the effect

Sfsafariviewcontroller is a special Uiviewcontroller that allows you to present web content in the current app using Safari's UI framework, while enjoying some of the convenience features of Safari, including but not limited to:

• A similar user experience
• Share cookies with Safari
• Password, certificate AutoFill
• Safari Reader

The disadvantage is also obvious: Sfsafariviewcontroller is very poor customization, even the address bar is not editable, only at the time of init, a URL to specify the address of the page. Another custom feature is a method inside the sfsafariviewcontrollerdelegate:

-(nsarray<uiactivity *> *) Safariviewcontroller: (Sfsafariviewcontroller *) controller activityitemsforurl: ( Nsurl *) URL title: (Nullable NSString *) title;

You can pass in an array of uiactivity and add various plug-in services for Uiactivityviewcontroller (click the button in the middle of the bottom toolbar to trigger).

Off Topic:

Apple has spared no effort to secure Mobilesafari's web presence in iOS: only the iOS WebKit framework and WebKit JavaScript are allowed to browse Web content, but only a very inefficient, highly inflexible uiwebview is available, And a wkwebview with a high degree of openness but a ton of bugs. But Apple has always been dominated by "restrictions"; Starting with iOS 9, Apple began to value app– users – Web The relationship chain and opened up a lot of new interfaces for developers to use, Sfsafariviewcontroller is one of them.

app– User – Web What is most important in this relationship chain? User data. By Sfsafariviewcontroller, Apple has enabled apps to use the most private cookies and icloud Web form data, and the app-web relationship has been narrowed by user data, while the official web bearer remains safari-- That's what Apple wants to emphasize.

What do users care about? The user is ignoring those deep-seated stuff. Perfect function, convenient experience is the user's concern. Sfsafariviewcontroller is a small safari built into the app that aggressively boosts safari exposure and can even capture enemy camp users. On the other hand, Sfsafariviewcontroller removes the heavy sense of app jumping safari and reduces the fragmentation of apps and Safari.

In general, this is a multi-win outcome. It's possible that only third-party browsers are compromised--let the third-party browser help with the amount of safari, and joke about it. Also, assume that some users who are exposed to safari by Sfsafariviewcontroller may be able to move from a third-party browser camp to Safari's embrace. The Safari experience is really not blowing, especially when you have almost always had an Apple device on your hands. Anyway, I've already moved from Chrome to safari without burning paper.

Sfcontentblockermanager

There is only one interface in the current API documentation:

+ (void) Reloadcontentblockerwithidentifier: (NSString *) identifier Completionhandler: (void (^__nullable) (Nserror *__ Nullable error)) Completionhandler;

Content blocker, said to be a browser extension kind of thing, and the role of advertising filtering, the current function is unclear, more information can be seen here.

Webkit

Currently Wkwebview has a problem with iOS 9 and cannot be used to test new APIs, only by using the API name to guess its purpose.

Wkwebview

@property (nullable, nonatomic, copy) NSString *customuseragent ns_available (10_11, 9_0);

Custom Wkwebview UA.

-(Nullable wknavigation *) LoadData: (NSData *) data MIMEType: (NSString *) MIMEType characterencodingname: (NSString *) Characterencodingname BaseURL: (Nsurl *) BaseURL ns_available (10_11, 9_0);-(Nullable wknavigation *) Loadfileurl: (Nsurl *) URL Allowingreadaccesstourl: (Nsurl *) Readaccessurl ns_available (10_11, 9_0);

LoadData and Loadfileurl, these two pages loaded data interface finally came back to T^t.

Wkwebsitedatarecord, Wkwebsitedatastore

Can manipulate the data record of Wkwebview

Unlike UIWebView, which can only operate on cookies and Urlcache, the data types available from the API indicate that the records that can be manipulated include:

• Disk Cache
• Memory Cache
• WEBAPP Cache
• Cookies
• Session Storage
• Local Storage
• Websql
• Indexed DB

Covers all Web page data records, resolves the bug that Wkwebview operation Nshttpcookie and Nsurlcache are not valid on iOS 8, and is more advanced than UIWebView: You know UIWebView can't clear local How annoying storage is.

As there is no actual measurement of wkwebview, it is not yet known whether iOS 9 resolves other wkwebview bugs, such as Wkwebview's request without nsurlprotocol. If these fatal bugs are not resolved, Wkwebview is hard to install into a third-party browser, which can be seen for more detailed reasons.

Safariservices, and the new changes on iOS 9 WebKit