Webansichten in Xamarin.iOS

  • Artikel

Im Laufe der Lebensdauer von iOS hat Apple eine Reihe von Möglichkeiten veröffentlicht, wie App-Entwickler Webansichtsfunktionen in ihre Apps integrieren können. Die meisten Benutzer nutzen den integrierten Safari-Webbrowser auf ihrem iOS-Gerät und erwarten daher, dass die Webansichtsfunktionalität anderer Apps mit dieser Erfahrung konsistent ist. Sie erwarten, dass dieselben Gesten funktionieren, die Leistung gleich ist und die Funktionalität identisch ist.

iOS 11 hat neue Änderungen an beiden WKWebView und SFSafariViewController. Weitere Informationen zu diesen Informationen finden Sie im Leitfaden zu Webänderungen in iOS 11.

WKWebView

WKWebView wurde in iOS 8 eingeführt, sodass App-Entwickler eine Webbrowsenschnittstelle implementieren können, die der mobilen Safari ähnelt. Dies ist teilweise darauf zurückzuführen, dass das WKWebView Nitro Javascript-Modul verwendet wird, dasselbe Modul, das von mobilen Safari verwendet wird. WKWebView sollte immer über UIWebView verwendet werden, sofern möglich aufgrund der erhöhten Leistung, der integrierten benutzerfreundlichen Gesten und der Einfachen Interaktion zwischen der Webseite und Ihrer App.

WKWebView kann Ihrer App nahezu identisch mit UIWebView hinzugefügt werden, da der Entwickler jedoch viel mehr Kontrolle über die UI/UX und Die Funktionalität hat. Beim Erstellen und Anzeigen des Webansichtsobjekts wird die angeforderte Seite angezeigt. Sie können jedoch steuern, wie die Ansicht dargestellt wird, wie der Benutzer navigieren kann und wie der Benutzer die Ansicht verlässt.

Der folgende Code kann verwendet werden, um eine WKWebView in Ihrer Xamarin.iOS-App zu starten:

WKWebView webView = new WKWebView(View.Frame, new WKWebViewConfiguration());
View.AddSubview(webView);

var url = new NSUrl("https://learn.microsoft.com");
var request = new NSUrlRequest(url);
webView.LoadRequest(request);

Es ist wichtig zu beachten, dass WKWebView sich der WebKit Namespace befindet, daher müssen Sie diese using-Direktive am Anfang Ihrer Klasse hinzufügen.

WKWebView kann auch in Xamarin.Mac-Apps verwendet werden, und Sie sollten es verwenden, wenn Sie eine plattformübergreifende Mac/iOS-App erstellen.

Das Rezept "JavaScript-Benachrichtigungen behandeln" enthält auch Informationen zur Verwendung von WKWebView mit Javascript.

SFSafariViewController

SFSafariViewController ist die neueste Möglichkeit, Webinhalte aus Ihrer App bereitzustellen und in iOS 9 und höher verfügbar. Anders als UIWebView oder WKWebView, SFSafariViewController ist ein Ansichtscontroller und kann daher nicht mit anderen Ansichten verwendet werden. Sie sollten als neuer Ansichtscontroller auf die gleiche Weise wie SFSafariViewController jeden Ansichtscontroller präsentieren.

SFSafariViewController ist im Wesentlichen eine Mini-Safari, die in Ihre App eingebettet werden kann. Wie WKWebView verwendet es dasselbe Nitro Javascript Engine, bietet aber auch eine Reihe zusätzlicher Safari-Features wie AutoFill, Reader und die Möglichkeit, Cookies und Daten mit mobilen Safari freizugeben. Die Interaktion zwischen dem Benutzer und dem SFSafariViewController Benutzer ist für Ihre App nicht zugänglich. Ihre App hat keinen Zugriff auf die standardmäßigen Safari-Features.

Außerdem wird standardmäßig eine Schaltfläche "Fertig " implementiert, sodass Benutzer ganz einfach zu Ihrer App zurückkehren können, sowie Vorwärts- und Zurück-Navigationsschaltflächen, sodass Der Benutzer durch einen Stapel von Webseiten navigieren kann. Darüber hinaus stellt sie dem Benutzer eine Adressleiste zur Verfügung, die ihm die Ruhe gibt, dass sie sich auf der erwarteten Webseite befinden. Die Adressleiste lässt es dem Benutzer nicht zu, die URL zu ändern.

Diese Implementierungen können nicht geändert werden, daher SFSafariViewController ist es ideal, als Standardbrowser zu verwenden, wenn Ihre App eine Webseite ohne Anpassung präsentieren möchte.

Der folgende Code kann verwendet werden, um eine SFSafariViewController in Ihrer Xamarin.iOS-App zu starten:

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

Dadurch wird die folgende Webansicht erzeugt:

Beispielwebansicht mit SFSafariViewController

Safari

Es ist auch möglich, die mobile Safari-App in Ihrer App zu öffnen, indem Sie den folgenden Code verwenden:

var url = new NSUrl("https://learn.microsoft.com");

UIApplication.SharedApplication.OpenUrl(url);

Dadurch wird die folgende Webansicht erzeugt:

Eine Webseite, die in Safari präsentiert wird

Das Navigieren von Benutzern von Ihrer App zu Safari sollte in der Regel immer vermieden werden. Die meisten Benutzer erwarten keine Navigation außerhalb Ihrer Anwendung. Wenn Sie also von Ihrer App weg navigieren, geben Benutzer sie möglicherweise niemals zurück, was im Wesentlichen das Töten des Engagements bedeutet.

iOS 9-Verbesserungen ermöglichen es dem Benutzer, über eine Zurück-Schaltfläche, die in der oberen linken Ecke der Safari-Seite bereitgestellt wird, auf einfache Weise zu Ihrer App zurückzukehren.

App-Transportsicherheit

App Transport Security oder ATS wurde von Apple in iOS 9 eingeführt, um sicherzustellen, dass alle Internetkommunikation bewährten Methoden für sichere Verbindungen entsprechen.

Weitere Informationen zu ATS, einschließlich der Implementierung in Ihrer App, finden Sie im App Transport Security-Handbuch .

UIWebView-Veraltung

UIWebView ist apples Legacy-Methode, Webinhalte in Ihrer App bereitzustellen. Es wurde in iOS 2.0 veröffentlicht und ist ab 8.0 veraltet.

Wichtig

UIWebView ist veraltet. Neue Apps, die dieses Steuerelement verwenden, werden ab April 2020 nicht im App Store akzeptiert, und Apps-Updates, die dieses Steuerelement verwenden, werden bis Dezember 2020 nicht akzeptiert.

Die Apple-Dokumentation UIWebView schlägt vor, dass Apps stattdessen verwendet WKWebView werden sollten.

Wenn Sie Xamarin.Forms verwenden und nach Ressourcen zur UIWebView-Veraltungswarnung (ITMS-90809) suchen, finden Sie weitere Informationen in der Dokumentation zu Xamarin.Forms-WebView.

Entwickler, die in den letzten sechs Monaten (oder so) iOS-Anwendungen eingereicht haben, haben möglicherweise eine Warnung aus dem App Store erhalten, dass UIWebView sie veraltet ist.

Veraltete APIs sind häufig vorhanden. Xamarin.iOS verwendet benutzerdefinierte Attribute, um diese APIs zu signalisieren (und nach Verfügbarkeit Ersatz vorzuschlagen) an die Entwickler zurück. Was dieses Mal anders ist und viel weniger häufig ist, ist, dass die Deprecation zur Übermittlungszeit vom Apple App Store erzwungen wird.

Leider ist das Entfernen des UIWebView Typs Xamarin.iOS.dll eine binäre Unterbrechungsänderung. Diese Änderung unterbricht vorhandene Drittanbieterbibliotheken, einschließlich einiger, die möglicherweise nicht unterstützt oder sogar erneut kompiliert werden können (z. B. geschlossene Quelle). Dies führt nur zu zusätzlichen Problemen für Entwickler. Daher entfernen wir den Typ noch nicht.

Ab Xamarin.iOS 13.16 stehen neue Erkennungs- und Tools zur Verfügung, die Ihnen bei der Migration helfenUIWebView.

Erkennung

Wenn Sie kürzlich eine iOS-Anwendung an den Apple App Store übermittelt haben, fragen Sie sich vielleicht, ob diese Situation für Ihre Anwendung(en) gilt.

Um herauszufinden, können Sie die zusätzlichen Mtouch-Argumente Ihres Projekts hinzufügen--warn-on-type-ref=UIKit.UIWebView. Dadurch wird jeder Verweis auf die veraltete UIWebView Anwendung (und alle zugehörigen Abhängigkeiten) gewarnt. Verschiedene Warnungen werden verwendet, um Typen vor und nach der Ausführung des verwalteten Linkers zu melden.

Die Warnungen, wie andere, können mithilfe von -warnaserror:Fehlern in Fehler umgewandelt werden. Dies kann hilfreich sein, wenn Sie sicherstellen möchten, dass nach ihren Überprüfungen keine neue Abhängigkeit UIWebView hinzugefügt wird. Zum Beispiel:

  • -warnaserror:1502 meldet Fehler, wenn Verweise in vorab verknüpften Assemblys gefunden werden.
  • -warnaserror:1503 meldet Fehler, wenn verweise in nachverknüpften Assemblys gefunden werden.

Sie können die Warnungen auch stillen, wenn entweder die Ergebnisse vor/nach dem Verknüpfen nicht hilfreich sind. Zum Beispiel:

  • -nowarn:1502 meldet keine Warnungen, wenn Verweise in vorab verknüpften Assemblys gefunden werden.
  • -nowarn:1503 meldet keine Warnungen, wenn Verweise in nachverknüpften Assemblys gefunden werden.

Entfernen

Jede Anwendung ist einzigartig. Das UIWebView Entfernen aus Ihrer Anwendung kann abhängig davon, wie und wo sie verwendet wird, unterschiedliche Schritte erfordern. Die häufigsten Szenarien sind wie folgt:

  • Es gibt keine Verwendung UIWebView innerhalb Ihrer Anwendung. Alles ist in Ordnung. Beim Übermitteln an den AppStore sollten keine Warnungen vorhanden sein. Nichts anderes ist von Ihnen erforderlich.
  • Direkte Nutzung UIWebView durch Ihre Anwendung. Entfernen Sie zunächst Die Verwendung von UIWebView, z. B. ersetzen Sie sie durch die neueren WKWebView Typen (iOS 8) oder SFSafariViewController (iOS 9). Sobald dies abgeschlossen ist, sollte der verwaltete Linker keinen Verweis UIWebView darauf sehen, und die endgültige App-Binärdatei hat keine Ablaufverfolgung davon.
  • Indirekte Nutzung. UIWebView kann in einigen Drittanbieterbibliotheken vorhanden sein, entweder verwaltet oder systemeigene Bibliotheken, die von Ihrer Anwendung verwendet werden. Beginnen Sie, indem Sie Ihre externen Abhängigkeiten auf ihre neuesten Versionen aktualisieren, da diese Situation möglicherweise bereits in einer neueren Version gelöst wurde. Wenden Sie sich andernfalls an den Standard tainer(n) der Bibliotheken, und fragen Sie nach ihren Updateplänen.

Alternativ können Sie die folgenden Ansätze ausprobieren:

  1. Wenn Sie Xamarin.Forms verwenden, lesen Sie diesen Blogbeitrag.
  2. Aktivieren Sie den verwalteten Linker (für das gesamte Projekt oder zumindest für die Abhängigkeit mithilfe UIWebView), sodass er möglicherweise entfernt wird, wenn nicht darauf verwiesen wird. Dadurch wird das Problem gelöst, aber möglicherweise zusätzliche Arbeit erforderlich sein, um Ihren Codelinker sicher zu machen.
  3. Wenn Sie die Einstellungen für verwaltete Linker nicht ändern können, lesen Sie die unten aufgeführten Sonderfälle.

Anwendungen können den Linker nicht verwenden (oder seine Einstellungen ändern)

Wenn Sie aus irgendeinem Grund nicht den verwalteten Linker verwenden (z. B. nicht verknüpfen), wird das UIWebView Symbol in der binären App, die Sie an Apple übermitteln, erneut Standard und möglicherweise abgelehnt.

Eine erzwungene Lösung besteht darin, den zusätzlichen Mtouch-Argumenten Ihres Projekts hinzuzufügen--optimize=force-rejected-types-removal. Dadurch werden Ablaufverfolgungen UIWebView aus der Anwendung entfernt. Jeder Code, der auf den Typ verweist, funktioniert jedoch nicht ordnungsgemäß (Ausnahmen oder Abstürze erwarten). Dieser Ansatz sollte nur verwendet werden, wenn Sie sicher sind, dass der Code zur Laufzeit nicht erreichbar ist (auch wenn er durch statische Analysen erreichbar war).

Unterstützung für iOS 7.x (oder früher)

UIWebView ist seit v2.0 Teil von iOS. Die häufigsten Ersetzungen sind WKWebView (iOS 8) und SFSafariViewController (iOS 9). Wenn Ihre Anwendung weiterhin ältere iOS-Versionen unterstützt, sollten Sie die folgenden Optionen berücksichtigen:

  • Legen Sie iOS 8 als Mindestzielversion fest (eine Buildzeitentscheidung).
  • Wird nur verwendet WKWebView , wenn die App unter iOS 8+ ausgeführt wird (eine Laufzeitentscheidung).

Nicht bei Apple eingereichte Bewerbungen

Wenn Ihre Anwendung nicht an Apple übermittelt wird, sollten Sie beabsichtigen, die veraltete API zu entfernen, da sie in zukünftigen iOS-Versionen entfernt werden kann. Sie können diesen Übergang jedoch mit Ihrem eigenen Zeitplan tun.