Creación de un flujo funcional
¿Quién crea flujos funcionales?
El implementador se encarga de crear flujos funcionales en Studio.
¿Dónde trabajas?
Debes acceder a tu ambiente Studio y trabajar utilizando módulos creados para el proyecto.
Este artículo incluye guías how-to que explican cómo resolver casos de uso específicos que pueden ocurrir durante la configuración y construcción del flujo funcional. Incluye varios casos:
Si tienes flujos funcionales definidos y debes crearlos y configurarlos en Studio. Lee la documentación disponible para obtener más información sobre la creación de flujos funcionales.
Si necesitas definir errores que se activarán en el módulo que contiene el flujo funcional o en la app principal. Para leer sobre errores en la app, lee Configuración. Para leer sobre los errores en el módulo, lee Crear o editar un módulo.
Si necesitas configurar el flujo funcional y los parámetros locales de la app. Para obtener más información sobre estos parámetros, lea Parámetros locales.
Si ya creaste el flujo, lo invocaste desde la app principal y ahora quieres probarlo. Lea Testear an App para obtener más información sobre el proceso de prueba y Branching para obtener información sobre la versión de aplicaciones.
Setup
Nota
Este caso de uso se aplica tanto a apps web como móviles.
Cada ambiente de Studio viene con un conjunto de errores predefinidos que invocan procesos lambda con tokens específicos que activan diferentes mensajes. Cuando se produce un error en la app, el usuario recibe un modal con un mensaje específico que varía según el token invocado y una acción específica definida cuando ese modal se cierra.
Para manejar errores en el módulo y la app padre, se deben configurar entidades específicas en el módulo, replicando la configuración de la app. Esto varía según el canal de la app.
En el caso de una app web, el módulo debe contener:
Un modal de error local en un área oculta común. Para obtener más información, lea los Estándares de sistema de diseño.
Un proceso lambda por tipo de error que invoca una pantalla local para mostrar el error y ejecuta el siguiente proceso lambda para redirigir al usuario.
En el caso de una app móvil, el módulo debe contener:
Un error local modal a través del uso de componente emergente del sistema en una pantalla local.
Un proceso lambda por tipo de error que invoca una pantalla local para mostrar el error y ejecuta el siguiente proceso lambda para redirigir al usuario.
Nota
Este caso de uso se aplica tanto a apps web como móviles.
Para usar deeplinks, se debe configurar lo siguiente en el módulo y en la app:
En el módulo:
Duplicar el parámetro generic token launch, así como la pantalla con la vista de procesamiento y el proceso lambda de redireccionamiento.
Editar el proceso lambda para que invoque la app padre con la información del token en su mensaje, para luego ejecutar el proceso lambda que redirige al usuario.
En la app padre:
Ejecutar el proceso lambda que redirige al usuario.
Nota
El parámetro generic token launch es un número de token que contiene la información obtenida cuando el usuario hace clic en un deeplink. La configuración del generic token launch permite la asignación de tokens a través de etiquetas que actúan como parámetros invocados externamente para redirigir al usuario en el deeplink.
Para trabajar en la descarga de configuración, el comportamiento de la app debe replicarse en el módulo. Hay que hacer dos configuraciones.
En el manejo de errores locales de la app, defines el comportamiento para descargar la configuración y redirigir a la tienda de apps cuando se requiere una actualización binaria.
En el módulo, el proceso lambda que maneja errores locales redirige al usuario a la app y cierra el módulo. Como resultado, el proceso lambda que maneja errores locales en la app padre recibe el mensaje y completa el flujo.
Nota
Este caso de uso se aplica solo a apps móviles.
Para establecer un tiempo de espera de sesión, debes configurar una lógica específica en el módulo para que el usuario sea redirigido a una pantalla de app específica cuando se produzca un timeout de sesión. En el módulo y en la app, respectivamente, se deben configurar los siguientes elementos:
En el módulo:
Duplicar el parámetro local de cierre de sesión. Como resultado:
el proceso lambda que ejecuta el parámetro de cierre de sesión cierra el módulo y envía un mensaje a la app padre para que ejecute la acción definida.
el proceso lambda que ejecuta el parámetro define un comportamiento diferente para dispositivos Android, lo que hace posible ejecutar el proceso lambda en la app padre sin disparar un mensaje.
En la app: el proceso lambda redirige al usuario a la pantalla especificada.
Nota
El parámetro de timeout de sesión permite administrar el tiempo (en segundos) para cerrar la sesión de la app debido a la inactividad, y el siguiente timeout de sesión define el proceso lambda que se ejecutará si la sesión se cierra debido a la inactividad.
Building
Los flujos funcionales se crean a través de interfaces de módulos. Por lo tanto, las convenciones de nomenclatura deben cumplirse durante todo el proceso de creación del módulo. Sigue estas convenciones como se especifica a continuación:
Nombre del módulo: Si el módulo representa un flujo funcional, el nombre debe incluir la expresión Flow + la funcionalidad de dicho flujo. Usa mayúsculas para comenzar todas las palabras y sepáralas usando guiones bajos.
Nombre de interfaz: El nombre se define por la funcionalidad representada por el flujo. Usa snake_case y divide palabras usando guiones bajos.
Para obtener más información sobre nombres, lee Convenciones de nomenclatura. Además, lee Crear o editar un módulo para seguir las mejores prácticas en la creación de un flujo funcional.
Nota
Este caso de uso se aplica tanto a apps web como móviles.
El proceso de generación no se puede completar si la app tiene dependencias vinculadas a las mismas entidades en diferentes versiones (ramas). Por ejemplo, la app Veribank está vinculada al módulo A en la ramaMainy al módulo B en la rama de Test; además, el módulo A está vinculado al módulo B en larama Develop. Dado que la app Veribank y el módulo A están vinculados al módulo B en diferentes ramas, no será posible generar la app.
Sugerencia
Comprueba las dependencias cruzadas entre apps y módulos en el diagrama de dependencias de la app.
Para generar y publicar correctamente la app, debes realizar una de las siguientes tres acciones, dependiendo de tu proyecto.
Si los cambios realizados en la rama no requieren la información del módulo vinculado como dependencia en una rama diferente de la rama vinculada a la app: puedes desvincular ese módulo como dependencia, de modo que solo la app esté vinculada al módulo y no se produzcan problemas de dependencias cruzadas.
Cambia la rama a la que está vinculado el módulo. Como resultado, tanto la app como el módulo se vincularán a otro módulo de la misma rama y no se producirán problemas de dependencias cruzadas.
Revisa las dependencias de la rama del módulo (es decir, el módulo vinculado a la app padre) y crea ramas para todas sus dependencias.
Importante
Debes crear nuevas ramas para todas las dependencias de la app padre, incluso si no se realizan cambios en ellas.
Nota
Este caso de uso se aplica a las apps web.
Si las clases definidas de forma predeterminada en las apps web tienen el mismo nombre clave definido en el tema, los valores definidos en el tema se sobrescriben aleatoriamente. Es necesario cambiar el nombre de siete clases en el tema genérico de la aplicación para que no afecten a las clases definidas por defecto.
Si, según los requisitos del proyecto, estás creando el módulo y debes aplicar un tema, debes comprender la aplicación de temas y cómo funcionan con respecto a la app padre.
Las pantallas de la app heredan el tema definido en la app, vista o módulo en el siguiente orden de jerarquía: vista, módulo y app. Esto significa que: una pantalla de la app hereda el tema aplicado a la vista en la que se incluye. Si no se aplica ningún tema, hereda el tema del módulo. Por último, si no se aplica ningún tema al módulo, hereda el tema de la app.
Como estándar de uso, los módulos no deben tener temas aplicados para que hereden el tema de la app padre. En casos de negocios específicos, es posible que debas aplicar un tema específico al flujo funcional que está invocando, por ejemplo, si una sección específica de la app está patrocinada y requiere el uso de diferentes colores. Para ello, deberás ejecutar diferentes acciones en función del canal de app de que se trate.
Para una app móvil:
Dirígete al Dashboard y, a continuación, haz clic en Modules para acceder al módulo (y la rama, si corresponde) que contiene el flujo funcional.
Dirígete al menú y, en la sección Design, haga clic en Views.
Busca la vista que contiene las pantallas de flujo funcionales y haz clic en Edit (icono de lápiz).
Dirígete al campo Theme y selecciona el tema que necesitas aplicar.
Haz clic en Save.
Para una app web:
Dirígete al Dashboard y, a continuación, haz clic en Modules para acceder al módulo (y la rama, si corresponde) que contiene el flujo funcional.
Haga clic en Settings.
Dirígete al campo Theme y, en la sección Theme info, selecciona el tema que deseas aplicar.
Nota
Debe establecer un tema para el módulo, incluso si es el mismo tema aplicado a la app.
Haz clic en Save.
Nota
Para los temas, debes cumplir con las definiciones tomadas durante la etapa del sistema de diseño.
Los flujos funcionales se crean a través de interfaces de módulos. Luego, se invocan desde un componente en la pantalla de una app padre.
Después de invocarlo, siempre debes cerrarlo. Cerrar el flujo funcional, es decir, el módulo que lo incluye, es clave para la experiencia del usuario. Cerrar el flujo implica que no aparece en la pantalla de la aplicación y se elimina de la pila de navegación.
En su lugar, debes configurar el cierre de flujo en el módulo. Para hacerlo, debes configurar un un conjunto de parámetros Message. Estos mensajes serán invocados desde componentes en la pantalla de la app, que luego ejecutará una acción específica a su vez. Los mensajes que puedes configurar se enumeran a continuación:
Configura un conjunto de parámetros de mensaje en la interfaz de flujo funcional. La lista de mensajes estándar representa en qué casos se define el cierre de flujo y, por lo tanto, la redirección del usuario a una pantalla diferente. Los mensajes son:
Onsuccess
Oncancel
Onback
Ontrxfail
Onlocalfail
Configurar un proceso lambda con dos bloques:
un bloque con el mensaje que necesita; y
un bloque que se ejecuta cuando se produce el mensaje y define que el módulo debe cerrarse.
Para aprender a usar los procesos lambda, lee Procesos lambda.
Invoca el flujo desde la pantalla de la app y define el proceso lambda aplicable al mensaje invocado. Esto se configura en el modal Link to Module que aparece al invocar el flujo. Para saber cómo invocar un flujo funcional y configurarlo, lee la documentación disponible.
Para obtener más información sobre Messages y otros parámetros en la interfaz de un flujo funcional, lea Crear o editar un módulo e interfaces.