Vues web dans Xamarin.iOS

Article
03/22/2017

Au fil de la durée de vie d’Apple, Apple a publié plusieurs façons pour les développeurs d’applications d’incorporer des fonctionnalités de vue web dans leurs applications. La plupart des utilisateurs utilisent le navigateur web Safari intégré sur leur appareil iOS et s’attendent donc à ce que les fonctionnalités d’affichage web d’autres applications soient cohérentes avec cette expérience. Ils s’attendent à ce que les mêmes mouvements fonctionnent, que les performances soient identiques et que les fonctionnalités soient identiques.

iOS 11 a introduit de nouvelles modifications à la fois WKWebView et SFSafariViewController. Pour plus d’informations sur ces informations, consultez le guide du guide des modifications web dans iOS 11.

WKWebView

WKWebView a été introduit dans iOS 8 permettant aux développeurs d’applications d’implémenter une interface de navigation web similaire à celle de Safari mobile. Cela est dû en partie au fait qu’il WKWebView utilise le moteur Nitro Javascript, le même moteur utilisé par safari mobile. WKWebView doit toujours être utilisé sur UIWebView dans la mesure du possible en raison des performances accrues, des mouvements intégrés et de la facilité d’interaction entre la page web et votre application.

WKWebView peut être ajouté à votre application de manière presque identique à UIWebView, mais comme le développeur que vous avez beaucoup plus de contrôle sur l’interface utilisateur/UX et la fonctionnalité. La création et l’affichage de l’objet d’affichage web affichent la page demandée, mais vous pouvez contrôler la façon dont l’affichage est présenté, la façon dont l’utilisateur peut naviguer et comment l’utilisateur quitte la vue.

Le code ci-dessous peut être utilisé pour lancer une WKWebView application Xamarin.iOS :

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);

Il est important de noter qu’il WKWebView se trouve dans l’espace WebKit de noms. Vous devrez donc ajouter cette directive using au début de votre classe.

WKWebView peut également être utilisé dans les applications Xamarin.Mac et vous devez l’utiliser si vous créez une application Mac/iOS multiplateforme.

La recette Gérer les alertes JavaScript fournit également des informations sur l’utilisation de WKWebView avec Javascript.

SFSafariViewController

SFSafariViewController est la dernière façon de fournir du contenu web à partir de votre application et est disponible dans iOS 9 et versions ultérieures. Contrairement UIWebView ou WKWebView, SFSafariViewController est un contrôleur de vue et ne peut donc pas être utilisé avec d’autres vues. Vous devez présenter SFSafariViewController un nouveau contrôleur d’affichage de la même façon que n’importe quel contrôleur d’affichage.

SFSafariViewController est essentiellement un « mini safari » qui peut être incorporé dans votre application. Comme WKWebView, il utilise le même moteur Nitro Javascript, mais fournit également une gamme de fonctionnalités Safari supplémentaires telles que le remplissage automatique, le lecteur et la possibilité de partager des cookies et des données avec Safari mobile. L’interaction entre l’utilisateur et l’utilisateur SFSafariViewController n’est pas accessible à votre application. Votre application n’aura accès à aucune des fonctionnalités Safari par défaut.

Par défaut, il implémente également un bouton Terminé , ce qui permet à l’utilisateur de revenir facilement à votre application, et de transférer et de renvoyer des boutons de navigation, ce qui permet à votre utilisateur de naviguer dans une pile de pages web. En outre, il fournit également à l’utilisateur une barre d’adresses lui donnant la tranquillité d’esprit qu’il se trouve sur la page web attendue. La barre d’adresses n’autorise pas l’utilisateur à modifier l’URL.

Ces implémentations ne peuvent pas être modifiées. Il est donc SFSafariViewController idéal d’utiliser comme navigateur par défaut si votre application souhaite présenter une page web sans personnalisation.

Le code ci-dessous peut être utilisé pour lancer une SFSafariViewController application Xamarin.iOS :

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

Cela produit l’affichage web suivant :

Safari

Il est également possible d’ouvrir l’application Safari mobile à partir de votre application à l’aide du code ci-dessous :

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

UIApplication.SharedApplication.OpenUrl(url);

Cela produit l’affichage web suivant :

La navigation des utilisateurs loin de votre application vers Safari doit généralement être évitée. La plupart des utilisateurs ne s’attendront pas à la navigation en dehors de votre application. Par conséquent, si vous quittez votre application, les utilisateurs peuvent ne jamais le retourner, ce qui tue essentiellement l’engagement.

Les améliorations apportées à iOS 9 permettent à l’utilisateur de revenir facilement à votre application via un bouton Précédent fourni dans le coin supérieur gauche de la page Safari.

Sécurité de transport de l’application

App Transport Security ou ATS a été introduit par Apple dans iOS 9 pour garantir que toutes les communications Internet sont conformes aux meilleures pratiques de connexion sécurisée.

Pour plus d’informations sur ATS, notamment sur la façon de l’implémenter dans votre application, reportez-vous au guide app Transport Security .

Dépréciation UIWebView

UIWebView est le moyen hérité d’Apple de fournir du contenu web dans votre application. Il a été publié dans iOS 2.0 et a été déconseillé depuis la version 8.0.

Important

UIWebView est déconseillé. Les nouvelles applications utilisant ce contrôle ne seront pas acceptées dans l’App Store à compter d’avril 2020 et les mises à jour d’applications utilisant ce contrôle ne seront pas acceptées d’ici décembre 2020.

La documentation d’Apple UIWebView suggère que les applications doivent être utilisées WKWebView à la place.

Si vous recherchez des ressources en ce qui concerne l’avertissement UIWebView de dépréciation (ITMS-90809) lors de l’utilisation de Xamarin.Forms, reportez-vous à la documentation WebView Xamarin.Forms.

Les développeurs qui ont envoyé des applications iOS au cours des six derniers mois (ou ainsi) ont peut-être reçu un avertissement de l’App Store, sur UIWebView la dépréciation.

Les dépréciations des API sont courantes. Xamarin.iOS utilise des attributs personnalisés pour signaler ces API (et suggérer des remplacements lorsqu’ils sont disponibles) aux développeurs. Ce qui est différent cette fois, et beaucoup moins courant, est que la dépréciation sera appliquée par l’App Store d’Apple au moment de l’envoi.

Malheureusement, la suppression du UIWebView type est Xamarin.iOS.dll un changement cassant binaire. Cette modification interrompt les bibliothèques tierces existantes, notamment certaines qui peuvent ne plus être prises en charge ou même réinscrire (par exemple, source fermée). Cela ne crée que des problèmes supplémentaires pour les développeurs. Par conséquent, nous ne supprimons pas encore le type.

À compter de Xamarin.iOS 13.16, de nouveaux outils et de détection sont disponibles pour vous aider à migrer à partir de UIWebView.

Detection

Si vous avez récemment envoyé une application iOS à l’Apple App Store, vous pouvez vous demander si cette situation s’applique à votre ou vos applications.

Pour en savoir plus, vous pouvez ajouter --warn-on-type-ref=UIKit.UIWebView aux arguments mtouch supplémentaires de votre projet. Cela avertit toute référence à l’intérieur UIWebView de votre application (et de toutes ses dépendances). Différents avertissements sont utilisés pour signaler les types avant et après l’exécution de l’éditeur de liens managés.

Les avertissements, comme d’autres, peuvent être transformés en erreurs à l’aide -warnaserror:de . Cela peut être utile si vous souhaitez vous assurer qu’une nouvelle dépendance à UIWebView n’est pas ajoutée après vos vérifications. Par exemple :

-warnaserror:1502 signale des erreurs si des références sont trouvées dans les assemblys pré-liés.
-warnaserror:1503 signale des erreurs si des références sont trouvées dans des assemblys post-liés.

Vous pouvez également désactiver le silence des avertissements si les résultats de la liaison avant/post ne sont pas utiles. Par exemple :

-nowarn:1502ne signale pas d’avertissements si des références sont trouvées dans les assemblys pré-liés.
-nowarn:1503 ne signale pas d’avertissements si des références sont trouvées dans des assemblys post-liés.

Suppression

Chaque application est unique. UIWebView La suppression de votre application peut nécessiter différentes étapes en fonction de la façon et de l’emplacement où elle est utilisée. Les scénarios les plus courants sont les suivants :

Il n’existe aucune utilisation à l’intérieur de UIWebView votre application. Tout va bien. Vous ne devez pas avoir d’avertissements lors de l’envoi à l’AppStore. Rien d’autre n’est nécessaire de vous.
Utilisation directe de UIWebView votre application. Commencez par supprimer votre utilisation de UIWebView, par exemple, remplacez-la par les types plus récents WKWebView (iOS 8) ou SFSafariViewController (iOS 9). Une fois cette opération terminée, l’éditeur de liens managés ne doit pas voir de référence et UIWebView le fichier binaire de l’application final n’aura aucune trace de celui-ci.
Utilisation indirecte. UIWebView peut être présent dans certaines bibliothèques tierces, gérées ou natives utilisées par votre application. Commencez par mettre à jour vos dépendances externes vers leurs dernières versions, car cette situation peut déjà être résolue dans une version plus récente. Si ce n’est pas le cas, contactez le ou les gestionnaires de maintenance des bibliothèques et demandez-lui des plans de mise à jour.

Vous pouvez également essayer les approches suivantes :

Si vous utilisez Xamarin.Forms, lisez ce billet de blog.
Activez l’éditeur de liens managés (sur l’ensemble du projet ou, au moins, sur la dépendance à l’aideUIWebView) afin qu’il puisse être supprimé, s’il n’est pas référencé. Cela va résoudre le problème, mais cela peut avoir besoin d’un travail supplémentaire pour rendre votre éditeur de liens de code sécurisé.
Si vous ne parvenez pas à modifier les paramètres de l’éditeur de liens managés, consultez les cas spéciaux ci-dessous.

Les applications ne peuvent pas utiliser l’éditeur de liens (ou modifier ses paramètres)

Si, pour une raison quelconque, vous n’utilisez pas l’éditeur de liens managés (par exemple, Ne pas lier), le UIWebView symbole reste dans l’application binaire que vous envoyez à Apple et il peut être rejeté.

Une solution forcée consiste à ajouter --optimize=force-rejected-types-removal aux arguments mtouch supplémentaires de votre projet. Cela supprime les traces de UIWebView l’application. Toutefois, tout code qui fait référence au type ne fonctionnera pas correctement (attendez des exceptions ou des blocages). Cette approche ne doit être utilisée que si vous êtes sûr que le code n’est pas accessible au moment de l’exécution (même s’il était accessible par le biais d’une analyse statique).

Prise en charge d’iOS 7.x (ou version antérieure)

UIWebView fait partie d’iOS depuis la version 2.0. Les remplacements les plus courants sont WKWebView (iOS 8) et SFSafariViewController (iOS 9). Si votre application prend toujours en charge les versions antérieures d’iOS, vous devez prendre en compte les options suivantes :

Prenez iOS 8 votre version cible minimale (décision de temps de génération).
WKWebView Utilisez uniquement si l’application s’exécute sur iOS 8+ (décision d’exécution).

Applications non soumises à Apple

Si votre application n’est pas soumise à Apple, vous devez planifier la suppression de l’API déconseillée, car elle peut être supprimée dans les versions ultérieures d’iOS. Toutefois, vous pouvez effectuer cette transition à l’aide de votre propre calendrier.

Partager via