Share via

Vistas web en Xamarin.iOS

  • Artículo

Durante la trayectoria de iOS, Apple ha publicado varias maneras en las que los desarrolladores de aplicaciones incorporan la funcionalidad de vista web en sus aplicaciones. La mayoría de los usuarios usan el explorador web Safari integrado en su dispositivo iOS y, por lo tanto, esperan que la funcionalidad de vista web de otras aplicaciones sea coherente con esta experiencia. Esperan que funcionen los mismos gestos, y que el rendimiento y la funcionalidad sean los mismos.

iOS 11 introdujo nuevos cambios en WKWebView y SFSafariViewController. Para obtener más información sobre ellos, consulte la guía de cambios web en iOS 11.

WKWebView

WKWebView se introdujo en iOS 8, lo que permite a los desarrolladores de aplicaciones implementar una interfaz de exploración web similar a la de Safari móvil. Esto se debe, en parte, al hecho de que WKWebView usa el motor Nitro Javascript, el mismo motor usado por Safari móvil. WKWebView debe usarse siempre que sea posible a través de UIWebView debido al aumento del rendimiento, los gestos fáciles de usar y la facilidad de interacción entre la página web y la aplicación.

WKWebView se puede agregar a la aplicación de forma casi idéntica a UIWebView, pero como desarrollador tiene mucho más control sobre la interfaz de usuario y la experiencia de usuario y la funcionalidad. La creación y visualización del objeto de vista web mostrará la página solicitada, pero puede controlar cómo se presenta la vista, cómo puede navegar el usuario y cómo sale el usuario de la vista.

El código siguiente se puede usar para iniciar un elemento WKWebView en la aplicación de 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);

Es importante tener en cuenta que WKWebView está en el espacio de nombres WebKit, por lo que tendrá que agregar esta directiva de uso a la parte superior de la clase.

WKWebView también se puede usar en aplicaciones de Xamarin.Mac y debe usarla si va a crear una aplicación Mac/iOS multiplataforma.

La receta Controlar alertas de JavaScript también proporciona información sobre el uso de WKWebView con Javascript.

SFSafariViewController

SFSafariViewController es la forma más reciente de proporcionar contenido web desde la aplicación y está disponible en iOS 9 y versiones posteriores. A diferencia de UIWebView o WKWebView, SFSafariViewController es un controlador de vista y, por tanto, no se puede usar con otras vistas. Debe presentar SFSafariViewController como un nuevo controlador de vista, de la misma manera que presentaría cualquier controlador de vista.

SFSafariViewController es básicamente un "mini safari" que se puede incrustar en la aplicación. Al igual que WKWebView, usa el mismo motor de Javascript Nitro, pero también proporciona una variedad de características adicionales de Safari como AutoFill, Reader y la capacidad de compartir cookies y datos con Safari móvil. La aplicación no accede a la interacción entre el usuario y SFSafariViewController. La aplicación no tendrá acceso a ninguna de las características predeterminadas de Safari.

También, de forma predeterminada, implementa un botón Listo, lo que permite al usuario volver fácilmente a la aplicación y los botones de navegación hacia delante y atrás, lo que permite al usuario navegar por una pila de páginas web. Además, también proporciona al usuario una barra de direcciones para indicarle que se encuentra en la página web esperada. La barra de direcciones no permite al usuario cambiar la dirección URL.

Estas implementaciones no se pueden cambiar, por lo que es ideal usar SFSafariViewController como explorador predeterminado si la aplicación debe presentar una página web sin ninguna personalización.

El código siguiente se puede usar para iniciar un elemento SFSafariViewController en la aplicación de Xamarin.iOS:

var sfViewController = new SFSafariViewController(url);

PresentViewController(sfViewController, true, null);

Esto genera la siguiente vista web:

Una vista web de ejemplo con SFSafariViewController

Safari

También es posible abrir la aplicación Safari móvil desde dentro de la aplicación, mediante el código siguiente:

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

UIApplication.SharedApplication.OpenUrl(url);

Esto genera la siguiente vista web:

Una página web presentada en Safari

Por lo general, debería evitar sacar a los usuarios de la aplicación para llevarlos a Safari. La mayoría de los usuarios no esperarán salir de la aplicación, por lo que si la dejan, es posible que nunca vuelvan a ella. Básicamente, se destruye la interacción.

Las mejoras de iOS 9 permiten al usuario volver fácilmente a la aplicación a través de un botón Atrás que se proporciona en la esquina superior izquierda de la página Safari.

Seguridad de transporte de aplicación

Apple introdujo App Transport Security o ATS en iOS 9 para asegurarse de que todas las comunicaciones de Internet se ajusten a los procedimientos recomendados de conexión segura.

Para obtener más información sobre ATS, incluido cómo implementarla en la aplicación, consulte la guía App Transport Security.

Desuso de UIWebView

UIWebView es la forma heredada de Apple de proporcionar contenido web en la aplicación. Se lanzó en iOS 2.0 y ha quedado en desuso a partir de la versión 8.0.

Importante

UIWebView está en desuso. Las nuevas aplicaciones que usan este control no se aceptarán en App Store a partir de abril de 2020, y las actualizaciones de aplicaciones que usan este control no se aceptarán en diciembre de 2020.

La documentación UIWebView de Apple sugiere que las aplicaciones deben usar WKWebView en su lugar.

Si busca recursos con respecto a la advertencia de desuso de UIWebView (ITMS-90809) mientras usa Xamarin.Forms, consulte la documentación de Xamarin.Forms WebView.

Es posible que los desarrolladores que envíen aplicaciones iOS en los últimos seis meses (aproximadamente) hayan recibido una advertencia de App Store, donde se indica que UIWebView entrará en desuso.

Es común que las API entren en desuso. Xamarin.iOS usa atributos personalizados para indicar esas API (y sugerir reemplazos cuando estén disponibles) a los desarrolladores. Lo que es diferente en este caso, y mucho menos común, es que la App Store de Apple aplicará el desuso en el momento del envío de la aplicación.

Desafortunadamente, quitar el tipo UIWebView de Xamarin.iOS.dll es un cambio importante binario. Este cambio interrumpirá las bibliotecas de terceros existentes, incluidas algunas que podrían no ser compatibles o incluso volver a compilarse (por ejemplo, código fuente cerrado). Esto creará problemas adicionales para los desarrolladores. Por lo tanto, todavía no vamos a quitar el tipo.

Desde Xamarin.iOS 13.16 hay disponibles nuevas herramientas y detección para ayudarle a migrar desde UIWebView.

Detección

Si ha enviado recientemente una aplicación de iOS a Apple App Store, es posible que se pregunte si esta situación afecta a las aplicaciones.

Para averiguarlo, puede agregar --warn-on-type-ref=UIKit.UIWebView a los argumentos mtouch adicionales del proyecto. Esto advertirá de cualquier referencia a la UIWebView en desuso dentro de la aplicación (y todas sus dependencias). Se usan diferentes advertencias para notificar tipos antes y después de que se haya ejecutado el enlazador administrado.

Estas advertencias, al igual que otras, se pueden convertir en errores mediante -warnaserror:. Esto puede ser útil si desea asegurarse de que no se agregue una nueva dependencia a UIWebView después de las comprobaciones. Por ejemplo:

  • -warnaserror:1502 notificará de errores si se encuentran referencias en ensamblados vinculados previamente.
  • -warnaserror:1503 notificará de errores si se encuentran referencias en ensamblados vinculados posteriormente.

También puede silenciar las advertencias si los resultados de la vinculación previa o posterior no son útiles. Por ejemplo:

  • -nowarn:1502no notificará advertencias si se encuentran referencias en ensamblados vinculados previamente.
  • -nowarn:1503no notificará advertencias si se encuentran referencias en ensamblados vinculados previamente.

Eliminación

Cada aplicación es única. Eliminar UIWebView de la aplicación puede requerir distintos pasos en función de cómo y dónde se use. Los escenarios más comunes son estos:

  • No se usa UIWebView dentro la aplicación. No hay problema. No debería recibir advertencias al enviar a AppStore. No es necesario que haga nada.
  • Hay un uso directo de UIWebView en la aplicación. Para comenzar, quite el uso de UIWebView, por ejemplo, reemplácelo por los tipos más recientes WKWebView (iOS 8) o SFSafariViewController (iOS 9). Una vez completado, el enlazador administrado no debería ver ninguna referencia a UIWebView y el binario final de la aplicación no tendrá ningún seguimiento de él.
  • Uso indirecto. UIWebView puede estar presente en algunas bibliotecas de terceros, ya sea administradas o nativas, que use la aplicación. Empiece por actualizar las dependencias externas a sus versiones más recientes, ya que es posible que esta situación se resuelva en una versión más reciente. Si no es así, póngase en contacto con los mantenedor de las bibliotecas y pregunte sobre sus planes de actualización.

También puede probar las siguientes estrategias:

  1. Si usa Xamarin.Forms, lea esta entrada de blog.
  2. Habilite el enlazador administrado (en todo el proyecto o, al menos, en la dependencia mediante UIWebView) para que se pueda quitar, si no se hace referencia a él. Esto resolverá el problema, pero podría requerir trabajo adicional que el enlazador de código sea seguro.
  3. Si no puede cambiar la configuración del enlazador administrado, consulte los casos especiales siguientes.

Las aplicaciones no pueden usar el enlazador (o cambiar su configuración)

Si por algún motivo no usa el enlazador administrado (por ejemplo, al No vincular), el símbolo UIWebView permanecerá en la aplicación binaria que envíe a Apple y podría rechazarse.

Una solución de fuerza bruta es agregar --optimize=force-rejected-types-removal a los argumentos mtouch adicionales del proyecto. Esto quitará cualquier rastro de UIWebView de la aplicación. Sin embargo, cualquier código que haga referencia al tipo no funcionará correctamente (verá excepciones o bloqueos). Este enfoque solo se debe usar si sabe con certeza que el código no es accesible en tiempo de ejecución (incluso si era accesible a través del análisis estático).

Compatibilidad con iOS 7.x (o versiones anteriores)

UIWebView ha sido parte de iOS desde v2.0. Los reemplazos más comunes son WKWebView (iOS 8) y SFSafariViewController (iOS 9). Si la aplicación sigue admitiendo versiones anteriores de iOS, debe tener en cuenta las siguientes opciones:

  • Haga que iOS 8 sea la versión de destino mínima (una decisión de tiempo de compilación).
  • Use solo WKWebView si la aplicación se ejecuta en iOS 8+ (una decisión en tiempo de ejecución).

Aplicaciones no enviadas a Apple

Si la aplicación no se envía a Apple, plantéese dejar de usar la API en desuso, ya que se puede quitar en futuras versiones de iOS. Sin embargo, puede realizar esta transición cuando lo desee.