Desarrollo de aplicaciones híbridas en Telefónica - Parte 2: Aspectos técnicos
En el
artículo anterior hablamos de nuestra motivación en Telefónica para crear un marco de trabajo de Android para
maximizar el rendimiento y ofrecer la mejor experiencia de usuario en una aplicación híbrida.
Ahora profundizaremos en los aspectos técnicos y las capacidades de nuestro marco, que se han desarrollado para aprovechar al máximo las capacidades del sistema operativo.
Como hemos mencionado, nuestro marco de trabajo intercepta cualquier URL antes de que se cargue en la webview. Esta función ofrece la posibilidad de controlar cómo interactúa una URL con la aplicación nativa, permitiéndonos manipular la interfaz o desencadenar flujos de lógica empresarial.
Para ello, nuestro marco de trabajo tiene la capacidad de utilizar parámetros de consulta URL o un archivo de configuración que se descarga cuando se inicia la aplicación.
Durante este proceso, hay algunos puntos que nos interesan:
Ahora profundizaremos en los aspectos técnicos y las capacidades de nuestro marco, que se han desarrollado para aprovechar al máximo las capacidades del sistema operativo.
Como hemos mencionado, nuestro marco de trabajo intercepta cualquier URL antes de que se cargue en la webview. Esta función ofrece la posibilidad de controlar cómo interactúa una URL con la aplicación nativa, permitiéndonos manipular la interfaz o desencadenar flujos de lógica empresarial.
Para ello, nuestro marco de trabajo tiene la capacidad de utilizar parámetros de consulta URL o un archivo de configuración que se descarga cuando se inicia la aplicación.
Durante este proceso, hay algunos puntos que nos interesan:
Dónde se cargará la URL
Consideramos que este punto es uno de los más importantes, ya que no queremos que todas las URL se carguen en la webview actual. Entre las opciones consideradas están:
Por ejemplo, si queremos mantener al usuario dentro de la aplicación, puede ser apropiado cargar la URL en la webview actual o crear una nueva. Por otro lado, si queremos llevar al usuario a un sitio web de terceros, puede ser más apropiado abrir la URL en el navegador del dispositivo.
- Modo estancia: Carga la URL en la vista web actual.
- Modo interno: Crea una nueva vista web y carga allí la URL. Simular una pantalla nativa.
- Modo navegador: Como el modo interno, pero con ligeros cambios en la interfaz de usuario para que el usuario sea consciente de ello en una vista web.
- Modo externo: Abre la URL en el navegador del dispositivo.
Por ejemplo, si queremos mantener al usuario dentro de la aplicación, puede ser apropiado cargar la URL en la webview actual o crear una nueva. Por otro lado, si queremos llevar al usuario a un sitio web de terceros, puede ser más apropiado abrir la URL en el navegador del dispositivo.
Animación que muestra una vista web usando el modo externo
En cualquier caso, es importante
considerar cuidadosamente las compensaciones de cada opción y elegir la que mejor satisfaga las necesidades de la aplicación y del usuario. Por ejemplo, usar
pestañas personalizadas nos permite mantener una apariencia y sensación consistentes con el resto de la aplicación, pero puede que no ofrezca el mismo nivel de control que una vista web completamente personalizada. Por otro lado,
usar una vista web personalizada nos da control total sobre la experiencia del usuario, pero puede requerir más recursos de desarrollo.
Cómo se presentará la vista web
Esto solo se
aplica cuando el modo de navegación es
Interno ya que en los otros tres modos no tenemos la posibilidad de modificar el estilo de presentación. En este caso, tenemos dos modos de presentación:
Flujo o Modal.
Por ejemplo, si queremos mostrar una webview como una función independiente, puede ser apropiado utilizar el modo Modal . Por otro lado, si queremos mostrar una webview como parte de un flujo de trabajo mayor, puede ser más apropiado utilizar el modo Flujo.
- Flujo: hará una transición de derecha a izquierda y su botón de la barra superior será una flecha hacia atrás.
- Modal: mostrará una webview con una transición de abajo a arriba y un botón X para cerrarla.
Por ejemplo, si queremos mostrar una webview como una función independiente, puede ser apropiado utilizar el modo Modal . Por otro lado, si queremos mostrar una webview como parte de un flujo de trabajo mayor, puede ser más apropiado utilizar el modo Flujo.
Animación que muestra dos vistas web usando el modo de flujo y el modo modal.
Qué componentes visuales deben modificarse
Similar al punto anterior, esto solo
se aplica cuando el modo de navegación se configura como Interno.
Podemos hacer ciertas modificaciones visuales en la interfaz para mejorar la experiencia de usuario.
Podemos hacer ciertas modificaciones visuales en la interfaz para mejorar la experiencia de usuario.
- topBar [boolean]: Nos permite mostrar u ocultar la barra superior.
- blockUntilLoaded [booleano]: Determina cuándo ocultar el spinner de carga nativo de la webview. Si se configura en true, el dispositivo esperará a que se carguen todos los recursos antes de quitar el spinner. Si se configura en falso, el spinner se eliminará tan pronto como el DOM de la página esté listo.
- fixedTitle [cadena]: Nos permite mostrar un título fijo para la página cargada, que permanecerá aunque se carguen nuevas URL en la misma webview.
- keepTitle [boolean]: Nos permite mantener el título actual de la página para las siguientes URL abiertas en la misma webview.
Qué lógica puede activarse
Por último, estos parámetros solo se
interpretarán si el modo de navegación está configurado como Permanecer o Interno. La siguiente lista de parámetros puede activar flujos lógicos de negocio específicos:
En resumen, nuestro marco de trabajo nos permite interceptar URL antes de que se carguen en la webview, permitiéndonos controlar cómo interactúa la URL con la aplicación nativa y personalizar el comportamiento de su aplicación. Para ello, el marco de trabajo puede utilizar parámetros de consulta de URL o un archivo de configuración .
También ofrece opciones para que decidir dónde se cargará la URL, como en la webview actual o en una nueva webview. Además, permite modificar la experiencia de usuario o activar flujos lógicos empresariales específicos.
Eso es todo. Esperamos que hayas disfrutado de este segundo artículo. Si este artículo te ha resultado útil, dale un aplauso y compártelo con tus amigos.
Este artículo forma parte de una serie. Si aún no has leído el primero de ellos, es un buen punto de partida para comprender un poco mejor nuestro recorrido y nuestras motivaciones.
[Parte 1 — Consejos y mejores prácticas]
En la publicación final, cubriremos cómo depuramos fácilmente nuestras integraciones.
[Parte 3 — Depuración]
- renewSession [boolean]: Fuerza a renovar la información de la sesión, recargando cualquier ventana actualmente abierta con nuevas credenciales después de renegociar la sesión.
- refreshOnClose [boolean]: Actualiza la URL cargada anteriormente. Si un usuario navega de una URL a otra URL y el modo de navegación para la segunda URL está configurado como refreshOnClose, cuando el usuario cierre la webview con la URL B, la webview con la URL A se recargará.
- dismissOnBack [boolean]: Abandona la vista web cuando se pulsa el botón Atrás. Esto puede ser útil en flujos web en los que se desea volver al punto de partida en lugar de retroceder.
- cleanCookiesBeforeLoad [booleano]: Todas las cookies se limpiarán antes de que se cargue la URL.
En resumen, nuestro marco de trabajo nos permite interceptar URL antes de que se carguen en la webview, permitiéndonos controlar cómo interactúa la URL con la aplicación nativa y personalizar el comportamiento de su aplicación. Para ello, el marco de trabajo puede utilizar parámetros de consulta de URL o un archivo de configuración .
También ofrece opciones para que decidir dónde se cargará la URL, como en la webview actual o en una nueva webview. Además, permite modificar la experiencia de usuario o activar flujos lógicos empresariales específicos.
Eso es todo. Esperamos que hayas disfrutado de este segundo artículo. Si este artículo te ha resultado útil, dale un aplauso y compártelo con tus amigos.
Este artículo forma parte de una serie. Si aún no has leído el primero de ellos, es un buen punto de partida para comprender un poco mejor nuestro recorrido y nuestras motivaciones.
[Parte 1 — Consejos y mejores prácticas]
En la publicación final, cubriremos cómo depuramos fácilmente nuestras integraciones.
[Parte 3 — Depuración]
Pruebas de Captura de Pantalla con Roborazzi en Sistemas de Diseño
Descubre cómo usamos Roborazzi para realizar pruebas de captura de pantalla eficientes en nuestros sistemas de diseño, asegurando la coherencia visual en distintas marcas y dispositivos sin la necesidad de emuladores. Aprende a integrarlo con Robolectric.