Flex 4 “Gumbo” preview

En los próximos meses se va a acabar de desarrollar la cuarta versión de Flex, nombre en clave “Gumbo”. Aunque todavía quedan aspectos por definir ya disponemos de información final y suficiente como para apreciar las mejoras que ésta va a aportar al flujo de trabajo.
En esta entrada se traducen las características más destacables sin entrar en detalle de tal forma que se pueda tener rápidamente una idea generalizada de la nueva arquitectura y las diferencias con respecto al actual modelo.


Antes de empezar es importante aclarar qué es Gumbo.
Esta nueva versión de Flex, internamente bautizada como “Gumbo”, no es un nuevo set de componentes o una ampliación del set existente, sino una nueva arquitectura sobre la que se podrán construir componentes y aplicaciones.
Los objetivos de esta nueva versión de Flex son principalmente el ofrecer una arquitectura más modular, que permita potenciar la productividad y que saque partido de las nuevas funcionalidades y optimizaciones del Flash Player.

Facilidad de diseño

Gumbo plantea una nueva arquitectura en la que se separa claramente la vista de la lógica funcional del componente. Esto ayuda a definir con mucha más claridad la línea que separa estas dos facetas del desarrollo de aplicaciones.
Un nuevo espacio de nombres MXML 2009 alberga una serie de mejoras y añadidos en lo que respecta a la gestión de layout, estados y transiciones.
Por otro lado un nuevo formato de archivo FXG proporciona una nueva metáfora para la declaración de gráficos y efectos que además de ser de fácil uso está pensada para ser soportada por distintas herramientas ya en desarrollo (Thermo, Flex) o todavía por venir.

Composición

Ésta clara separación entre vista y lógica permite que de forma trivial los componentes puedan ensamblar funcionalidades entre si o simplemente descomponerse a sí mismos para simplificarse según sea requerido. En resumen mayor versatilidad.
Además de la facilidad de composición la nueva arquitectura facilita todavía más la extensibilidad de los componentes en relación a su predecesor (Flex 3).

Productividad

Mejora considerable del rendimiento del compilador con el nuevo SDK.
Soporte para automatización de Flex en AIR.
Una implementación de CSS más completa con soporte para asociación de múltiples selectores (separados por un espacio) para definir el estilo de un mismo componente, soporte para referenciar descendientes e hijos y finalmente soporte para selectores id.

Interoperatibilidad entre Halo y Gumbo

Gumbo, aunque utiliza las mismas clases base que Halo introduce algunas nuevas. Por otro lado la infraestuctura horizontal tal como la gestión de focos, drag and drop, etc… será la misma en ambos modelos.
Gumbo va a proporcionar una base suficiente para que progresivamente se pueda migrar el set de componentes de los que se dispone en Halo (modelo Flex 2, 3) a la nueva arquitectura, pero en esta primera iteración no todos los componentes de Halo van a ser migrados. Se habla de que se dispondrá de aproximadamente unos 10 componentes Gumbo para esta primera release.
Cabe anotar que la forma en que se ha ideado Gumbo permite la cohexistencia de ambos modelos (Gumbo / Halo) en una misma aplicación.

Evolución del framework

Gumbo está preparado y de hecho solo funcionará con el nuevo Flash Player 10 nombre en clave Astro. Esto significa que Gumbo va a utilizar las nuevas características disponibles en Astro de forma generalizada.
Se utilizan las características del nuevo motor de renderizado de texto como el texto bidireccional y se incluirá un nuevo componente de vídeo que va a sacar partido de las novedades disponibles en este campo.

Recursos

Esta recopilación de información es una vista de pájaro de lo que va a ser Gumbo.
Para más información podéis revisar las fuentes e incluso descargar el SDK completo disponible en el sitio web de Adobe.

13 Comentarios

  1. Zarate

    “Facilidad de diseño”

    Esto, viniendo de Adobe y sus componentes hay que tomarlo con una sonrisa como poco. Todas y cada una de las versiones de los componentes era el día de su presentación “muy fácil de skinnear, no como la versión anterior”.

    Es sonrojante el tiempo que le está llevando a Adobe sacar un juego decente y sin bugs de componentes. A mi por lo menos me lo parece.

    Yo ya he dicho que para mi deberían estar integrados en el mismo player y automáticamente disponibles para todo el mundo, lo mismo que la clase Math o cualquiera de las otras.

    Ya, ya sé que entonces arreglar bugs se complicaría mucho, pero yo *nunca jamas* he oido que un navegador tenga un bug de funcionamiento en un RadioButton, un CheckBox o un TextArea. Y si Mozilla, Opera e incluso hasta IE6! llegaron a ese nivel, no me puedo creer que Adobe no.

    Y ya, también sé que no piensas lo mismo Joan : P

  2. Carlos Rovira

    Hola Zárate,

    Dale un vistazo al nuevo framework Gumbo, te recomiendo el video de Ely. Creo que Gumbo comparado con Halo, que es lo que venimos viendo desde los tiempos de Flaash MX 2004, es realmente un avance en ese aspecto.

    En cuanto al tema que comentas de distribución con el Flash Player, ahora tienes el cacheo de RSLs…es un punto intermedio entre ambas posiciones no?.

  3. Joan Garnet

    Hola Zárate,
    esta vez de verdad se ha llegado a un punto muy interesante. Sabes que en la versión 5 te volveré a decir lo mismo :p pero es que la experiencia y la evolución permiten que cada versión sea mejor que la anterior. Sino estaríamos arreglados no? 🙂
    En cuanto a lo de incluir el framework en el player no es garantía de que no contenga bugs, así que creo que la solución del “cacheo” es a la práctica equivalente a tu propuesta pero sin todos los inconvenientes derivados de la misma, como mantenimiento de compatibilidad entre versiones, aumento del peso del player, etc..
    Estoy contigo en que un set de componentes debe ser 99.9% bug free y que a menudo esto no ha sido así, sobretodo con los productos de Macromedia y ya ahora no tanto con Adobe. A ver si ahora que el SDK es open source la gente se anima a enviar sus parches y acelerar el proceso de mejora del producto. ¿Te animas? :p

    Un saludo!!

  4. alek

    Astro tiene alguna relación con AS4 o simplemente es != ?
    Tengo que “des-aprender” muchas cosas desde la version flex 2 que conozco con respecto al novísimo framework Gumbo? de verdad , creo que empiezo a hacerme viejo para esto…

  5. alek

    Mi consejo para los que comienzan es …aprender AS3/4 , OOP, Patrones, UML y dejar para el últimisimo momento el tema del MXML pues está en constante cambio .Acabo de leer un articulo sobre transiciones,estados y JUER!! no solo cambia por completo sino que ahora es casi intuitivo despues del palizón [ahora absurdo] que me dí para aprender estas tontuneces….

  6. Zarate

    Sé que peco de cabezón, pero voy a seguir : )

    El cacheo de los componentes no me parece la solución, me parece que complica la cosa y mucho. Quicir, suponiendo que la implementación del cacheo en el player sea *perfecta* a la primera (y es mucho suponer), ahora hay que explicarle a los desarrolladores todo el lío y cómo va el proceso. Que si cacheo, versiónes, sandbox de seguridad, crossdomains… MUCHO LIO para un problema TAN sencillo.

    Todo mi razonamiento viene de aquí: Los componentes son BÍSICOS, tan básicos como la clase Math o DisplayObject y por eso deberían estar en el player.

    Es más, todo el tema del skinning no estoy ni siquiera seguro de que sea correcto desde el punto de vista de la usabilidad. Un usuario de HTML sabe perfectamente qué es un radio y qué no, qué es un combo y qué no.

    Pero es que además lo que yo propongo no sería excluyente. Es decir, los componentes básicos estarían disponibles para todos, quien quiera utilizar unos propios ADELANTE, exactamente igual que ahora.

    Explícale a uno de HTML que tiene que cachear los radios, los combos y los textareas…. no cuela.

    Que alguien me explique por qué todo el tema del cacheo tiene sentido para Flash y no para HTML. Una buena razón y me callo : )

    Salud!

  7. Pingback: riactive.com » Recomendaciones para la semana…

  8. Joan Garnet

    @alek: Gumbo no tiene que ver con AS4 directamente, es una arquitectura mejorada del sdk de Flex. Eso si, utiliza de forma generalizada las nuevas características de Astro (FP 9) como no podía ser menos 🙂
    El lightweight/scalable framework que comentas se va a desarrollar sobre la arquitectura de Gumbo, pero no está planeado para esta primera release. Gumbo se adoptará de forma progresiva en distintas fases para que no sea un cambio demasiado traumático.

    @zarate: la solución del cacheo no tiene implicaciones demasiado complejas y es equivalente en funcionalidad a lo que propones, simplemente se trata de una cache interna del player exclusiva para determinados contenidos signados por Adobe como por ejemplo las distintas versiones del sdk de flex y en el futuro puede que incluso otras librerías de terceros. Gran parte del proceso es automático y sencillo de llevar a cabo.

    Que un set de componentes sea algo básico es una opinión muy personal, pero los desarrolladores de juegos dirán que algo básico es soporte completo para 3D y que los componentes no los quieren para nada, otros dirán que más codecs de vídeo, otros que más soporte para audio, etc… lo realmente básico en última instancia son las herramientas que nos ofrecen las APIs del player, que nos ofrecen una funcionalidad base suficiente para que nosotros podamos construir sobre ella las librerías que creamos convenientes.

    Todo lo que sea buscar soluciones para evitar cargar el player y mantener su tamaño al mínimo necesario es a mi parecer bueno, y el sistema de cacheado creo que es una buen ejemplo de ello.
    Es mi opinión personal 🙂

  9. llops

    Lo siento Zarate, pero yo también discrepo de meter los componentes en Player 🙂

    En mi caso, la razón para oponerme es justamente la contraria a la tuya: los componentes son algo muy específico. Entiendo que para un desarrollador Flex los componentes son algo prioritario, pero el Flash Player no es sólo de los “Flexeros”. Por ejemplo, en mi caso, en los últimos casi 3 años no he utilizado ningún componente (a excepción de un picker, para ser sinceros). Sólo hay que mirar sitios como el FWA para ver que los componentes no son algo intrínseco del Player…

    Saludos!

  10. Pingback: MadeInFlex » Blog Archive » Descarga Flash Builder 4 y Flash Catalyst

  11. Pingback: Flash Builder 4 y Flash Catalyst en labs : Joan Garnet :: Arquitectura y desarrollo RIA

  12. Pingback: Cómo trabajar con Flex 4 Gumbo en Flex Builder 3 « Consultoria y formacion Adobe

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Acerca de Made In Flex

Made In Flex es una comunidad de desarrolladores de Apache Flex creada en 2006.

Apache Flex, anteriormente conocido como Adobe Flex, es un SDK (kit de desarrollo de software) para crear aplicaciones enriquecidas - multiplataforma basadas en Adobe Flash donado por Adobe a la fundación Apache in 2011 y promocionado a proyecto de primer nivel en Diciembre de 2012.

Actualmente estamos cambiando muchos aspectos del sitio web para ofrecer un sitio útil para toda la comunidad que tenga en cuenta las necesidades actuales.

Últimas Fotos

Instalador de Apache Flex

Entrar o Registrase