Vi um post bastante interessante no site www.infoq.com que fala dos Top 10 de “enganos/erros/confusões” a quando da programação de uma aplicação em Flex. Este post fala de aspectos muito interessantes e importantes que devemos ter em atenção ao construir uma aplicação em Flex. Como este post se encontra em inglês, vou tentar fazer uma tradução em português, para que seja mais fácil a sua compreensão, bem como adicionar algumas opiniões pessoais. Vale a pena ler!! Começando. 1. Usar uma framework RIA para construir aplicações Web 1.0 - (Nova tecnologia, velhos hábitos)

Um dos maiores desafios a quando da mudança de aplicações web 1.0 para o desenvolvimento de Ria’s é aprender a pensar diferente. O flex disponibiliza um conjunto de componentes que permite fazer coisas que eram impensáveis e impossíveis de fazer à apenas uns anos atrás. Por vezes essa possibilidade é esquecida e a framework acaba por ser utilizada apenas para implementar as tradicionais aplicações Web 1.0. Construir aplicações Web 2.0 é mais do que um actualizar parcial de uma pagina e adicionar cantos redondos em divs. Para isso é altamente recomendado recorrer apenas ao Javascript/Ajax e Css e não desperdiçar tempo com o Flex, porque o flex deve ser usado sim para oferecer um design e funcionalidade atractiva para os utilizadores. Se já são programadores java, aprender Action Script 3 e a linguagem de interface será brincadeira de criança. O maior desafio por vezes é que os programadores não estão habituados a “desenhar” visualmente a sua aplicação, e para o desenvolvimento de ria’s é um “must-know” ter alguns conhecimentos de design. A programação pode ser muito boa, mas a verdadeira “força” do Flex está no seu aspecto visual aliado à sua versatilidade.

2. Quebrando aspectos standard dos browsers.

Enquanto o Flex providencia uma excelente plataforma para melhorar a experiência e agradar o utilizador, continua a ser muito importante manter o aspecto “familiar” do site/aplicação como os botões anteriores e seguintes do browser, bookmarking e auto-complete. Ao contrário do que às vezes se pensa, estes aspectos não são difíceis de implementar no Flex. O flex 3 já inclui propriedades “deep-linking” para suportar os botões seguinte e anterior bem como bookmark. E aspectos como o “auto-complete” pode ser facilmente implementado, até mesmo usado alguns componentes. Deep Linking @ labs.adobe.com - Flex Wiki. Auto complete; Exemplo e componente @ AutoComplete Input

3. Muitos “containers” reduzem o desempenho da aplicação.

O flash player utiliza uma hierarquia gráfica para apresentar objectos parecida com objectos DOM em HTML. Quantos mais “containers” forem usados, mais tempo leva a rederização. No centro de desenvolvimento Flex da adobe (Adobe’s Flex Developer Center) pode-se encontrar um artigo que fala das melhores práticas relacionadas com a performance do Flex, incluindo o uso de “containers”. O maior inimigo da performance do Flex está relacionado com a tentação de usar muitos “containers” para melhorar o aspecto da nossa aplicação, mas isso aumenta muito negativamente a performance do Flex. Este é o pior inimigo da performance do Flex, e felizmente é 100% contornável, bastando fazer uso moderado destes mesmos containers.

4. Usar XML para transferência de dados em protocolos (já optimizados), reduz o desempenho.

O flex oferece aos programadores um grande número de opções de comunicação entre o Flex e tecnologias servidor, incluindo AMF3, XML, SOAP, e pedido HTTP directos. Podem ver um exemplo do uso destas tecnologias bem como os “benchmarks” aqui. O BlazeDS (open source) actualmente com suporte da adobe, deve ser uma escolha quase obrigatória em projectos que usem backend em Java, fazendo uso do protocolo AMF3. O AMF é um protocolo de transferência binária que facilmente se integra com o Java, PHP, Python ou praticamente qualquer linguagem server side, recorrendo a diversas variações especificas para as variadas linguagens e que oferece muito mais fiabilidade e performance.

5. Tentar contratar um programador Flex “pode não ser a melhor nem fácil escolha”.

Programadores Flex experientes e com credenciais, ainda são muito difíceis de encontrar e os que se encontram são pagos a peso de ouro. Actualmente o Flex encontra-se em vias de adopção como foi o java nos finais dos anos 90. O pedido de programadores flex continua a exceder as ofertas o que torna muito dificil encontrar um bom programador de Flex, mas ao mesmo tempo cria uma grande oportunidade para os programadores Java e não só expandirem os seus conhecimentos e adoptar o flex como framework de desenvolvimento. Muitas empresas que procuram programadores Flex acabam por contratar pessoas que conhecem bastante bem o Java ou outras linguagens de aplicativos Web, e dada a escassez de profissionais Flex, acabam mesmo por dar ao longo de algumas semanas acções de formação de Flex já que a sua linguagem e API’s são facilmente aprendidas por qualquer pessoa que esteja já familiarizada com programação Web e GUI’s.

6. Não usar exageradamente animações e efeitos.

Usando o flash como plataforma de distribuição, facilmente um programador flex se sente tentado a usar e abusar dos “one-line-effects” que o flex traz, mas os programadores apenas devem usar estes efeitos quando eles são mesmo necessários, e nunca os usar sabendo que o utilizador se distrairá do contexto da aplicação. O uso exagerado de efeitos pode cansar o utilizador!! Os efeitos no flex, bem como as suas durações devem ser tidos em conta, e se puderem contar com uma ajuda e percepção visual de um “Designer” melhor, assim com certeza que terão uma aplicação bem mais agradável. Muitas das animações são simplesmente muito longas, lentas, chatas e por vezes excessivas. Reduzam as animações!! Se existe alguma coisa que os utilizadores não gostam é ter que esperar pelo terminar de uma animação, que por vezes nem agrada, para poderem começar a usar o aplicativo. Não se pretende terminar com as animações no flex, mas sim sensibilizar para o bom uso das mesmas. Cada animação/efeito deve ter um propósito e serem aplicados moderadamente!! Podem ver um artigo bem interessante sobre animações e efeitos aqui.

7. Não definir um “eco-sistema” na empresa.

Como em todos os trabalhos de programação de projectos de software, também no flex é extremamente importante montar um “eco-sistema” para desenvolver aplicações. O TTD (Test Driven Development, ou desenvolvimento “assistido”), é um marco em qualquer projecto de qualquer empresa. Para o Flex, o FlexUnit framework serve precisamente para programar “unit tests”. No Adobe Developer Connection, o Neil Webb discute a utilização do TTD para programadores Flex, usando o FlexUnit. (podem ver o post aqui ). Existe também o Flexcover para “code coverage reporting”, algo como “relatórios de cobertura do código”. A integração contínua (CI), está provada como sendo uma boa pratica para construir e programar Flex quando o projecto é desenvolvido por mais que um programador. Em semelhança ao Java, as plugins Ant e Maven também estão disponíveis para integração contínua de aplicações Flex.

8. Não usar a framework por completo.

Existe um número elevado de “features” opcionais no Flex que devem ser consideradas no desenvolver de uma aplicação. Por exemplo Runtime Shared Libraries (RSL) podem ser usadas para diminuir bastante o tamanho das aplicações. O tamanho de uma aplicação pode ser reduzido utilizando referencia directas a ficheiros/imagens/scritps que podem ser separadamente transferidos do servidor para a cache do computador do utilizador. Esta operação obriga que varias aplicações que utilizem estes mesmos “assets” sejam carregados na “runtime”, mas o utilizador apenas as descarregará para o seu computador apenas uma vez. Estes ficheiros/imagens/scripts partilhados são chamados de Runtime Shared Libraries. Outra das “features” pouco usadas da framework, são as características de usabilidade já incluídas no Flex. Podem ler mais sobre estas características aqui. Quem deseja realmente respeitar e usar acessibilidade nas suas aplicações, o flex torna simples essa tarefa e oferece muitas características como podem ver aqui.

9. Não usar “renderers” complexos em DataGrid’s.

O itemRenderer original para as dataGrid’s já está muito optimizado! (e por consequência ao serem alterados ou implementados irão causar diminuição do desempenho, falado no ponto 3.) O número de “item renderers” que são “compilados” pela dataGrid multiplica-se pelas linhas e colunas da tabela, criando uma enorme quantidade de código. Para minimizar esse impacto, deve-se utilizar os “itemRenderers” quando são realmente necessários e estes devem ser o mais optimizados possível. Quando itemRenderes mais elaborados e complexos são mesmo necessários deve-se usar um UIComponent (ou outras classes “low-level”) e colocar o seu conteúdo para a linha/coluna manualmente.

10. Não preparar a nossa aplicação para modo Offline.

O modelo tradicional das Ria’s é orientado para o browser, mas tecnologias como o Adobe AIR ou o Google Gears actualmente permitem que as aplicações Flex sejam executadas offline. Não preparando as aplicações para uma possível execução offline, se o utilizador/cliente a desejar em modo offline, as coisas tornam-se bastante difíceis de transformar, já que teríamos que refazer grande parte do código da aplicação. Tipicamente, aplicações de negócio/empresariais, correm num servidor. Uma ria em modo offline, permite muito mais “expansão” para o cliente/utilizador, pelo que a arquitectura da aplicação deve poder ser facilmente implementada e transformada de/para modo online/offline.

Bom, e assim termino, a tradução não foi feita à letra, mas penso que a excelente qualidade informativa do post original, mereceu este meu trabalho de “tradução.”

Foi util??

Um abraço.

Este artigo está disponivel em pdf para download.