Existen muchas mejoras que pueden mejorar la conversión y el uso de tu AWP.
Accesos directos a aplicaciones
Los atajos a aplicaciones son una lista estática de vínculos directos a tu AWP, que se escriben en el manifiesto. Especificación del manifiesto de apps web. Te permite definir una lista de combinaciones de teclas para diferentes partes o funciones de tu AWP y aceleran la navegación a las secciones a las que accedes con frecuencia.
Los accesos directos a aplicaciones están disponibles en la mayoría de los sistemas operativos de escritorio y en Android con WebAPK, y aparecen en un menú contextual en el ícono de la app en la pantalla principal, el conector o la barra de tareas, como en la siguiente imagen:
Para acceder a este menú, los usuarios deben hacer clic con el botón derecho en el ícono de la AWP o mantenerlo presionado.
Los accesos directos se definen en el miembro shortcuts del manifiesto. Toma un array de miembros con las siguientes propiedades:
name- El texto que se mostrará al usuario, por lo general, en un menú contextual.
url- Es la URL que la AWP debe cargar cuando el usuario la inicia desde este acceso directo. Debe ser una URL dentro del alcance de tu AWP y debe incluir un vínculo directo a la función que describen
nameoshort_name. short_name- Un nombre más corto que se usa cuando no hay suficiente espacio para mostrar el valor completo del campo
name(opcional). description- Una descripción de lo que hará este acceso directo(opcional)
icons- (Opcional) Un array de objetos de ícono con campos
src,type,sizesypurposeopcionales, que describen qué imágenes deben representar el acceso directo
Debes tratar los accesos directos a aplicaciones como la mejor habilidad posible. Esto significa que no puedes confiar en que estas combinaciones de teclas aparezcan de forma coherente y, aunque aparezcan, no sabes cuántas combinaciones de teclas aparecerán o si la plataforma ignorará los íconos, según lo determinen los navegadores. Un debate completo sobre cada plataforma está fuera del alcance, pero a continuación tienes una idea de cómo funciona en Android y computadoras de escritorio. La mejor manera de lidiar con esta incertidumbre es ordenar los elementos por prioridad.
En la siguiente muestra de código, se definen diferentes combinaciones de teclas para apps que puedes probar si instalas la app en Android con Chrome o en computadoras con Edge o Chrome.
iOS y iPadOS
Al publicar AWP, se implementaron algunas mejoras que pueden mejorar la experiencia de los usuarios de Safari en iOS/iPadOS.
Pantallas de presentación
Como se ve en el capítulo Manifiesto de las apps web, Android crea pantallas de presentación automáticamente según los valores del manifiesto. No es el caso de iOS ni iPadOS. En estos dispositivos, debes definir las pantallas de presentación en el código HTML como imágenes estáticas con elementos <link>.
Estas imágenes se conocen como imágenes de inicio en dispositivos Apple y usan la propiedad rel con el valor apple-touch-startup-image, como en el siguiente ejemplo:
<link rel="apple-touch-startup-image" href="ios-startup.png">
El desafío es que la imagen de inicio debe tener el tamaño de ventana exacto que tendrá la AWP cuando se abra. Por lo tanto, los distintos dispositivos iOS y iPadOS necesitarán imágenes diferentes. Se deben cubrir otras situaciones en el iPad, como las aperturas horizontales o verticales y la renderización de la AWP en modo multitarea (como 1/3, 1/2 o 2/3 de la pantalla).
Puedes consultar una lista actualizada de los tamaños de pantalla de iOS y iPadOS en los Lineamientos de la interfaz humana de Apple
Se pueden configurar diferentes versiones de la imagen de inicio con una consulta de medios dentro del atributo media:
<link rel="apple-touch-startup-image" href="ios-startup.png"
media="orientation: portrait">
<link rel="apple-touch-startup-image" href="ios-startup-landscape.png"
media="orientation: landscape">
Patrones de diseño para imágenes de inicio de iOS
Definir las imágenes de inicio es un trabajo arduo, por lo que contamos con algunas herramientas para la generación y la configuración automatizadas:
- La generación estática se integra con tu sistema de compilación, crea todas las imágenes estáticas PNG y te proporciona el código HTML con elementos
<link>para insertar en el documento. El Generador de recursos de AWP es un ejemplo de esta herramienta. - Generador del cliente, herramienta de JavaScript que puede incorporar una o más versiones en base64 de la imagen de inicio en los elementos insertados de
<link>según el tipo y el tamaño de pantalla actuales del dispositivo. Puedes usar un lienzo en la memoria, renderizar la imagen y convertirla en un URIdata:con un archivo PNG. La biblioteca de AWP Compat es una biblioteca del cliente fácil de usar que lo hace clonando la pantalla de inicio típica de Android.
Detecta una AWP en plataformas móviles de Apple
Si bien debes usar la mejora progresiva y la detección de funciones en tu AWP, es posible que haya algunos casos extremos en los que necesitemos saber si el usuario está usando una AWP en plataformas móviles de Apple, como cuando quieres ofrecer instrucciones de instalación o agregar vínculos a apps específicas de la plataforma que son solo para iOS.
Para evitar leer la cadena del usuario-agente, verifica la propiedad standalone del objeto navigator. Esta es una propiedad no estándar y solo está disponible en el motor WebKit en iOS y iPadOS.
- Si
navigator.standaloneesundefined, significa que el usuario no tiene un dispositivo iPadOS o iOS. - Si
navigator.standaloneesfalse, significa que el usuario abrió la AWP en el navegador y la usa allí. - Si
navigator.standaloneestrue, significa que el usuario abrió la AWP desde la pantalla principal y obtiene la experiencia de AWP independiente.
Compatibilidad con pantalla completa
En Safari para iOS y iPad, solo se admite display: standalone como modo de visualización del ícono de tu AWP. Si bien display: fullscreen no es compatible con los dispositivos Android, es posible usar una metaetiqueta no estándar para que tu AWP entre en modo de pantalla completa.
En la siguiente imagen, puedes ver a la izquierda un diseño independiente predeterminado con un color de tema y, a la derecha, una AWP con un modo iOS de pantalla completa que te permite renderizar contenido detrás de la barra de estado.
Si agregas la siguiente etiqueta en tu HTML, tu AWP en iOS y iPadOS ingresará al modo de pantalla completa, pero es diferente a la de Android.
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
En este modo, la barra de estado del dispositivo (la parte superior en la que ves el reloj, el nivel de batería y los íconos de notificaciones) sigue estando visible, pero se renderiza sobre tu contenido con un fondo transparente.
Cuando uses este modo, ten cuidado con el diseño, ya que el sistema operativo siempre renderizará los íconos en blanco, por lo que siempre debes contrastar los fondos de la parte superior de la pantalla con contenido claro. Además, es importante usar variables de entorno de CSS para renderizar contenido en el área segura, como se ve en el Capítulo de diseño de apps.
Confiabilidad de la instalación
Safari en iOS y iPadOS anteriores a la versión 15.4 solo carga el archivo de manifiesto desde la red cuando el usuario abre la hoja para compartir (mediante el ícono para compartir dentro del navegador) y no cuando se carga la página. Por lo tanto, Safari no verifica si tu sitio web es una AWP hasta ese momento, lo que puede dar lugar a situaciones en las que el manifiesto no se puede cargar o lleva demasiado tiempo, y Safari lo ignora.
Cuando Safari no puede cargar el manifiesto a tiempo, cuando presionas "Agregar a la pantalla principal", se coloca un ícono en la pantalla principal, pero no brinda una experiencia de la app. Solo será un acceso directo a una pestaña de Safari.