A Adobe publicou ontem uma imagem muito interessante e elucidativa para representar o ecosistema da Flash Platform. Na imagem é possível ver o universo das ferramentas Adobe, e a forma como se interligam.

À esquerda, a azul claro, temos as ferramentas de design: After Effects, Adobe Illustrator, Fireworks e Photoshop. Com estas ferramentas os designers podem criar o aspecto gráfico das aplicações / sites / experiências / etc, sendo este exportado num novo formato, o FXG. O FXG é um novo formato da Adobe baseado em XML para representar elementos gráficos, e que é compatível com o universo que circunda a plataforma Flash.

A azul escuro temos as aplicações de desenvolvimento: o Flash IDE, Flash Catalyst (anteriormente conhecido por Thermo), e o Flex Builder. O Flash IDE e o Flex Builder são os nossos já velhos conhecidos, sendo o primeiro mais virado para Interaction Designers que procuram um IDE visual, e o segundo para developers que procuram um IDE virado para código. O Flash Catalyst é uma ferramenta que ficará no meio, entre o Flash e o Flex Builder que permitirá a Interaction Designers utilizar um ambiente gráfico e intuitivo para importar layouts feitos nas ferramentas de design, e convertê-los através de alguns cliques para aplicações, podendo ser adicionada interactividade. O resultado o Flash Catalyst é MXML (bem formado, segundo dizem) que depois é entregue aos developers para implementarem toda a parte dura do código. Segundo se diz, o Flash Catalyst pode também carregar MXML já alterado pelos developers (corrijam-me se estiver enganado), pelo que permitirá que ambas as equipas – developers e designers – possam trabalhar ao mesmo tempo, recorrendo a um source control. O Flash Catalyst está ainda a um ano de ser lançado em versão final, pelo que durante este período serão certamente disponibilizadas versões beta e de preview.

A cinzento, em cima, temos o Flex SDK, a framework de eleição para desenvolvimento de RIAs. É composta por um conjunto de componentes, e ferramentas que assentam em Actionscript 3, para desenvolvimento rápido de aplicações. O Flex SDK está actualmente na versão 3, mas a versão que se segue (nome de código: Gumbo) vai trazer novidades absolutamente estontantes. Sendo open-source, é possível acompanhar o desenvolvimento do Gumbo, e inclusivé, fazer já aplicações com a actual versão. As milestones do Gumbo são:

• lançamento do MAX preview agora durante o MAX;
• versões Beta 1 e Beta 2 na primeira metade de 2009 (aposto em Fevereiro e Maio);
• versão final na segunda metade de 2009.

As ferramentas acima “não fazem mais” que gerar ficheiros SWF que são depois interpretados e executados nos devidos runtimes: o Flash Player, que corre dentro do browser, e com limitações de acesso à máquina do utilizador (obviamente por motivos de segurança), e o Adobe Air, que permite que os SWFs possam ser instalados nos computadores dos utilizadores e correr como aplicações desktop, com acesso à maquina do utilizador como qualquer outra aplicação (i.e. leitura do disco, clipboard, etc). O Flash Player está neste momento na versão 10 que introduz uma panóplia de funcionalidades fantásticas: suporte nativo a 3D, FileReference local, suporte a filtros avançados (Pixel Bender), suporte avançado a texto, melhor performance com suporte a aceleração pela placa gráfica, etc.

De referir que os runtimes acima são compatíveis com os principais sistemas operativos, nomeadamente Mac, Windows e Linux – e a grande novidades do Max: graças ao Open Screen project temos também o Flash Player 10 em Symbian, Windows Mobile, Wii, Playstation, etc.

As aplicações (SWFs) que assentam sobre os runtimes acima serão fat clients descarregados para as máquinas dos utilizadores (pelo browser, ou instalados com Adobe Air), e que poderão posteriormente comunicar com um servidor para trocar dados. Essa comunicação pode assentar em diversos protocolos e formatos, tais como simples texto, XML, SOAP (web-services), JSON, e AMF – o formato de dados em que assenta o Flash Remoting. Estes formatos podem ser trocados sobre HTTP ou HTTPs, Sockets, RTMP, entre outros.

Esta panóplia de formatos de comunicação permitem comunicar com quase todas as tecnologias server-side existentes no mercado, pelo que aplicações feitas em Flash são facilmente integráveis com plataformas existentes, sejam elas Adobe ou de terceiros. Da Adobe, temos os servidores especificamente criados para Flash: BlazeDS e Flash Media Server que introduzem funcionalidades de Data e Multimedia Streaming, entre outras. Depois temos os servidores ColdFusion e LiveCycle ES, de onde a minha funcionalidade favorita deste último é de longe o facto dos servidores poderem tomar a iniciativa de contactar os clientes e empurrar dados (i.e. dados dos clientes sincronizados automaticamente com o servidor). Apesar da Adobe fornecer as suas próprias soluções server-side, como dito acima aplicações Flash podem ser facilmente integradas com outras soluções de backend de entidades terceiras, como, PHP, JAVA, .NET, etc, desde que implementem algum dos protolocos de comunicação acima referidos. Como exemplos de plataformas, temos BEA, SAP, salesforce.com, WebSphere, Zend, etc.

Vendo esta imagem, é inevitável sentir orgulho de ter acreditado e escolhido um dia o caminho da plataforma Flash. Aquilo que começou um dia como uma ferramenta para adicionar animações a páginas Web, é hoje em dia a mais poderosa plataforma para criar aplicações distribuídas e interactivas. As nossas amigas RIAs.

No último evento do Adobe User Group, Nelson Batista fez uma pequena introdução ao Papervision3D onde explicou a composição do framework, como utilizar assim como certos erros a evitar.

Como parte dos meus estudos para a Certificação Flex 3, estou a rever alguns pontos em que me sinto menos à vontade dentro do maravilhoso mundo do Flex. Vou começar por um ponto que ainda hoje reserva bastantes dificuldades de compreensão. Falo do MVC – Model, View, Controller.

O MVC é um padrão quer de desenho quer de arquitectura usando na construção de software. O uso deste padrão é muito vasto, e entende-se como o tratamento separado da lógica de programação e a interface grafica do proprio software que resulta numa enorme versatilidade da aplicação que torna muito mais facil modificar o aspecto visual da aplicação ou o código sem criar dependencias/afectação entre eles lidando facilmente com a comunicação entre utilizador, interface gráfica e o código da nossa aplicação.

Entendendo as siglas;

• Model – Representa a informação / dados da aplicação e as “regras/definições” para manipular / trabalhar com esses mesmos dados da aplicação. No flex, geralmente class pessoais ou classes de serviços para lidar com um backend.
• View – Representa os elementos gráficos da nossa aplicação, como inputText, datagrid, textArea, no flex engloba states, viewstacks, em resumo, todos os componentes gráficos.
• Controller – Representa o tipo de controlo/detalhes que envolvem a comunicação com o Model (Dados e definições) e o View (Interfaces gráficas) estes detalhes resultam da lógica de comunicação entre o Model e o View e normalmente representam também a interacção com o utilizador.

Este padrão MVC foi adaptado por centenas de frameworks, e o Flex não escapou à adaptação sendo que o principal objectivo de uso deste MVC no Flex é a simplicidade e re-utilização do código criando componentes bem definidos que permitem a obtenção de uma enorme versatilidade de todos os eles, bem como uma fácil cominicação entre os mesmo componentes, sem falar numa optimização do desempenho da nossa aplicação.

Ao criarmos um aplicação sem nos preocuparmos com este padrão teremos uma agradavel supresa no final de a termos terminado. O próprio Flex / Framework já está baseada nesta arquitectura e possui mesmo os seu proprio padrão MVC definido, como os componentes que definem a interface do utilizador, os modelos de apresentação de dados e os componentes responsaveis pelo controlo de dados como interacções com linguagens back-end.

Tentar entender este processo no ambito do flex pode ser muito complicado, mas vamos colocar um caso lógico que explica muitas das operações do flex:

Onde estruturamos devidamente os elementos e acções deste modelo:

Model:

• Usando action script, definindo como estrutura de class.
• Geralmente são usadas varias classes para simplificação de objectivos de cada uma que englobam:
• — Classes de dados nativas
• — Serviços de comunicação com back-end
• — No AIR, classes para lidar com chamadas como o SQLite

View :

• Todas as views são componentes gráficos do flex
• Tem como principal objectivo lidar com o layout da aplicação e disparar eventos para o controller
• Não acedem a dados directamente, apenas usam dados de eventos, dataProviders ou propriedades publicas / databinds
• São geralmente componentes escritos em MXML

Controller :

• Pode existir mais que um, embora apenas seja necessário em aplicações muito complexas.
• É usado como ponte entre o View e o Model visto que estes 2 não podem comunicar entre si directamente. Algumas propriedades / funções :
• — Definir dataproviders
• — Chamadas para o Model
• — Lidar com eventos do View
• — Alternar entre views
• Não são necessáriamente Action Script, no flex os arquivos MXML podem ser elementos “Controladores”

O Padrão MVC não se trata de um programa, formula ou função, trata-se sim de uma forma de organização de código permitindo esta “triologia” de funcionamento; criando uma class controlador que recebe/lida com dados de um conjunto de classes (model) e que faz a devida actualização da nossa interface grafica/componentes (view).

Claro que esta explicação pode ser mal entendida e perdoem-me os experts no padrão MVC, mas basicamente é isto que é feito claro que com alguns pontos e detalhes como vimos em cima.

Este tipo de implementações têm varias variantes, podendo nós, devidamente estruturado, criar um padrão MVC para estruturar a nossa aplicação, embora a Adobe disponibilize o Cairngorm que simplifica muito a aprendizagem pincipalmente com exemplos de muitos sites. A sua instalação é muito simples e o seu uso e aprendizagem também. Uma grande referencia em Cairngorm é o blog o David Tucker:

http://www.davidtucker.net/category/cairngorm/

Façam download dos videos e exemplos e facilmente verão do que falo.

Bem, na estrutura do exame Flex 3 este é um dos pontos: “List and describe de differences between model, view and controller in a Flex application”, que nos pede para explicar as diferenças apontadas em cima.

Bem, por agora é tudo… fiquem com alguns pontos de referencia do meu estudo sobre MVC.

http://cristobal.baray.com/indiana/projects/mvc.html (recomendo vivamente)

http://www.wonderhowto.com

http://livedocs.adobe.com/

http://www.iteratif.fr/blog/

Abraço e pelo menos espero ter esclarecido alguém, e já agora, alguém com uma opinião ??

Post originalmente colocado em: http://www.msdevstudio.com