Ejemplo de CycleFramework

Hola a todos, ya iba siendo hora de que las estrellas se alineasen para que en primer lugar, escribiese mi primer post y en segundo, que subiésemos por fin un ejemplo de CycleFramerwork.

Aunque el framework es muy sencillo de usar, sí somos conscientes de que a priori puede resultar complejo comprender la potencia que tiene sin tener un ejemplo de código, en el que se resuelvan los problemas cotidianos de la vida del desarrollador.

Para esto, os hemos preparado un ejemplo en el que podéis ver una gestión de usuarios clásica, con todos los problemas que esta conlleva. Para facilitar el seguimiento del ejemplo, os recomiendo que tengais a mano la documentación en PDF de CycleFramework. Además, nuestro Alberto ha diseñado y skineado la aplicación de ejemplo para que podáis ver y disfrutar de su buen gusto, al igual que lo hacemos nosotros día a día con su buen hacer .

Lo primero que veréis es una pequeña pantalla de login sin validar que os permitirá entrar directamente al pulsar el botón de enviar. Si seguís el caso de uso, veréis que llegamos hasta la clase ExampleServiceFacade.as.

Aunque el framework sólo se centra en la gestión de las vistas, y para el tratamiento y organización de las llamadas a negocio se suelen usar otros frameworks como Cairngorm, nosotros preferimos una arquitectura propia en la que mediante una o varias fachadas de negocio, tenemos acceso a los  servicios que expone una aplicación servidora. Esto unido a un modelo con ciertas peculiaridades hace que de forma automática se gestionen las peticiones que no requieren de tratamiento, dejando en el modelo los datos recibidos.

En futuras versiones de CycleFramework, esta planificada una ampliación que contemple esta metodología, de forma que se consiga crear un framework integral en el desarrollo de aplicaciones Flex.

Hecha esta aclaración para que podáis seguir el ejemplo, continuemos con la explicación.  De vuelta a ExampleServiceFacade vemos que se ejecuta el método login, sin realizar comunicación alguna con servidor. En caso de realizarse, sería aquí donde invocaríamos a un servicio ofrecido por un RemoteObject, HttpService o cualquier otro que se os ocurra.

En este caso se instancia un objeto de la clase User y se deposita dentro del modelo en la variable loginData. Esta notación tiene que ver con el sistema de manejo automático de peticiones, el cual no se explicara en este post.

Pero, cómo es posible que sólo con un cambio el loginData la aplicación haya cambiado y ahora estemos viendo el “alta de usuario”, bien ahora es el momento de abrir ExampleViewController.as, esta clase al heredar de ViewController nos permitirá de forma fácil, asociar cambios en la vista cuando suceden cambios en el modelo. Esto lo conseguiremos haciendo uso de dos métodos: addWatcher y addHandler.
El primero lo usaremos cuando con el cambio de una variable del modelo (sin importar lo que contenga) queremos navegar a un estado de la aplicación. El segundo lo usaremos en los casos en los que sí que dependemos del valor que cambia para navegar a un estado u otro.

Claros ejemplos de esto pueden ser:

addWatcher(ExampleResponseModel.getInstance(),"getUsersData",
                   new ArrayCollection(['vm','userManager',"retrieve"]));

Donde vemos que cuando en getUsersData se deje una lista de usuarios, siempre querremos navegar al listado de usuarios.

addHandler(ExampleResponseModel.getInstance(),"loginData",loginHandler);

Pero en el caso del login, podemos querer, dependiendo del perfil de usuario, navegar a uno u otro estado de la aplicación, con lo que para estos casos especiales usaremos el método addHandler, que nos permitirá usar un manejador a medida para estos cambios de la vista, que en última instancia tienen que estar controlados por el desarrollador.

Aunque en el ejemplo no se hace uso de ExampleServiceController.as, esta clase tendrá un funcionamiento muy similar a ExampleViewController.as, sólo que en este caso lo que queremos es tener organizados los refrescos de datos en función de cambios en el modelo. Ejemplo de esto, puede ser que tras realizar un alta de usuario, recibimos del servidor el usuario creado, pero queremos que la aplicación navegue al listado de usuarios y refresque los datos.

En este caso añadiríamos en ExampleServiceController un handler para que cuando llegue el usuario creado se pida de nuevo la lista de usuarios. A su vez en ExampleViewController tendríamos un watcher al listado de usuarios del modelo para navegar a la vista del listado de usuarios.

Con lo que así tendríamos cerrado el caso de uso de una forma elegante y sencilla, además de realizar de este modo todas las acciones cuando tenemos los datos, creando una experiencia de usuario mejorada, ya que los pintados en pantalla serán siempre limpios y sin “parpadeos”.

Ahora os toca a vosotros investigar, espero que os quede todo claro y en el caso de que no sea así, sólo decidlo para que podamos aclarar todas vuestras dudas. Y como se dice en mi tierra,

“en fin Serafín, que más corre el galgo que el mastín, más si el camino es largo, más corre el mastín que el galgo”