Rankmi

La aplicación se basa en un explorador web embebido, específicamente un View del tipo web
View.
El flujo de la aplicación es desde el HOME_LAUNCHER el punto de entrada es el
SplashActivity, de acá válida si hay conexión o no y entra al WebViewActivity.
Constantemente el webView estará haciendo validaciones por medio del ViewModel, además
que en el momento de que no se tenga conexión mostrará el DialogFragmentCheckNewtork

Figura 1. Flujo de la aplicación Rankmi

Resumen

SplashActivity
Este contiene el código necesario para mostrar la animación lottie del inicio así como
detectar si hay o no hay conexión para desplegar una vista de sin conexión en su layout
correspondiente, a partir de acá se va a la siguiente activity creando un nuevo intent.
WebViewActivity
Este viene siendo el corazón de la aplicación, se utilizan una serie de flags para manipular
los elementos nativos de Android, ya que toda la información viene del webView y no es
posible detectar más que el cambio de URL, a no ser que se cuente con validaciones de JS
de las que se hablará más adelante.
En esta activity se utilizó binding, para generar un objeto con todas las vistas del layout y así
evitarse la costosa tarea de tener que revisar todo el layout para usar alguna vista.
Se definió una clase exclusiva para el cliente de Rankmi, y así poder observar el estado del
webView.
La manipulación del onBack se hizo basándose en los URL que se obtenían en el client.
Considerando que las aplicaciones web embebidas para Android fueron de cierta manera
dejadas atrás por Google, el manejo del login por Google, se hizo implementando callbacks.

ViewModel
Este contiene toda la lógica necesaria para saber cuando mostrar el menú nativo, las
llamadas a las funciones JS y validaciones nativas de la aplicación.
DialogFragmentCheckNetwork

Este fragment se encarga del despliegue del dialog, en el momento que no se tenga
conexión a internet y ocurra un cambio de URL

Configuración del webView

Toda la configuración se lleva a cabo en el webViewActivity, se define la vista webView con

el nombre de mainWebView programáticamente, esto con la intención colocarle las
configuraciones.
La función setupWebView(), Se encarga de las siguientes configuraciones

Figura 2. Settings webView

Al mainWebView se le aplicaron todas estas configuraciones, para que funcionara de la

manera correcta, de acá hay que destacar las que están encerrados en rosado, son las
correspondientes para que el JS esté habilitado y se cargue el URL de la página.
El resto que están en color naranja son las correspondientes para que funcione el login por
Google de la aplicación.

Rankmi Cliente

La aplicación cuenta con un cliente modificado para detectar si la página está iniciando, si
está cargando un recurso o si ya finalizo, esto es muy útil para debugear desde
androidStudio y ver que está ocurriendo y en cuál estado se encuentra el webView, se crea
una clase de este en la configuración del WebView

Figura 3. Definición del cliente de Rankmi

En este cliente se sobrescriben 4 funciones de las cuales

onLoadResource(): Se ejecuta cada vez que se carga un elemento del DOM de la página,
en este se introdujo la ejecución de tres funciones que están en verdad validando el estado
de la página.

checkNetwork() : Esta “observando” si hay internet en el dispositivo, para cambiar el

valor de _hideErrorDialog.value, esta variable, definida en el viewModel es
observada para desplegar el dialogFragmentCheckNetwork.

goForMobile() : Esta función está definida en el JS de la página web y cambia

elementos de la página web para ser mostrada como una “aplicación móvil”.

enableBottomBar(): Esta función viene del JS y trae una validación de cuando se

debe mostrar el menú nativo de la aplicación, según el estado de la paginaweb

onPageStarted() : Esta función se ejecuta cuando la página en el webView comienza a

cargar, se hace una validación para esconder el webView y poder mostrar el icono de
cargando, además se oculta el menú nativo.

OnPageFinished() : Esta se ejecuta cuando la página en el webView se termina de cargar,

hace una validación para mostrar el webView, oculta el icono de cargando y muestra el menú
nativo

Nota:
La funcionalidad de onPageStarted() y onPageFinished() no es como se esperaría, es
decir solo se ejecutan al iniciar la aplicación y al loguearse, por eso se introdujo la función
onLoadResource()

Observadores

La aplicación al integrar viewModel también usó LiveData para manipular ciertos elementos
de Android nativo, en este caso ver la figura 4.
El rectángulo naranja corresponde al observador de la pestaña de notificaciones, como se
debe esconder el webView y mostrar una vista nativa, se está observando constantemente la
variable booleana showNotification para ver si se debe mostrar o no la misma.
El valor de esta variable cambiará según sea la pestaña que se seleccione.
 Figura 4. Observers in Rankmi

El rectángulo morado, está observando hideErrorDialog, que es la variable que cambia

según hay internet o no, mencionada en el apartado anterior. En este caso si no existe el
dialog lo genera, y le asigna el contrato para poder usar setOnDismissListener

Luego si el diálogo debe de ser mostrado lo muestra en la pantalla.

Menú

El menú es un linearLayout que contiene un TabLayout

Figura 5. Manejo de estados en el menú

Al tabLayout se le colocó un listener para ver qué tab ha sido seleccionada y en función de
eso ejecutar una función u otra. El funcionamiento de base en esas funciones se puede ver
en el apartado de modificaciones.

Nota
Se utilizó onTabUnseleceted también para manejar, las validaciones que tiene cada una de
las pestañas

Login por Google.

El login, se hace generando un dialog que contiene adentro otro webView que lleva a
Google, en este es importante resaltar los recuadros azules, el primero genera el
webViewPopUp que será donde se desplegará la página de Google, luego se coloca el
agente, el cual le dice a Google desde que dispositivo se está accediendo.
Este login funciona basándonos en unos callback que son los que son capaces de
redireccionar y mandar a cerrar el dialog cuando se finaliza el login

Figura 6. Dialog para loguearse usando google

Al finalizar el login se manejan la excepción generada con la destrucción y el cierre y del
webView y el dialog generado. Ver figura 7.

Figura 7. Manejo de excepciones generadas al finalizar el login

Posibles modificaciones

Caso 1. Cambio en las llamadas a JS

Si se quisiera hacer cambios en la aplicación relacionados con la llamada de funciones del

JS de la página, se debe primero escribir las funciones en el código de JS de la misma forma
que fue escrita mobileCallEvent. En la aplicación creamos una clase que posee los
distintos parámetros de la función mobileCallEvent para poder comunicarnos con el JS. Ver
figura 8.
Por lo tanto, en el código de Android, se debe buscar la clase MobileEvents y agregar el
nombre del string que apunta a la función JS.

Figura 8. Clase MobileEvents, la cual contiene a los distintos parámetros de la función

mobileCallEvent
Para llamar a la nueva función definida se hace basándonos en el webView.

La vista del webView tiene el método de evaluateJavascript. Que nos permite llamar
alguna función JS que esté dentro de la página web ver figura 3. Los parámetros de la
función son:
“window.mobileCallEvent(\”” + action + “\”)”) este argumento le está diciendo al
explorador embebido en su código JS que busque en el objeto windows la función definida
como mobileCallEvent y le pase como argumento un string definido en la aplicación móvil. De
esta manera se logra apuntar a alguna función definida en JS desde Android.

Nota
La modificación de ese parámetro debe hacerse con mucho cuidado, respetando comillas y
los slash si no, la llamada de la función no se ejecutara y deberá debuggearse desde algún
explorador web para ver el error.

Figura 9. llamar funcion desde JS desde android.

En la aplicación se creó la función callJavascriptFunction, la cual recibe el string de la

clase mobileEvents y el webView de la app. Esto fue hecho con la intención de mover la
lógica al viewModel.
Caso 2. Cambio de link.

En principio se debe de cambiar el link contenido en el companion object dentro del

webViewActivity, ver figura 10.

Figura 10. URL del webView

Luego de cambiar este URL se debe hacer la manipulación del onBackPressed

 Figura 11. onBackPressed

Considerando que se trata de un explorador embebido no hay muchas alternativas para

detectar eventos o el estado de la aplicación más que utilizando el cliente. Para poder saber
a donde la aplicación debe ir al presionar el onback, se hizo la lógica de la figura 5. La cual
básicamente detecta si puedes ir hacia atrás o cerrar la aplicación dependiendo del URL en
que te encuentres ya sea HOME, LOGIN o MENU.
Si se cambia el link de la aplicación, hay que evaluar los nuevos URL y modificar los strings
de las funciones enableTabFromUrl y onBackPressed correspondientes a las figuras 5 y 6
respectivamente.
Figura 10. enableTabFromUrl function.