Mis aventuras en SAP AppGyver – desafío SAP (vol 4 – final)
Llegamos al final de esta serie, en esta entrada veremos como recuperé los datos guardados en el dispositivo y los mostré por pantalla.
También intentaré plasmar mis impresiones como desarrollador después de probar esta corriente de no-code low-code.
Si te perdiste la entrada anterior, aquí la tienes:
https://ecastella.com/mis-aventuras-en-sap-appgyver—desafio-sap-vol-3/
Sin mas, vamos a por los datos.
Recuperando datos
A medida que vamos añadiendo películas, el dispositivo tiene una lista de ids de película en el dispositivo. Así que lo que la solución fácil era implementar una lista.

Aunque la lógica utilizada es bastante larga vamos a ir por pasos.

Nos centramos en el evento «Page focused» que se dispara una vez la página esta apunto para mostrar al usuario.
Recuperando datos del dispositivo
La recuperación de los datos es tan fácil como la de guardar. Solo necesitamos el componente de recuperación de datos.

Una ve tenemos el componente, como en el caso de las APIs seleccionamos el origen de datos y también podemos hacer filtros y ordenar los registros.

Si os acordáis de la entrada anterior en el dispositivo solo guarde los datos del ID de la película, así que necesitaba recuperar el detalle de todas las películas. Otra vez tenia el mismo problema… hacer un loop para hacer cosas.

Para poder recuperar los datos finalmente, se acaba simulando un loop programado, pero con bastantes flechas. Vamos por partes.
Primero modificamos una variable de pagina llamada contador (que nos servirá para para saber en que posición de la lista estamos). Utilizaremos una formula bastante para sumar sobre la misma variable. Esta parte me pareció un poco liada usando la variable directa como entrada pero como formula haciendo referencia a que es una variable de la página:


El siguiente paso es igual que en a entrada anterior, obtener de un origen de datos remoto unos datos. En esta caso, de la API de películas. Lo primero sera definir este origen de datos.

Utilizamos el componente para obtener un registro individual:

Como tenemos una lista de IDs, haremos referencia al ID que nos interesa mediante una formula:


Una vez tenemos los datos de la API, los mapeamos a un objeto como el que tendrá la lista. Para poder hacer el mapping la solución fue crear dos variables, una tipo objeto que representa los datos de una película y otra tipo tipo lisa donde guardaré los datos de cada una de las películas.

Así que una vez leídos los datos los guardamos en esta variable mediante un mapping:


Una vez los datos los he mapeado a la variable intermedia, los añado a la lista que luego pintaré:


Por último, y para crear el loop, lo que se tiene que hacer es una condición de salida del loop. En este caso, comparando el count con el número de items que tengo en la lista:

Mediante una formula, sabemos si seguimos dentro del loop o ya podemos salir.

Pintando los resultados
Nome voy a extender en este punto ya que es el mismo que en la entrada anterior. Seleccionamos el componente tipo lista. Le añadimos la variable que tipo lista que queremos pintar y luego añadimos los datos individuales de cada registro:

Conclusiones
Una vez terminada la App, y después de unos días para pensar en el la utilidad que puede tener veo que Appgyver pues ser una herramienta útil para aplicaciones pequeñas con poca funcionalidad.
Pros
- Operaciones sencillas, es decir, seleccionar un datos, mapearlos en un componente de pantalla y tratar acciones de pantalla en función del click a los distintos componentes
- Permite hacer una app de manera rápida sin necesitar un aprendizaje intenso
- Es muy fácil integrar con sensores del dispositivo
- Publicar la aplicación no requiere nada mas allá de apretar un botón
- Tiene una gestión de versiones, por lo que no es necesario ningún repositorio externo ni conocer como se utiliza.

- Permite generar una aplicación para publicar en un market tipo iOS o Android.
Contras
- Si queremos hacer un listado con filtros, es necesario jugar con los componentes para poder hacer los filtros mediante formulas que pueden llegar a ser largas y poco intuitivas
- La gestión de versiones no tiene un descriptivo para ver que se ha hecho, solo aparece el nombre del componente
- Si necesitamos hacer operaciones en listas, la cosa puede llegar a ser un poco complicada.
- Aunque podemos personalizar los estilos, no tenemos la posibilidad de utilizar CSS, cosa que es comprensible ya que no queremos programar, pero esto nos condena a estilos muy básicos o a tener que utilizar mucho la imaginación.
- El sistema de debug es muy poco intuitivo. Aunque no he querido mirármelo mucho, cuando lo intente utilizar no me funciono.
Hasta aquí mi experiencia con Appgyver. En general si que seria una herramienta a tener en cuenta para acelerar la construcción de aplicaciones, incluso trasladando a usuarios avanzados esta construcción.
Lo que puede ser un problema es el alto coste de licencias ya que aproximadamente cada usuario activo son 10€/mes, algo que pasa en muchos servicios de SAP donde parece que cuando dictaminan el precio de una herramienta solo la tengan que utilizar 5 personas, sin contar que SAP esta implantado en empresas un un gran volumen de usuarios.
Como siempre suscribete, dale a la campanita de notificaciones y comparte en redes para estar a la última.
Gracias por la serie.
Personalmente, pienso que el tema del low code / no code es un gran acelerador a la hora de desarrollar aplicaciones, lo que no tengo tan claro es el tema de los citizen developers…
Si quieres hacer algo medianamente elaborado, necesitas tener cierto conocimientos técnicos, sí o sí.
Y si nos referimos al ámbito SAP, lo que no tengo claro es dónde queda ahora Mendix dentro de todo esto…
Un saludo.
Mi siguiente post es el 100 i tengo pensado hablar de estos temas.
Opino igual que tú, i te hago un spoiler . Un demà del que nadie habla relacionado con el citizen developer es las licencias. Las empresas no pagarán licencia para todos los usuarios, entonces qué pasará? Creo que va a salir un artículo muy crítico