Vues web dans Xamarin.iOS
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:1502
ne 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 deUIWebView
, par exemple, remplacez-la par les types plus récentsWKWebView
(iOS 8) ouSFSafariViewController
(iOS 9). Une fois cette opération terminée, l’éditeur de liens managés ne doit pas voir de référence etUIWebView
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’aide
UIWebView
) 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.