El documento detalla la transición de páginas web a aplicaciones cliente web utilizando Flex, destacando la importancia de la programación de interfaces y la gestión del estado. Se discute la arquitectura basada en componentes y la comunicación entre ellos a través de eventos, así como la necesidad de estructurar aplicaciones en módulos para mejorar el mantenimiento y la reusabilidad. Además, se menciona el uso de patrones de diseño, como el mediador, para facilitar la comunicación y reducir el costo de mantenimiento en aplicaciones complejas.

2. Ingeniero Civil Informático UdeC. Magíster Tecnologías de Información. UTFSM. Jefe de Proyectos de desarrollo de aplicaciones Web. Dirección de Tecnologías de Información. UdeC. Flex desde 2007 Ricardo Poblete

3. Agenda ¿Por qué este tema? Componentes Eventos Caso ejemplo Diferentes formas de diseño Performance Conclusiones

5. Compartir una de las primeras diferencias enfrentadas y que es muy recurrente. Existe un cambio en la programación de interfaces de usuario: de páginas web a aplicaciones cliente web. Es un tema transversal en casi toda aplicación Flex

6. Experiencia de aplicaciones web

7. Diferencia básica entre una página y una app.flex En una página web, el cliente es Stateless El estado de la aplicación está en el servidor Cada página es independiente de otra En una app. Flex el cliente es Statefull El estado de la aplicación está en el cliente Con Flex, el cliente tiene cargada la aplicación (o parte de ella "on demand“ Por esto, es necesario comunicar las diferentes partes ya instanciadas el cliente Flex.

9. Flex es considerado un framework basado en componentes (component - based framework) Cada elemento visual y no visual es un componente también.

10. Una aplicación Flex se puede escribir en un solo archivo mxml Problemas de mantenimiento, acoplamiento, reusabilidad, etc, tampoco se puede trabajar en equipo. Es buena práctica dividir la aplicación en módulos o componentes que realicen tareas específicas. Fácil desarrollo ( Trabajo en equipo) Mejoras en mantención Reusabilidad Divide y vencerás Crea tus propios componentes. Puedes escribirlos en tags mxml o con actionscript.

12. Flex está hecho con una jerarquia de clases Actionscript Todos los componentes visuales derivan de la clase UIComponent

13. ¿Por qué comunicar componentes? Necesitamos informar a otro componente que ha ocurrido algo Hizo clic en un objeto de la lista y el otro componente debe mostrar el detalle Se ha cancelado la operación, entonces deshacer los cambios Han llegado los datos de la BD, se debe actualizar la lista Etc Tienen algo en común Trabajan en conjunto para hacer sinergiao dar lógica a la app. Comparten información (datos) o trabajan con un conjunto de datos relacionados

15. La forma común de comunicarse es por medio de EVENTOS que se gatillan durante la ejecución de una aplicación. Las aplicaciones Flex están dirigidas por eventos (event-driven). Los eventos pueden ser causados por la interacción de un usuario y también por respuestas asincrónicas Las clases fundamentales de la arquitectura de Flex tienen definido por defecto eventos fundamentales ( updateComplete, resize, move, creationComplete, etc)

16. Veamos un componente

19. En AS3 cada evento se representa mediante un objeto de evento, que es una instancia de la clase Event o de alguna de sus subclases. Por ser una clase podemos extenderla. Creación de un objeto evento Evento:Event = new Event(); El objeto event trae consigo propiedades que lo describen

20. El objeto evento tiene propiedades, entre ellas quien generó el evento (target) y el nombre del evento (type), entre otras click creationComplete itemClick Etc Podemos crear nuestros propios tipos eventos contactoAgregado listaEliminada etc

21. Para utilizar eventos necesitamos Una instancia de la clase evento Eventos de tipos diferentes Extender clase evento para mejorarla Algo que genere el evento (dispatch) Algo que esté “escuchando” el evento (listener) Indicar lo que debe suceder cuando ocurra el evento (handler function)

22. Definir y exponer el evento en el componente Componente expone el evento que puede gatillar con tags de Metadata El contenedor del componente, al instanciarlo, define qué ejecutar cuando el componente gatille el evento

23. Definir y exponer el evento en el componente (II) Por otro lado, el componente que gatilla el evento Contenedor del evento ejecuta una función cuando detecta el evento

24. Colocar un detector (listener) de eventos El objeto o componente que desee detectar debe “inscribirse” en la lista de detectores El componente que gatilla el evento siempre lo realiza con un dispatch El componente que detecta (escucha) ejecuta la función definida

25. Extender la clase evento Hay que crear una clase propia que extienda a la clase Event, heredar las capacidades de la clase Event y sobrescribir el método clone(). UTILIZADAS PARA TRANSPORTAR INFORMACIÓN

26. Extender la clase evento (II) Para colocar un detector del evento nuevo, es necesario colocar un listener Y por supuesto la correspondiente función handler No olvidar importar la nueva clase Para disparar el evento, es necesario el dispatcher

27. Comunicación en cualquier sentido Costoso debuggin Costosa mantención

28. Muchos eventos transmitiendo datos Mismo efecto anterior, pero además Mucho mas costoso en memoria

29. Para mejorar, utilizar el patrón Mediador “ The mediator pattern is a software design pattern that provides a unified interface to a set of interfaces in a subsystem.”[wikipedia]

31. Requerimientos Desarrollar una aplicación que permita administrar una lista de contactos básica. Cada contacto debe contener el nombre completo, dirección, teléfono y categoría. Las categorías deben provenir del componente de categorías establecido en la organización.

32. Diseño Layout Aplicación principal Lista de contactos Detalle de Contacto Categorías

33. Diseño Clases Mediador Aplicación principal Lista de contactos Detalle de Contacto Categoría de contactos Event: EditarContacto Event: Contacto Aceptado, Cancelado

34. Diseño Clases eventos extendidos Aplicación principal Lista de contactos Detalle de Contacto Categoría de contactos Editar Contacto Contacto Eliminado

35. Diseño Clases Mediador Aplicación principal Lista de contactos Detalle de Contacto Categoría de contactos Event: EditarContacto Event: Contacto Aceptado, Cancelado Modelo

37. Profiler Mediator Profiler CustomEvents Profiler Model

39. Un desarrollador de Flex debe tener claro Componentes Eventos Existen diferentes formas de comunicar componentes La mejor forma dependerá del tipo de proyecto, cada una tiene pros y contras El performance es muy similar en aplicaciones pequeñas