Para os mais atentos foi lançada a compilação de todos estes tutoriais à um tempo atrás, basta procurarem no blog, que teve algum sucesso o que me levou a escrever uma segunda parte apenas em pdf que distribui inicialmente consoante uma doação, e que mais tarde também foi distribuída num pequeno “giveaway” e que agora finalmente será distribuída publicamente para o publico. Esta segunda parte do tutorial será dividida em vários post’s durante algumas semanas, e no final será colocado o pdf para download… se necessita urgentemente desta segunda parte (conta com 60 novas paginas) então entre em contacto comigo no twitter ou por email justificando essa necessidade que talvez sejam dos primeiros a receber esta segunda parte gratuitamente, embora haja alguns desses contactos que possam não ter resposta não desesperem… vai ser rápido para estar completamente publicado.

Este tutorial foca o Action Script 3 Orientado para o Flex, mas na sua base a estrutura é exactamente a mesma para o flash, por isso será com certeza útil também para os amantes do flash.

Nota: Não sendo um profissional, as técnicas adoptadas podem não ser as mais correctas, podendo mesmo existir alguns erros, mas bom… se detectarem algo “anormal” me informem.

Bom, vamos então à parte 12.

Não utilizem o sistema de comentários em baixo para tirar duvidas, elas não serão respondidas aqui! Usem antes o fórum do blog disponivel em: http://forum.msdevstudio.com

Continuando… Falaremos agora de (notem que os pontos podem nao estar seguidos, a versão final sofreu pequenas alterações):

5.3. Relacionamento entre classes.

Neste momento a nossa class passa a pertencer ao grupo de classes pessoais que podemos adicionar ao nosso projecto.
Um dos pontos muito úteis é o reaproveitamento do código para as mais variadas coisas, e de entre as quais podemos usar um relacionamento entre varias classes pessoais.

Um exemplo pode ser a definição de certas constantes numa class. Vamos supor que necessitamos de ter definidos tamanhos e um titulo para vários painéis feitos pela class em cima, poderemos efectuar 2 tipos de classes para este efeito, embora para este tipo de definições possamos usar uma class sem “inicializador” (apenas servirá para definir constantes / variáveis)
[coolcode lang="actionscript"]
package teste
{
public class def
{
public const PANEL_W:int = 400;
public const PANEL_H:int = 300;
public const PANEL_TITLE:String = “Painel personalizado”;
}
}
[/coolcode]
Esta class  não necessita de ser inicializada porque apenas apresenta parâmetros fixos da nossa aplicação e não têm um constructor.

Na nossa class em cima vamos colocar em prática o uso desta nossa class, editando a class teste.as e fazendo o seguinte.
No topo a seguir aos imports coloquem:
[coolcode lang="actionscript"]
import teste.def;
[/coolcode]
e na nossa função criado() substituimos a linha:
[coolcode lang="actionscript"]
_nomePessoal=”Teste Painel “+Math.floor(Math.random()*15);
[/coolcode]
por
[coolcode lang="actionscript"]
_nomePessoal=def.PANEL_TITLE+Math.floor(Math.random()*15);
[/coolcode]
Neste momento o titulo de cada painel criado será iniciado pela definição colocada na class def:
[coolcode lang="actionscript"]
public const PANEL_TITLE:String = “Painel personalizado”;
[/coolcode]
vamos também definir o tamanho fixo do nosso painel da class, trocando na função teste() o seguinte:
[coolcode lang="actionscript"]
//definimos o painel
this .width=270;
this .height=270;
[/coolcode]
por
[coolcode lang="actionscript"]
this .width=def.PANEL_W;
this .height=def.PANEL_H;

[/coolcode]

Desta forma, todos os paineis criados pela nossa class teste terão sempre as definições :
[coolcode lang="actionscript"]
public  const PANEL_W:int = 400;
public  const PANEL_H:int = 300;
public  const PANEL_TITLE:String = “Painel personalizado”;
[/coolcode]
Este tipo de definições são muito úteis quando há necessidade de ter sempre constantes na nossa aplicação, por exemplo num caso de uma aplicação que se liga a um banco de dados, podemos guardar o host e informações de login.. neste caso, apenas com um problema. Estas constantes apenas podem ser lidas, visto que são constantes e apenas podem ser alteradas pelo criador da aplicação e compilando de novo a aplicação.

Este trabalho poderia ser feito pela class seguinte:
[coolcode lang="actionscript"]
package  teste
{
public class definicoes
{
public const PANEL_W:int = 400;
public const PANEL_H:int = 300;
public const PANEL_TITLE:String = “Painel personalizado”;

public function definicoes()
{

//constructor

}

}
}
[/coolcode]
Mas neste caso teríamos algum código inválido, ou seja, o definicoes() ira ser inicializado em vão.. não temos necessidade de o ter no código (embora o possamos ter)

O action Script 3 é tão versátil que nos permite inclusive extender uma class já feita para trabalhar com outros exemplos, vejam o exemplo seguinte que estende a nossa class de definições.
[coolcode lang="actionscript"]
package  teste
{
public class fullDef extends def
{
public const PANEL_DATE:String = “20/09/2008″;

public function fullDef()
{

}

}
}
[/coolcode]
Este método cria uma nova class fullDef que estende a nossa class def, por palavras mais simples esta class usa as definições da class def em si própria, ou seja, herda (hereditária) as variáveis da class que está a ser estendida:
[coolcode lang="actionscript"]
public  const PANEL_W:int = 400;
public  const PANEL_H:int = 300;
public  const PANEL_TITLE:String = “Painel personalizado”;

[/coolcode]

e trata-as como se fossem suas, ou seja estas mesmas variáveis estarão disponíveis na class fullDef, basta testarem da seguinte forma:
[coolcode lang="actionscript"]
var  fid:fullDef = new fullDef;
[/coolcode]

e a partir deste momento as constantes da nossa class def de definições estarão também disponíveis nesta nossa class, juntamente com a constante PANEL_DATE que adicionei em cima, pela seguinte forma:
[coolcode lang="actionscript"]
fid.PANEL_DATE;
fid.PANEL_H;
fid.PANEL_TITLE;
fid.PANEL_DATE;
[/coolcode]
De notar que uma constante não pode ser alterada depois do nosso código ter sido compilado num ficheiro .swf.

Para esse efeito usamos apenas private var, e se o formos fazer usando a  nossa class de definições e a class fullDef deveremos usar o método [Bindable] já explicado anteriormente e que vai permitir que todas as classes que utilizem a nossa class def sejam actualizados com novos valores.

Esta extensão funciona com variáveis, constantes, e funções quer das nossas classes pessoais ou das classes do Flex / Flash.

Bom, por agora é tudo… até uma próxima…

Sugestões? criticas? e porque não elogios? deixe um comentário…

Duvidas? Use o fórum.

O loop funciona de forma muito simples bem como o break, imaginem:

[coolcode]
for (var j:int = 0; j<5; j++) {
if ( j == 2)  break;
}
[/coolcode]

Este código executa o cilco 5 vezes, mas como temos um break se o j==2 ele simpelsmente só é executado 2 vezes… mas agora imaginem um ciclo dentro de outro ciclo:

[coolcode]
for (var i:int = 0; i<5; i++) {
for (var j:int = 0; j<3; j++) {
if ( j == 2) break;
}
}[/coolcode]

Neste caso, o break apenas vai travar o segundo ciclo for enquanto que o primeiro continua a ser executado, ou seja, para cada valor de I o segundo ciclo será executado 2 vezes porque tem o break==2;

Mas agora imaginem que eu quero parar ambos os ciclos quando o j==2, claro que poderia fazer o seguinte:

[coolcode]
var controlo:int=0;

for (var i:int = 0; i< 5; i++) {
for (var j:int = 0; j<3; j++) {
if ( j == 2)) {
break;
controlo=1;
}
}
if(controlo==1) break;
}
[/coolcode]

Mas iria alongar muito o meu código certo? é aqui que entra em acção mais uma dica, o label, que nor permite indicar labels para servirem de break, sendo definido pelo utilizador, é um pouco complicado explicar em palavras, por isso vejam como resolveriamos o exemplo em cima:

[coolcode]
inicial: for (var i:int = 0; i<5; i++) {
for (var j:int = 0; j<3; j++) {
if (j == 2)  break inicial;
}
}
[/coolcode]

Simples não? apenas indiquei um label 'inicial' na linha do primeiro ciclo, e quando fiz o break indiquei que o break deveria ser feito, mas saltando para o label, ou seja, saltando para fora dos 2 ciclos. Esta é mais uma dica que nos poupa bastante trabalho, principalmente em projectos grandes onde tenhamos varios ciclos executados dentro uns do outros. Estes labels também podem ser usados pelo continue mas isso fica para uma próxima dica.

Espero que seja util,

Abraço!

Para quem ainda nao sabe, o tour de flex é um aplicativo air que apresenta cerca de 218 exemplos em flex e air, que demonstra em muitas da enormes capacidades do  Adobe Flex. Depois do excelente lançamento já à alguns tempos do showcase do flex é lançado agora o Tour de flex que sem duvida aliados podem ser capazes de incentivar ao uso da plataforma flash para aplicações realmente ricas para a internet e desktop. Podem fazer o download aqui. (Para quem ja instalou o aplicativo, basta abri-lo visto que ele contém um sistema de actualização automatica.)

A minha participação está disponivel no menu em “Other Components”  orgulhosamente entre nomes como Alex Uhlmann,  Doug McCune ou Mark Shpeherd. O Titulo do aplicativos está no menu  ”Mário Santos – Graphic Data Presentation” como podem ver pelos screenshots que se seguem:

Espero que seja o primeiro de muitos, embora actualmente nao tenha muito tempo para a preparação de alguns exemplos.

Abraço.

Esta parte já foi incluída no livro aqui disponibilizado para download…

Vejamos o seguinte código de um package devidamente comentado:

package teste

{

import flash.events.Event;

import mx.containers.Panel;

import mx.controls.Label;

import mx.events.ChildExistenceChangedEvent;

import mx.events.FlexEvent;

public class teste extends Panel

{

//colocamos a imagem como embed (incoporada no nosso applicativo e definida

//com a variavel imediatamente em baixo (iconImg) disponivel na forma de class.

[Embed("flexBtn.png")]

private var iconImg:Class;

/*Esta propriedade estará disponivel como elitura/escrita por exemplo: 

meuPainel.nomePessoal */

[Bindable]

private var _nomePessoal:String;

//Disponivel como dataCriacao em modo de leitura apenas; meuPainel.dataCriacao

private var _dataCriacao:String;

//variavel temporaria usada para saber as horas/minutos/segundos usados em baixo

private var dados:Date = new Date;

public function teste()

{

//definimos o painel

this.width=270;

this.height=270;

this.x=0;

this.y=0;

//adicionamos o eventListner

this.addEventListener(FlexEvent.CREATION_COMPLETE, criado,false,0,true);

}

private function criado(evt:FlexEvent):void {

/*definimos a hora exacta da criação do painel, com recurso ao date, neste 

caso d variavel dados */

_dataCriacao=dados.getHours()+":"+dados.getMinutes()+":"+dados.getSeconds();

//adicionamos o icon ao painel

this.titleIcon=iconImg;

//verificamos se o nomePessoal foi definido

if(!_nomePessoal) {

/*se o nome nao tiver sido dados, damos um nome temporario, no caso será dados como:

Teste Painel "numero" onde o numero será um valor aleatorio entre 0 e 15, este

numero é conseguido através do Math.floor(Math.ramdom()*15); */

_nomePessoal="Teste Painel "+Math.floor(Math.random()*15);

}

/*vamos usar um label que indica o nomePessoal e a hora da ciração do painel, este

Label desaparecerá assim que forem adicionados filhos ao painel, para isso usamos 

um evenListner*/

var lbl:Label = new Label;

lbl.name="status";

lbl.x=0;

lbl.y=0;

//definimos o texto

lbl.text=_nomePessoal + " criado em: "+dataCriacao;

//adicionamos como child ao painel

this.addChild(lbl);

//event listner para sabermos quando foi adicionado um filho ao painel para

//podermos remover o label colocado em cima.

this.addEventListener(ChildExistenceChangedEvent.CHILD_ADD, remove, false, 0, true);

//despacha o evento terminado personalizado

this.dispatchEvent(new Event("btnsProntos"));

//remove o eventListner terminao, visto que apenas será disparado uma vez.

this.removeEventListener(FlexEvent.CREATION_COMPLETE, criado);

}

private function remove(evt:ChildExistenceChangedEvent):void {

//função para remover o label com o nome e hora de ciração, isto acontece quando é

//adicionado um filho ao painel.

//removemos o child 0 (é o child lbl usado em cima, é o numero zero porque nada 

//mais foi adicionado ao painel)

this.removeChildAt(0);

//removemos o event listner caso contrario se forem adicionados mais que um filho

//esta função vai remover sempre o ultimo inserido

this.removeEventListener(ChildExistenceChangedEvent.CHILD_ADD, remove);

}

/*como quero apenas que a propriedade de dataCriacao seja apenas de leitura, fazemos

apenas a função para ler esse valor, com o get, chamado getter */

public function get dataCriacao():String {

return _dataCriacao;

}

/*como quero que a propriedade _nomePessoal seja quer de leitura, quer de escrita,

tenho que dizer à nossa classe que pode disponibilizar ou receber conteudo de/nessa

variavel, fazendo isso com as funções get e set **/

public function get nomePessoal():String {

return _nomePessoal;

}

//Recebe uma string como nome

public function set nomePessoal(nome:String):void {

_nomePessoal=nome;

}

}

}

No exemplo em cima usei já uma class mais complexa, mas como está devidamente comentada será bem facil de perceber. Neste exemplo podemos entender o seguinte; É usado um Painel como base, (extends) e as suas propriedades…depois disso é automaticamente adicionado um titleIcon exemplificando atributos herdados do pai (Panel).

O que acrescentei depois foram alguns novos atributos ao nosso Painel Pessoal, como o nomePessoal e o dataCriacao, onde ambos podem ser acedidos para ler os seus valores:

trace(meuPainel.nomePessoal);

trace(meuPainel.dataCriacao);

e o nomePessoal pode ser definido:

meuPainel.nomePessoal="nome pessoal do meu painel";

Esta leitura/escrita destes valores só é possivel devido aos getter’s e setter’s que estão disponiveis nas nossas class’s, onde o get é usado em:

trace(meuPainel.nomePessoal);

e o set:

meuPainel.nomePessoal=”nome pessoal do meu painel”;

Neste exemplo em cima também vemos o uso de algumas funções matematicas (floor e ramdom) que podem ser acedidas pela class Math. De seguida adicionamos um label ao painel assim que ele é criado com o nomePessoal e a hora da sua ciração, e ao juntar um eventListener esse label será eliminado assim que seja adicionado um child ao painel. Não esquecendo também que removemos os eventListeners para não causar conflito.

Para testarem esta class basta fazerem:

import mx.controls.Button;

import teste.teste;

import mx.controls.Alert;

private var myPanel:teste = new teste;

private function init():void {

myPanel.addEventListener(“btnsProntos”, terminado);

//myPanel.nomePessoal=”Painel GRUN”; podem ou não definir o nome pessoal do nosso painel.

addChild(myPanel);

}

private function terminado(evt:Event):void {

Alert.show(“Painel e icon completos.”)

}

private function addChildMe():void {

var temp:Button = new Button;

myPanel.addChild(temp);

}

Aqui se chamarem a função init, o nosso painel é criado no stage, com o nome e hora da criação… se chamarem a função addChildMe será adicionado um botão ao nosso painel e o label que lá existia será removido automaticamente. E pronto, finalmente têm a vossa class criada que é nada mais nada menos um painel personalizado, e sem darem muito por isso já usaram métodos e parâmetros hereditários, bem como a composição que anteriormente foi explicada..

Continua…

Abraço.

Bom, dei de caras com as propriedades deepLink, que podem ser obtidas atravéz do browserManager/URLUtil, por isso fiz um pequeno exemplo que podem usar nas vossas aplicações, copiando o contudo do arquivo que disponibilizo em baixo para a raiz da vossa aplicação, depois basta fazerem o import na vossa aplicação:

São então disponibilizadas as seguintes funções:

getPort():String

getProtocol():String

getServer():String

getDoc():String

getTodo():String

getPath():String

onde para receberem os respectivos elementos devem usar:

   1: var util:urlUtils = new urlUtils();

   2: //tomando como exemplo o link: http://msdevstudio.com/immo/backend/backend.html

   3:

   4: //buscar nome do servidor:

   5: var nomeServidor:String = util.getServer();

   6: //devolve: msdevstudio.com

   7:

   8: //buscar protocolo

   9: var protocolo:String = util.getProtocol();

  10: //devolve http

  11:

  12: //buscar porta

  13: var porta:String = util.getPort();

  14:

  15: //buscar url completo

  16: var urlCompleto:String = util.getTodo();

  17: //devolve http://msdevstudio.com/immo/backend/backend.html

  18:

  19: //buscar caminho relativo 

  20: var caminho:String = util.getPath();

  21: //devolve http://msdevstudio.com/immo/backend/

  22:

  23: //buscar o nome do portador do swf

  24: var documento:String = util.getDoc();

  25: // devolve backend.html

Isto não é nada mais que um simples package que simplifica as coisas em aplicações medias/grandes e que em muitas variadas situações se torna muito util.

Podem fazer o download aqui.

fiz um package pelo simples motivo de ajudar a quem ler a perceber como um package funciona, bem como se podem tornar simples a utilização destes packages principalmente pela sua reutilização por outros programadores e outras aplicações. Podem ver o código comentado também.

Aguarda-se feedback.

Este artigo está disponivel em pdf para download.

Alem de estar sempre a par das ultimas novidades em tudo quanto é área, podemos realmente ter acesso a feed’s de sites muito bons, que revelam muito boa qualidade.

Dos cerca de 120 feed’s que tenho no thunderbird, vou começar por ir deixando uma lista de vez a quando no blog, não se assustem porque quase todos os feed’s estão em inglês mas é onde se encontra muita informação de boa qualidade (não estou a desprezar o que se faz de bom em PT)

Aqui vai:

Flex Examples (não podia faltar) – http://feeds.feedburner.com/blogspot/PmCX?format=xml

Alex’s Flex Closet – http://blogs.adobe.com/aharui/atom.xml

Beedigital – http://www.beedigital.net/blog/feed/

Building blocks – http://joelhooks.com/feed/

Digital Backcountry – http://feeds.feedburner.com/ryanstewart

Eric feminella – http://www.ericfeminella.com/blog/wp-rss2.php

James Ward – http://www.jamesward.org/wordpress/feed

Metah AS3 – http://www.metah.ch/as3/rss.php

Ntt.cc – http://feeds.feedburner.com/Nttcc?format=xml

John Nack – http://blogs.adobe.com/jnack/index.xml

Mike Potter – http://feeds.feedburner.com/adobe/mpotter

Flex Doc Team – http://blogs.adobe.com/flexdoc/atom.xml

Kiwi Project – http://feeds.feedburner.com/kiwiproject

Penguin.SWF – http://blogs.adobe.com/penguin.swf/atom.xml

Adobe Design Center – http://feeds.feedburner.com/AdobeDesignCenter

Como repararam, muitos destes feed’s pertencem a blog oficialmente suportados pela adobe e seus programadores, ou seja, quero dizer que a adobe ainda é o melhor recurso para informação de qualidade em inglês… quanto a português, brevemente coloco alguns feed’s que bons blog’s que por aí se encontram

gp:

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.

Apesar de englobar apenas os produtos cs3, tais como o Ilustrador, Photoshop, Fireworks, Bridge, Contribute, Flash e não dedicar muito ao desenvolvimento de ria’s, é interessantíssimo para todos, mesmo os programadores, para todos ficarmos a ganhar com interfaces e conhecimentos da grande vantagem do conhecimento dos produtos da adobe.

Os vídeos online resultam de uma parceria da adobe com a lynda.com que resultou num excelente trabalho.

Bom, os curiosos já estão fartos de ler, por isso aqui vai o desejado link para o “Adobe Video Workshop” e paciência para os cerca de 180 vídeos Flex Powered!!

http://www.adobe.com/designcenter/video_workshop/

Um pérola, não?!

Edit: Só agora que descobri mais referençias a esse video workshop que afinal já está online desde a segunda metade do ano passado… epah…!! ando atrasado!! mas é um boa noticia na mesma, pode ser que não seja o unico a nao saber!!

Abraço.

Depois de muito procurar e virar de “ponta-cabeça” o site da adobe não consegui encontar nada que referisse aos tais seminários que notifiquei aqui no post seminários adobe online coisa que achei bem estranha já que na altura da subscrição desses mesmos seminários era-nos dito que seriam gravados e disponibilizados para download, coisa que parece que ainda não foi propriamente feita…

Depois de algum trabalho pelos meandros de vários motores de busca lá consegui começar a colher informações de onde se encontravam estes seminários… ainda não estão propriamente disponíveis para download, mas já podem ser vistos no centro “multimédia” do Adobe Acrobat Connect.

Apenas não consegui encontrar 3 destes seminários, mas em contra-partida encontrei alguns também bem interessantes, então deixo aqui a lista:

Bem, acabou a lista, bem grande por sinal, mas com a certeza de muita utilidade!

Cumprimentos.