Hola amigos y lectores de SharingAway. Hoy les traigo un aspecto que personalmente considero muy importante si van a comenzar con el desarrollo (sin código) de aplicaciones móviles.

Toca la tarea, para algunos no tan divertida, de hacer debug, o de hacer testing en nuestra Aplicación. Para ello vamos a repasar que opciones nos ofrece FlutterFlow para probar nuestra App durante el ciclo de desarrollo, cuáles son las diferentes modalidades, cuándo usarlas y para que sirven.

Por otra parte, y como si fuera poco , será útil hacer un repaso sobre el centro de alertas en FlutterFlow, Warnings y Errores, que son cada uno y que impacto tienen.

Para cerrar, les traigo algunas cositas adicionales al final, así que les conviene leer todo… Les mencionaré algunas herramientas complementarias.

🖐🏼 Importante: Nos vamos a enfocar en testing de Aplicaciones Móviles

‍

Las pruebas en el ciclo de desarrollo

El ciclo de desarrollo es todo el proceso que se recorre a la hora de crear software. Desde que se crea una idea, hasta que finalmente se pone en producción a manos de los usuarios. Pasando por etapas de documentación, validación, estructuras, diseños, etc. En nuestro caso vamos a entrar en particular detalle sobre una de esas etapas, las pruebas. Vale destacar que todos estos conceptos son independientes de la tecnología, incluso de si estás creando con o sin código.

🖐🏼 Recuerda que por más que crees software sin código, tendrás que hacer testing y deberás tomarte este asunto muy seriamente.

‍

Test mode

Ya dada la introducción correspondiente ahora si, empezamos con el Test Mode, y para utilizarlo es necesario hacer clic en el icono de “rayo” y esperar que nuestra app haga el build. Tener en cuenta que este proceso puede tardar unos 3 o 4 minutos, un poco más si se trata de proyectos muy grandes.

‍

‍

Este modo es muy útil cuando nos encontramos en pleno proceso de desarrollo. ¿Por qué? Porque de haber errores, la mismísima pantalla de la aplicación nos alertará con mensajes rojos y alertas sobre cuál es el error, permitiendo una mejor idea de dónde está el problema y cómo solucionarlo.

Asimismo, nos permite hacer uso de la función de “Hot Reload”. Esta es una función de Flutter que nos permite re-construir nuestra APP muy rápido, solo en algunos segundos, sin esperar esos 3-4 minutos. Entonces gracias al Hot Reload, podemos modificar la APP y ver los cambios casi que en tiempo real.

Usando Test Mode deberás tener en cuenta:

• Las funciones de compras o In App Purchase no funcionan
• Las opciones de cámara no funcionan
• Las opciones de Notificaciones Push no funcionan

Run mode

En segundo lugar nos encontramos el Run Mode, que si bien en cuanto a lo que podemos hacer es muy similar al Test Mode, se diferencia en que replica lo que sería la App corriendo en un dispositivo final. Accedemos al él, tocando la flecha y dando “Run”.

‍

‍

Además, FlutterFlow permite crear un enlace para cada Run Mode y luego de activarlo podrías compartirlo con otra persona. Esto resulta muy útil si estás creando proyectos para terceros dado que podrán visualizar tus avances tal y como se vería en el dispositivo final, asombroso 😎

Preview mode

El Preview Mode es my util cuando te encuentras en la etapa de diseño. No construye la Aplicación, por lo que no tendrás que esperar esos 3-4 minutos. Ahora bien, eso implica que tampoco utilizará datos ni podrás interactuar con el backend, es solo a efectos de diseño de la interfaz. Accedes mediante el ojito que indico a continuación.

‍

‍

En resumen:

• Utilízalo si: estas diseñando la interfaz o probando animaciones y no te interesa que se cargue ningún tipo de información de usuario.
• No lo utilices si: estás probando los flujos de backend o lógica de negocio.

Errores y Warnings

FlutterFlow nos indica dos tipos de issues o problemas mientras estamos desarrollando nuestra aplicación. En este panel de problemas tendremos, Warnings (alertas) y Errors (errores). La principal diferencia entre ellos es que si bien con alertas podemos construir nuestra App e incluso lanzar una nueva versión, no ocurre así con los errores. Los errores deben estar todos resueltos pare poder construir o hacer build de nuestra APP, ya sea en el Test Mode o en Run Mode.

🖐🏼 Los errores deben estar todos resueltos pare poder construir o hacer build de nuestra APP

En ambos casos, alertas o errores, al tocarlos nos navegará a la sección donde ocurre el problema con el fin de poder solucionarlo.

‍

‍

‍

Herramientas Adicionales

Si bien podemos poner mucho esfuerzo en mitigar errores, nunca nos va a faltar el momento en el que luego que nuestra APP ya esté en manos de usuarios, nos damos cuenta algo funciona mal. A continuación quisiera mostrarte cómo podrías mitigar estos impactos, incluso cuando ya has lanzado tu app o tu nueva versión.

Remote Config

Remote config es uno de los servicios dentro de la suite de Firebase y está integrado en FlutterFlow, es muy fácil de usar. Nos permite controlar variables de forma remota, es decir, sin la necesidad de tocar nuestra APP o nuestro proyecto en FlutterFlow. Quizás te preguntes ¿Pero de qué me sirve esto? Bueno te explico:

Imagina que liberas una nueva versión de tu aplicación con esa funcionalidad que tus usuarios tanto han solicitado. Luego de transcurridos tres días, notas que un error hace que la nueva funcionalidad no esta funcionando como lo esperado y para eso tienes que: primero, detectar donde está el problema, luego solucionarlo y por último iniciar un nuevo proceso de liberación, o sea, armar versión, enviar a revisión y finalmente publicar.

Gracias a remote config podrías definir un parámetro asociado a la visualización de tu nueva funcionalidad en la APP, del tipo show-feature con valores, true -false. Si detectas el error, es simplemente cambiar el parámetro a false y detienes el problema, menos usuarios enojados y ahora puedes trabajar tranquilo en la corrección del bug, de nada 😛 .

Liberaciones parciales

Tanto Apple como Google ofrecen dos herramientas que puede salvarte de varios dolores de cabeza. Las liberaciones parciales permiten liberar de forma parcial tu aplicación cada vez que subes una nueva versión a las tiendas. Esto hace que la actualización se instale de forma progresiva en los dispositivos y puedas detener el lanzamiento ante cualquier inconveniente que detectes. Tienen un funcionamiento un poco diferente entre Google y Apple pero te comentaré a continuación:

• En Google deberás manualmente incrementar el % de los usuarios que recibirán la nueva actualización, pudiendo revertir el deploy en cualquier momento siempre que no hayas llegado al 100%.
• En Apple, funciona de una forma más “auto gestionada”, Apple irá liberando de forma progresiva la nueva versión a tus usuarios durante un período de 7 días. El primer día al 1%, el segundo al 2%, el tercero al 5%, el cuarto al 20%, etc.

Cuando se trata de mitigar errores esta resulta una herramienta muy poderosa dado que podrías evitar arruinar tu reputación como desarrollador, algo que cuesta tanto construir.

🖐🏼 Las liberaciones parciales permiten liberar de forma parcial tu aplicación cada vez que subes una nueva versión a las tiendas.

‍

Una funcionalidad por vez

En términos generales, aconsejo desarrollar de a una funcionalidad a la vez. Esto para que el espacio de pruebas sea más acotado y tengamos más control sobre lo que estamos haciendo testing. Si son muchas las novedades a probar, probablemente perdamos el control o incluso obviemos aspectos importantes. Una vez que te aseguras que todo funciona como lo esperado, lo aconsejable es cerrar esa versión y comenzar a trabajar en la siguiente.

Hasta aquí este artículo. Espero que les sea de utilidad para poder encarar la etapa de pruebas desde otra perspectiva mitigando al máximo la ocurrencia de errores no deseados.

Nos leemos en el próximo artículo 👋🏼

‍