Além dos patrocinadores, quero deixar também o meu agradecimento a todos os oradores, que se esmeraram na qualidade das apresentações, para aqueles que não estiveram presentes no evento deixo aqui as apresentações , excepto a do João Saleiro que já fez o favor de nos disponibilizar a sua.

Estamos também a contar ter esta semana os vídeos da apresentação assim que tiverem na nossa posse disponibilizaremos aqui no blog.

Apresentação do Luis Martins:

Apresentação Enrique Duvos:

Apresentação Nuno Godinho:

Apresentação Ricardo Castelhano e Ricardo Fiel:

Mais uma vez obrigado pela participação de todos, e quero desde já deixar aqui uma noticia em primeira mão, se gostaram deste evento preparem-se porque vêem ai novidades, como por exemplo a presença do Joshua Davis, num próximo evento nosso, além de muitas outras que estão na manga, acreditem este ano irá ser o ano da nossa RIAPT.

Só tive acesso ao artigo após ter dado entrada na gráfica, pelo que, na minha opinião, há algumas passagens que poderiam ter ficado mais precisas – nomeadamente, ser referida a Microsoft e não ser referida a Adobe (!!!), dar em alguns pontos a sensação de que as RIAs são gratuítas, e confundir-se algumas características que pertencem geralmente às Web Applications como características das RIAs. Ainda assim o artigo refere e bem a importância das RIAs para o negócio.

Coloco abaixo a entrevista original, que é mais específica e pormenorizada, podendo ser muito útil para elucidar algumas questões mais ligadas ao negócio que são feitas habitualmente por quem quer saber mais sobre o assunto. Curiosamente, estas são as questões que me são habitualmente feitas pelos clientes. Recordo que a entrevista não foi feita para publicação mas sim para ajudar o autor do artigo, pelo que poderão haver algumas “gralhas” de português.

A entrevista original

1- O que são as aplicações RIA?

Rich Internet Applications são aplicações com um interface gráfico, funcionalidades e interacção semelhantes ao de uma aplicação desktop, tal como o Microsoft Word, mas que correm dentro do web-browser. Imagine que não precisaria de instalar o Microsoft Word, sendo que para o usar bastaria abrir um endereço no seu web-browser. O endereço http://www.buzzword.com/ pode ser tomado como um exemplo de um processador de texto colaborativo no formato RIA.

2- Porque surgiram estas aplicações?

Este tipo de aplicações surgiu de uma evolução natural do software. Hoje em dia queremos aceder aos nossos dados e aplicações de qualquer local, dispositivo, e sistema operativo. Queremos simplicidade, não ter que passar pelo processo de instalação de software nem termos que nos preocupar com manutenção. Numa empresa, por exemplo, é penoso ter que instalar software em centenas ou milhares de computadores, dar manutenção, fazer actualizações, e por aí adiante – implica elevados custos, e demasiado tempo perdido. Daí as empresas hoje em dia terem convergido para o modelo de “Web-Application” – aplicações baseadas em html que correm remotamente sem terem que ser instaladas nos terminais. Infelizmente, as web-applications apesar de práticas possuem limitações a nível de interface gráfico e funcionalidades, sendo complicado imitar a interacção e objectividade do software desktop. As RIAs são no fundo o próximo passo: pegar no melhor das aplicações Web e das aplicações Desktop e juntar num único conceito.

3- Quais os seus objectivos principais?

As RIAs objectivam o mesmo que qualquer outra solução de software: resolver problemas. O cliente tem um problema, e precisa de uma solução. Essa solução pode ser desenvolvida no modelo “Desktop Application”, no modelo “Web Application”, e agora no modelo “RIA”. Portanto a nível de requisitos funcionais, os objectivos são os mesmos: resolver os problemas de negócio.
Porém, no que toca aos requisitos não funcionais – que se prendem com as características tecnológicas das aplicações – pretende-se com as RIAs disponibilizar software acessível de qualquer local e computador com ou sem restrições de segurança sendo dado especial destaque ao Interface Gráfico e interacção com o utilizador com vista a que o software seja o tão fácil de usar quanto possível. Regra geral é desdenhada a importância do interface gráfico e simplicidade de utilização, sendo esse um dos primeiros pontos que os clientes cortam no investimento – porém, surge a questão: de que serve software que funciona se ninguém o souber usar eficientemente?
Outra característica comum nas RIAs é que facilitam a colaboração: é possível que várias pessoas trabalhem sobre os mesmos dados ao mesmo tempo. Este é por exemplo o principal ponto forte do Buzzword: permite que várias pessoas estejam a trabalhar sobre o mesmo documento, algo que actualmente com o Microsoft Word não é possível.

4- Quem produz essas aplicações (empresas estrangeiras, portuguesas)? Há empresas a trabalhar exclusivamente nelas?

Sobretudo empresas estrangeiras. Posso referir com convicção a Cynergy Systems (http://www.cynergysystems.com/), líder mundial na matéria, a Fantasy Interactive, mais dotada no lado criativo (http://www.fantasy-interactive.com/) e a EffectiveUI (http://www.effectiveui.com/).
Em Portugal o conceito ainda é recente, e só agora se começa a ver algum interesse – em parte, um pouco graças aos www.riapt.org. Sei que existem algumas consultoras interessadas em apostar na matéria devido a contactos regulares que tenho recebido com questões sobre as tecnologias de desenvolvimento, procurando por técnicos especializados, ou solicitando a minha disponibilidade para dar formação e prestar serviços.
Enquanto estive em Madrid no Adobe onAir Tour – um evento sobre o assunto – conheci a Buzz-ID (http://www.buzz-id.com/), uma PME portuguesa que começa a dar cartas interessantes nesta matéria. No meu caso pessoal, comecei em 2005 a reunir esforços para criar uma equipa especializada na matéria – a Webfuel. Nestes dois anos estivemos essencialmente a reunir o know-how, a definir workflows e a preparar-mo-nos para o mercado. Neste momento falta simplesmente o “clique” – os clientes e projectos certos – para o arranque definitivo. (Neste momento já demos o clique e já ninguém nos pára )

5- A quem se destinam estas aplicações?

Estas aplicações são como quaisquer outras aplicações, portanto o destinatário é simplesmente qualquer utilizador de software que precise de uma ferramenta para o ajudar em algo. As RIAs podem portanto destinar-se ao end-user – que precisa por exemplo de ferramentas de manipulação de imagem, de processamento de texto, de agregração de informação, colaboração, etc – ou ao negócio em si – qualquer aplicação de business intelligence. Obviamente que os principais interessados serão aqueles que querem tirar partido do facto de não terem que instalar as aplicações podendo usá-las a partir de qualquer local e dispositivo mas sem se quererem limitar à típica “web application” baseada em HTML. Muitas empresas estrangeiras que trabalham com SAP começaram a desenvolver a camada de front-end das suas aplicações em tecnologias de desenvolvimento de RIAs – como o Adobe Flex -, integrando com os backends SAP existentes. A título de curiosidade, a SAP disponibiliza um livro exactamente sobre a integração com o Adobe Flex, e aborda os conceitos de RIA: http://www.sappress.com/product.cfm?account=&product=H1951

6- Quanto custa a sua criação?

Em termos de negócio, a diferença de uma RIA para outra aplicação reside sobretudo na camada de front-end. O investimento no backend é exactamente o mesmo, sendo que este simplesmente irá expôr os seus serviços tal como anteriormente na forma de Web-Services ou outra solução de comunicação (como o Flash Remoting). O investimento adicional é feito sobre a camada de front-end que implica colocar na equipa de desenvolvimento especialistas em design, interaction design, usabilidade e user experience. Porém, face ao custo total das aplicações habituais, o investimento adicional é ligeiro, facilmente suportável e perfeitamente justificado.

7- Qual o lucro/retorno que as empresas que criam estas aplicações obtêm ou esperam obter?

O ROI não é sobretudo dirigido a quem desenvolve o software, mas a quem o usa. As empresas que criam estas aplicações não são diferentes das outras empresas de desenvolvimento de software. Simplesmente, investiram numa área de ponta, inseriram na sua equipa criativos e especialistas nas plataformas de RIAs, de forma a desenvolver software que resulta na satisfação do cliente pela sua simplicidade de adopção e utilização.
Porém, empresas de desenvolvimento que criem as suas próprias aplicações genéricas podem usufruir de um novo modelo de negócio de distribuição de software denominado de “pay-per-use”. Ao invés de venderem um pacote que o cliente tem que comprar e instalar no seu computador, simplesmente disponibilizam a aplicação na Internet que pode ser usada através de um fee mensal, anual ou simplesmente pontual. (Faltou referir o modelo de negócio Software as a Service). A manutenção é feita simplesmente actualizando a aplicação no servidor central, sendo benéfico para quem desenvolve e para quem usa. Obtém-se um modelo de negócio mais fácil de gerir, e mais justo para ambas as partes. Uma vantagem que interessa realçar é que neste modelo não é possível piratear software. O que o utilizador compra é um acesso periódico à aplicação, pelo que a única hipótese para um pirata é roubar o acesso a outra pessoa.

Em certos casos específicos, também se pode adoptar um modelo de negócio de revenue-sharing, em que a empresa que desenvolve recebe parte dos lucros que a empresa que utiliza gera através do produto de software.
Outro modelo de negócio que não acho tão interessante, é a remuneração por publicidade, em que são colocados anúncios no meio da aplicação. Porém, é uma solução que a meu ver apenas se justifica em aplicações relacionadas com redes sociais online, e que para o negócio em si não faz sentido nenhum.

8- Que género de aplicações vão ser reformuladas para o formato RIA?

Quaisquer aplicações que não estejam dependentes das limitações da largura de banda actual, ou das restrições de segurança dos plugins das tecnologias em que se baseiam as RIAs. A título exemplificativo, podemos ir desde backoffices, CRMs, aplicações B2B, B2C às simples aplicações e ferramentas destinadas ao end-user, como processadores de texto, folhas de cálculo ou editores de imagem.

9- Quais as vantagens/desvantagens deste tipo de aplicações para as empresas clientes?

O custo de instalação de software desktop em centenas ou milhares de computadores é alto. No caso das aplicações empresariais, temos uma redução drástica no custo de deployment, na medida em que basta colocar a aplicação num servidor HTTP, e a partir daí milhares de terminais ficam com a aplicação disponível através do web-browser.  Além de que, ao se eliminar o passo do deployment, também se obtém um time-to-market muito menor, diminuindo o gap desde o momento em que se fechou o desenvolvimento até ao momento de início da sua utilização em ambiente de produção.
Na manutenção consegue-se novamente obter uma redução drástica de custos, visto que basta dar manutenção a um único ponto: o servidor HTTP onde é disponibilizada a aplicação. Ao actualizar essa aplicação, actualiza todos os clientes “em simultâneo”.

Quanto à sua utilização, o facto de regra geral serem dotadas de melhores interfaces gráficos resulta numa maior produtividade por parte dos seus utilizadores que se sentem mais confortáveis com a aplicação. Outra ponto que interessa realçar é que as RIAs são muito mais eficientes que as típicas web-applications no que toca à troca de informação com o servidor, obtendo-se tempos de espera muito menores.

Imaginemos por exemplo uma aplicação de B2B de gestão de stocks e encomendas. Um distribuidor pretende que os retalhistas com quem trabalha possam usar uma aplicação do distribuidor para fazer reposição de stocks. Se essa aplicação for uma RIA o distribuidor terá somente que entregar ao retalhista o URL da aplicação, com as respectivas credenciais de acesso. O retalhista simplesmente terá que utilizar o seu web-browser para abrir a aplicação, fazer o login, e utilizá-la. Isto é algo que acontece actualmente com as aplicações web, mas no caso das RIAs o retalhista irá usar algo que é realmente uma aplicação, com um interface gráfico e interacção em tudo idênticos ao software desktop, e não um conjunto de páginas HTML que se assemelham a uma aplicação.

10- Como é feito o controlo de acesso e a segurança às redes RIA?

Os sistemas de controlo de acessos e a segurança são em tudo idênticas às actuais aplicações Web. Os paradigmas e preocupações são exactamente os mesmos, pelo que não há alteração nem no investimento nem no know-how necessário. Qualquer aplicação distribuída, seja ela desktop, web, ou ria, que troque dados num canal deverá garantir que esse canal é seguro através de algumas técnicas habituais – como o https.

11- Não há riscos acrescidos de pirataria informática e uma espécie de terrorismo financeiro (caso haja bases de dados financeiras disponíveis na rede)?

Não mais que o risco actualmente existente quando utiliza um sistema de home-banking, como o CaixaDirecta. Porém, é natural que com a proliferação das aplicações RIAs surjam empresas com lacunas a nível de desenvolvimento e segurança e seja complicado para o utilizador distinguir se deve confiar nessa empresa/aplicação ou não. Mas como sabe que pode confiar no seu sistema de home-banking?  Os riscos dependem sobretudo da seriedade e experiência da equipa de desenvolvimento, e do investimento que foi feito em segurança.

No caso de aplicações críticas, estas podem e devem ser colocadas a correr em ambientes controlados, em que a aplicação está acessível somente dentro da rede da empresa. O acesso externo poderá ser concedido em condições especiais, como por exemplo, VPN’s, ou a partes limitadas do sistema consoante as credenciais do utilizador.

12- Como irá funcionar a utilização destas aplicações?

Simples: abre o seu browser, que regra geral vem equipado com um plugin como o Adobe Flash Player ou Microsoft Silverlight e coloca o endereço da aplicação. Por vezes pode ser necessário fazer um login, mas a partir daí a utilização da aplicação será em tudo idêntica à utilização do seu software habitual. Existem algumas pequenas limitações nos plugins que raramente se notam, mas independentemente disso estou convicto que até ao final deste ano até essas limitações estarão completamente ultrapassadas. (Falava do Flash Player 10)

13- É sabido que algumas das aplicações são open-source e outras são pagas. Como são definidas as que terão custos e o que as tornam pagas?

Cabe a quem desenvolve tomar essa decisão. Tem exclusivamente a ver com o modelo de negócio escolhido, e com as vantagens e desvantagens dos modelos de licenciamento de software aberto ou fechado. Há casos em que o software open-source é completamente justificado. Por exemplo, a empresa decide disponibilizar gratuitamente o código fonte sendo as receitas geradas pelo suporte e formação. Ou ainda, porque desenvolveu um produto para optimizar o seu negócio (i.e. as receitas são resultantes do negócio e não da venda do software), e acha que se disponibilizar o código fonte do seu produto este irá melhorar com o tempo graças à participação de outras pessoas, resultando consequentemente numa mais valia para o seu negócio que se torna mais eficiente à medida que o software é melhorado.

Porém, está é uma questão que não é inerente às RIAs, mas a qualquer tipo de software.

14- O que se espera do mercado das aplicações desktop? Vai entrar em falência?

Não acredito. Simplesmente vai ter que se adaptar a uma nova realidade, em que o destaque está nos dados e não na aplicação, e aprender a co-existir com as Rich Internet Applications. Começa a surgir um novo conceito, o de Rich Desktop Application. Uma Rich Desktop Application (RDA) consiste numa aplicação que é instalada no nosso computador, mas que regra geral é composta essencialmente por um interface gráfico. Os dados e a camada de negócio encontram-se num servidor remoto. E porque queremos instalar uma RDA no nosso computador, se podemos usar uma RIA? Porque podemos não estar sempre ligados à Internet, e não queremos deixar de usar as nossas aplicações quando a ligação está indisponível -  neste caso, quando a ligação é reposta, os dados são sincronizados com o servidor. Ou simplesmente porque as RDAs não estão limitadas pelas restrições de segurança das sandboxes dos plugins sobre as quais assentam as RIAs, permitindo uma maior integração com o sistema operativo.

Como disse atrás, o destaque hoje em dia está nos dados e não na aplicação em si. O que o utilizador quer é ubiquidade: manipular os seus dados a partir de qualquer local, independentemente do sistema operativo, dispositivo, ou meio de acesso. O que é criado pelas equipas de desenvolvimento são diferentes terminais: Desktop, Web, RIA, ou mesmo aplicações móveis, mas todos eles acedem e manipulam os mesmos dados. Tecnologias de desenvolvimento de RIAs como o Adobe Flex permitem facilmente criar uma RIA, e depois reutilizar o código para criar uma RDA (neste caso, assente sobre Adobe Air).

15- Existem problemas de compatibilidade entre máquinas e sistemas informáticos (ex: PC e MAC)?

A compatibilidade de acesso a uma RIA é definida pelo suporte do plugin sobre o qual a RIA assente nos diferentes sistemas operativos.
O Flash Player, por exemplo, é actualmente suportado em Windows (XP, Vista, 2003, 2000, ME e 98), Linux, Macintosh e Solaris, com uma penetração na ordem dos 95% (http://www.adobe.com/products/player_census/flashplayer/version_penetration.html) . A versão Lite do Flash Player pode ainda correr em dispositivos móveis, mas implica a criação de source code específico para essa versão.
O Microsoft Silverlight é actualmente suportado em Windows (Vista,2003, XP) e Mac OS. Está a ser desenvolvido suporte para Linux, e para dispositivos móveis com Windows Mobile 6 e Symbian S60.
A Adobe possui ainda uma tecnologia denominada Adobe Air que permite transformar uma RIA numa RDA dando-lhe funcionalidades adicionais de integração com o sistema operativo. O Adobe Air é compatível de forma idêntica em todos os sistemas operativos, tal como o Flash Player.

Em resumo, uma das vantagens das RIAs é efectivamente o facto de que não está dependente do sistema operativo.

Aconselho vivamente a leitura desse post para facilitar a compreensão deste.

Após esse post, uma das principais questões que me fizeram, foi “e como transportar dados no evento?”.

Exemplo

Imaginemos um site com a seguinte estrutura:

• Stage
• Stage.seccaoDeProdutos
• Stage.seccaoDeProdutos.listagem
• Stage.seccaoDeProdutos.listagem.itemProduto1
• Stage.seccaoDeProdutos.listagem.itemProduto2
• Stage.seccaoDeProdutos.listagem.itemProduto[n]
• Stage.seccaoDeProdutos.produtoDetalhe

Pretende-se que a classe Listagem detecte cliques nos produtos. Sempre que há um clique num produto, a classe SeccaoDeProdutos deve ser informada e reagir, removendo a listagem, e mostrando o ProdutoDetalhe com os dados do produto clicado.
Graças ao post anterior, já sabemos como resolver a primeira metade deste problema (reagir ao clique, remover a listagem, e mostrar o ProdutoDetalhe), como se demonstra adiante:

Reagir ao clique

Exemplo do Listagem.as

// Considerando que listaDeProdutos é uma matriz com instâncias da
// classe Produto (id:Number, designacao:String, descricao:String, foto:String)
for (var i:Number=0; listaDeProdutos.length>i; ++i)
{
var p:ItemProduto=new ItemProduto(); // Criar um ItemProduto
p.dados=listaDeProdutos[i]; // Colocar os dados do produto dentro do ItemProduto
addChild (p) // Colocar o ItemProduto no ecrã
p.addEventListener(MouseEvent.CLICK, produtoClickHandler);  // Detectar os cliques no itemProduto
}

private function produtoClickHandler(ev:MouseEvent):void
{
dispatchEvent(new Event('produtoClick'));
}

No SeccaoDeProdutos.as:

var l:Listagem=new Listagem();
addChild(l);
l.addEventListener('produtoClick', listagemProdutoClickHandler);

private function listagemProdutoClickHandler(ev:Event):void
{
trace('Agora bastaria remover o listagem, e instanciar o ProdutoDetalhe com os dados do produto clicado');
trace('Mas... qual é o produto clicado????')
}

Transportar dados

Entramos agora na segunda parte do problema: como entregar à classe SeccaoDeProdutos o produto que foi clicado?

A solução consiste em criar um Custom Event: uma classe nossa que estende a classe Event, e pode por isso levar mais propriedades – sendo assim usada para transportar informação de um lado para o outro.

Na solução acima, no produtoClickHandler, fazemos dispatchEvent(new Event(‘produtoClick’)); Se interpretarmos esta linha de código, vemos que está a ser lançado um evento do tipo “Event”, com o tipo “produtoClick”. É aqui que queremos lançar um evento nosso, que vamos ter que criar previamente, como se explica adiante.

Criar um Custom Event

Criar um Custom Event não é mais que criar uma classe que estende a classe Event. Vamos assim criar a nossa classe ProdutoEvent:

ProdutoEvent.as:

package
{
import flash.events.Event;
public class ProdutoEvent extends Event
{
public function ProdutoEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
}
}

Transportar dados no Custom Event

O código acima é o suficiente para definir um novo evento. Porém, ainda não chega para o nosso caso: queremos que o nosso evento possa transportar dados. Assim, a solução passa simplesmente por adicionar uma propriedade pública ao nosso evento:

ProdutoEvent.as:

package
{
import flash.events.Event;
public class ProdutoEvent extends Event
{
public var produto:Produto;
public function ProdutoEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
}
}

Agora que temos o evento criado, já o podemos usar. Alteramos assim o código do Listagem.as :

Listagem.as:

private function produtoClickHandler(event:MouseEvent):void
{
var produtoEvent:ProdutoEvent=new ProdutoEvent('produtoClick');
produtoEvent.produto= (event.currentTarget as ItemProduto).dados   ;     // Vamos colocar dentro do nosso evento (ev.produto) os dados que vamos buscar ao ItemProduto clicado (ev.currentTarget as ItemProduto), que estão na propriedade dados, como vimos no código inicial
dispatchEvent(produtoEvent);
}

Agora na classe SeccaoDeProdutos.as, temos que apanhar o tipo certo de evento no handler, e já conseguimos aceder aos dados transportados. Basta fazer a seguinte alteração:

SeccaoDeProdutos.as:

private function listagemProdutoClickHandler(ev:ProdutoEvent):void
{
trace('Agora bastaria remover o listagem, e instanciar o ProdutoDetalhe com os dados do produto clicado');
trace('O produto clicado foi: ' + ev.produto.designacao + ' TARAAAAM!');
}

Temos com isto um evento que pode carregar dentro de si dados preenchidos na classe que o lança, para que possam ser usados pela classe que o apanha.

Criação de tipos no Custom Event

O código acima já resolve o problema, mas pode ser melhorado de forma a evitar a string “produtoClick”. O ideal seria conseguirmos obter o mesmo comportamento que temos com a classe MouseEvent: fazermos algo como MouseEvent.CLICK em vez de escrevermos à mão “produtoClick”.

Para isso basta criarmos dentro da classe ProdutoEvent constantes estáticas do tipo String, uma para cada tipo de evento possível. Por exemplo:

ProdutoEvent.as:

package
{
import flash.events.Event;
public class ProdutoEvent extends Event
{
public static const VIEW:String="view";
public static const DELETE:String="delete";
public static const UPDATE:String="update";
// etc... colocar aqui todos os tipos que quisermos aplicar à classe ProdutoEvent
public var produto:Produto;
public function ProdutoEvent(type:String, bubbles:Boolean=false, cancelable:Boolean=false)
{
super(type, bubbles, cancelable);
}
}
}

Agora quando quisermos preparar um ProdutoEvent, deixamos de fazer:

var ev:ProdutoEvent=new ProdutoEvent('produtoClick');

e passamos a fazer:

var ev:ProdutoEvent=new ProdutoEvent(ProdutoEvent.VIEW);

Para escutarmos o evento, deixamos de fazer:

l.addEventListener('produtoClick', listagemProdutoClickHandler);

e passamos a fazer:

l.addEventListener(ProdutoEvent.VIEW, listagemProdutoClickHandler);

Criei um exemplo completo que demonstra a aplicação prática da explicação acima. Se a minha explicação não tiver sido suficiente, espero que o exemplo ajude a perceber a criação e utilização de Custom Events.

• MDM Zinc em 20 minutos por Paulo Moreira
• SVN e Flex pelo novo evangelista da Adobe, Mihai Corlan
• Construção de uma aplicação com Cairngorm por João Fernandes

A apresentação do Mihai será assistido no local através de uma sessão de connect.
No final do evento, será sorteado uma licença de um software da Adobe.
As inscrições para participar deverão ser feitas aqui.

Vou falar apenas do processo que acontece por detrás de um adicionar um botão como child a um container (Box) com o simples código:

O Flex, procederá da seguinte forma:

1. É chamado o componente construtor (new Box e depois new Button)

2. Chamado o setter (b.label=) e actualizado todo o componente ( muitas das vezes são chamados métodos de actualização para definirem todo o layout: invalidateProperties(), invalidateSize(), ou invalidateDisplayList() )

3. Adiciona como child (filho) do box. Aqui o Flex faz a maior parte do trabalho, executando-se a  seguinte ordem:

4. Define a propriedade parent do componente para fazer referencia ao seu “container”.

5. Calcula e define o estilo/”style” de todo o componente.

6. Dispara o evento preinitialize do componente.

7. Chama o método createChildren() do componente.

8. Chama os métodos invalidateProperties(), invalidateSize(),  e invalidateDisplayList() para obrigar a serem disparadas/chamadas os métodos commitProperties(), measure(), ou updateDisplayList() no próximo evento render. A única excepção a estes acontecimentos, é que o flex não chama o método measure()  quando o “user/programador” define a altura e largura do componente.

9. Dispara o evento initialize no componente. Nesta altura todos os childs (childrens) no componente são inicializados, mas o componente ainda não foi correctamente definido no seu tamanho, nem processado o seu layout. Este evento pode ser usado para definir /executar procedimentos extra no componente antes que seja completamente processado.

10. Dispara o evento childAdd no componente “pai” / “parent”.

11. Dispara o evento initialize do seu componente “pai” / “parent”.

12. Durante o próximo evento render o flex faz as seguinte acções:

• Chama o métodos pela seguinte ordem:

1. commitProperties();
2. measure();
3. layoutChrome();
4. updateDisplayList();

• Finalmente é disparado o evento updateComplete no componente.

13. O Flex, depois deste processo ainda poderá disparar eventos de renderização ( render ) se os métodos commitProperties(), measure(), ou updateDisplayList() forem executados/chamados através dos métodos invalidateProperties(), invalidateSize(), ou invalidateDisplayList().

14. Depois do ultimo evento render ser chamado, o flex executa as seguintes acções:

• Coloca o componente visível ( .visible=true; ).
• Dispara o evento creationComplete no componente. O componente é dimensionado e processado para o layout. Este evento é apenas disparado uma única vez e só quando o componente é criado.
• Dispara o evento updateComplete no componente, este evento também é disparado quando são alteradas quaisquer definições do componente, como layout, posição, tamanho ou qualquer alteração das características visuais.

A maior parte do trabalho de configuração, definição, e renderização de um componente acontece que este é adicionado a um container ( método addChild() ), isto porque enquanto o componente não for adicionado a um container, o Flex não consegue saber o seu tamanho, definir as propriedade “in-line”/”inheriting” ou desenha-lo no ecrã.

Perceber estes passos é essencial para conhecer  as propriedades e as operações que são executadas aquando da criação de um componente. Ajuda-nos também a perceber melhor porque é que às vezes temos certos erros no nosso código bem como a entender o processo de criação de um componente, o que se torna muito útil para criarmos o nosso próprio componente.

Artigo original aqui (EN)

Este artigo está disponivel em pdf para download. (link externo – www.msdevstudio.com)

Todos sabemos que por vezes torna-se bastante difícil encontrar artigos e suporte em português, e embora o flex esteja já instalado no mercado, continua-se a encontrar pouca informação composta em algum lado, contando apenas com alguns (bons) blog’s, e algumas poucas (listas/grupos) onde podemos tirar as nossas duvidas.

Foi basicamente por isso que decidi criar um pequeno tutorial de instalação e como criar um exemplo “Olá Mundo”  (parte I), mas como tive bastante “feedback” das pessoas, acabei por continuar o tutorial, estando neste momento na parte 5 (inacabada e não publicada) que brevemente será aqui colocada também.

Venho então dar a conhecer o tutorial Adobe flex a partir do zero que oficialmente coloquei no meu blog, e que agora partilho com o riaPT visto ser a maior referência nacional em ria’s (pelo menos não conheço outra). Neste momento o tutorial vai a meio mas deixo já o download das primeiras quatro partes compiladas num ficheiro e deixo também o index  do que já foi feito mas melhor identificação, passo então a citar:

1. Observações iniciais. Pag. 4- 5
2. Instalando, configurando e fazendo o típico teste “hello world”. Pag. 5-6
2.1. Criando um novo Projecto. Pag. 6-7
2.2. Entendendo o espaço de Trabalho do Flex Builder. Pag. 7-10
2.3. Criando o primeiro exemplo “hello world”. Pag. 10-11
2.3.1. Criando um script (AS3). Pag. 12-14
3. Entendendo a ordenação e estruturação do código.Pag. 14-16
3.1. Criação de um ficheiro action script externo para uso no flex. Pag. 16-18
4. Entendendo os componentes internos, states e transições/efeitos. Pag. 18-20
4.1. States, entendendo a sua disposição. Pag. 21-22
4.2. Transições e seus efeitos. Pag. 23-24
5. Programação do exemplo “olá mundo” em Action Script. Pag. 25-27
6. Efeitos e eventListners. Pag. 27-32
7. Componentes e Módulos.Pag. 33
7.1. As diferenças entre componentes e módulos. Pag. 33
7.2. Criando um componente e trabalhando com ele. Pag. 34-36
7.3. Enviando e recebendo dados de/para um componente. Pag. 37-38
7.4. Criando um módulo e trabalhando com ele. Pag. 38-41
8. Entendendo a comunicação com Objectos Remotos.Pag. 42
8.1. Instalação do amfPHP e servidor Wamp. Pag. 42-43
8.2. Criando o primeiro serviço no amfPHP. Pag. 43-44
8.3. Configurando o Flex Builder para trabalhar com o amfPHP. Pag. 44
8.4. Criando o primeiro Remote Object no Flex. Pag. 45-46

Podem fazer o download do pdf aqui ou ver a versão online nas publicações http://issuu.com acedendo aqui

Espero que seja útil, e qualquer critica ou correcção estejam à vontade para me informar.

EDIT: A parte 5 já está disponivel para download aqui

Experimentem a clicar nos ícones. O menu pode ser usado tanto no Flash CS3 como no Flex.

Para usarem o menu nos vossos projectos, basta que:

1. Coloquem na pasta do vosso projecto o ficheiro MacMenu.as;
2. Coloquem no stage os ícones que pretendem que façam parte do menu. Tenham o cuidado de centrar as imagens no ponto 0,0 por causa do zoom;
3. Façam o seguinte código:

var listaDeIcones:Array=[m1, m2, m3, m4, m5, m6];

var menu:MacMenu = new MacMenu(listaDeIcones);

addChild(menu); // Por causa do enterFrame. Preferia evitar esta solução, mas por agora...

Onde m1, m2, m3, etc, são o nome das instâncias dos vossos ícones.

O menu possui três parâmetros de configuração:

• ratio: define a distância de reacção ao rato. Quanto menor o número, mais próximo precisa o rato de estar para que os ícones reajam. Exemplo: menu.ratio= 130;
• escala_maxima: define o zoom máximo que os ícones terão. Exemplo: menu.escala_maxima=1.2;
• escala_minima: define o zoom mínimo que os ícones terão. Exemplo: menu.escala_minima=0.5;

Decidi separar o código de reacção aos cliques retirando-o da classe MacMenu, isto porque podem querer criar as vossas próprias reacções aos cliques. Se no entanto quiserem usar as do exemplo acima (no clique, o ícone fica com um brilho e começa aos saltos), precisarão da classe GlowReactor e da pasta caurina:

1. Copiar para o vosso projecto a pasta caurina;
2. Copiar para o vosso projecto o ficheiro GlowReactor.as;
3. Fazer o seguinte código:

new GlowReactor(listaDeIcones);

Algumas das práticas usadas no exemplo são discutíveis, mas recordem-se que foi feito em meia hora com fins educativos. Ainda assim, espero que vos agrade e seja útil.

O código fonte pode ser descarregado daqui.

Começo com um dos maiores erros que costumo ver, especialmente em antigos programadores Actionscript 2: a amaldiçoada utilização do parent (o antigo _parent) ou do stage (o antigo _root).
Este post aplica-se tanto a Flash CS3 como a Flex. O código está puramente em Actionscript 3, mas o raciocínio é exactamente o mesmo para MXML.

O caso

Imaginemos a seguinte imagem:

Temos o Stage. Dentro do Stage, temos um menu e duas secções: seccaoA e seccaoB. Dentro do menu temos dois botões: opcaoA e opcaoB. Ou seja:

• Stage
• Stage.menu
• Stage.menu.opcaoA
• Stage.menu.opcaoB
• Stage.seccaoA
• Stage.seccaoB

Queremos que quando o utilizador clique na opcaoA, a seccaoA seja mostrada, e que aconteça o mesmo para a opcaoB e seccaoB.

O código, para os adeptos do “parent”, parece óbvio:

(Dentro do Menu):

// Construtor
public function Menu()
{
opcaoA.addEventListener(MouseEvent.CLICK, opcaoAClickHandler);
opcaoB.addEventListener(MouseEvent.CLICK, opcaoBClickHandler);
}

function opcaoAClickHander(ev:MouseEvent):void
{
parent.seccaoA.visible=true;
parent.seccaoB.visible=false;
}

function opcaoBClickHander(ev:MouseEvent):void
{
parent.seccaoA.visible=false;
parent.seccaoB.visible=true;
}

Aparentemente isto resolveria o problema de uma assentada só. Porém…

Os problemas do parent

Infelizmente está 100% incorrecto utilizar o parent. A regra é simples: é *proibido* usá-lo. Surgiu um problema que obriga à utilização do parent? Repense! Leia este post, e veja como se resolve.
E obviamente perguntará: porque é que está incorrecto?

Problema 1: Reutilização

O seu menu está um espectáculo: é um dos preferidos na sua empresa tanto que o quer utilizar em vários projectos.

Entretanto aparece um novo projecto onde vai usar o menu. Porém foi outro elemento da equipa que fez a seccaoA e seccaoB, mas…. deu-lhes outros nomes. Chamou-lhes “seccao1″ e “seccao2″. E agora, que faz?

Primeira opção: mudar os nomes dados pelo seu colega (seccao1 e seccao2) para seccaoA e seccaoB. Big mistake: infelizmente o outro elemento da equipa tinha feito imenso código que usava intensivamente os nomes “seccao1″ e “seccao2″. E agora vai fazer o quê? Mexer no código dele? Não me parece…

Segunda opção: mudar no seu código onde está parent.seccaoA para parent.seccao1. Parece uma boa ideia dado o exemplo que fizemos aqui, mas se se tratasse um menu altamente complexo que usasse imensas vezes “parent.seccaoA”, seria lógico (e rápido) estar a mudar em todo o lado para seccao1 ?

Ok, é teimoso e estaria disposto a mudar o seu código todo… Porém, ao fazer isto, em vez de ter um menu que está a reutilizar entre projectos, na realidade acaba por estar a criar vários menus diferentes. Isto porque para cada projecto terá que mudar o código de cada menu de acordo com os nomes das secções. Ou seja, no fundo é um menu diferente com código diferente por projecto…

Problema 2: Refactoring

O seu projecto está feito e parece terminado. Porém, agora aparece o chefe a dizer “Ah e tal, vocês fizeram isto mal. Não quero a seccaoA dentro do Stage, mas sim dentro de um MovieClip chamado SectionContainer que tem uma borda e uns efeitos giros”. E lá vão vocês criar o SectionContainer, e colocar as secções lá dentro. Entretanto compilam e… Erro!

O código antigo do menu referia-se a parent.seccaoA. Porém, com a alteração, a seccaoA neste momento pode ser acedida assim: parent.sectionContainer.seccaoA. E com isto lá ter que ir mudar o seu código (e rezar para que o menu não seja complexo ao ponto de ter que mudar 23423423 linhas…).

A solução: componentes fracamente acoplados

A solução é relativamente simples, e passa por se cumprir uma regra também ela simples:

« Um componente/”MovieClip” nunca pode saber nada sobre quem o usa. Um componente/”MovieClip” só é responsável por si próprio »

Por outras palavras, se dentro do Menu está a fazer “parent.seccaoA”, quer dizer que o menu sabe que existe uma secção fora de si chamada seccaoA – sabe mais do que deveria saber.

Então como posso fazer: “quanto se clica na opcaoA, quero mostrar a seccaoA” se o menu não pode saber que há uma seccaoA ? Ora, o menu não tem que mudar para a seccaoA mas sim avisar quem o está a usar que está na altura de mudar para a seccaoA. Avisar como? Através de eventos!

Lançar e apanhar os eventos

O raciocínio passará a ser então:

1. O utilizador clica no botão, o que despoleta um click e respectiva chamada da função opcaoAClickHander
2. O opcaoAClickHandler deverá avisar o componente externo que está na altura de mudar para a seccaoA, lançando um evento chamado por exemplo “opcaoAClick”
3. O Stage deverá estar a escutar eventos do tipo “opcaoAClick”, e quando os apanha chama a função menuOpcaoAClickHandler
4. O menuOpcaoAClickHandler deverá conter o código necessário para mostrar a secção correspondente e esconder as outras.

Assim, o código correspondente:

(Dentro do Menu):

// Construtor
public function Menu()
{
opcaoA.addEventListener(MouseEvent.CLICK, opcaoAClickHandler);
opcaoB.addEventListener(MouseEvent.CLICK, opcaoBClickHandler);
}

function opcaoAClickHander(ev:MouseEvent):void
{
dispatchEvent(new Event("opcaoAClick"));
}

function opcaoBClickHander(ev:MouseEvent):void
{
dispatchEvent(new Event("opcaoBClick"));
}

(Dentro do Stage, que está associado a uma classe chamada Index):

// Construtor
public function Index()
{
menu.addEventListener("opcaoAClick", menuOpcaoAClickHandler);
menu.addEventListener("opcaoBClick", menuOpcaoBClickHandler);
}

function menuOpcaoAClickHandler(ev:MouseEvent):void
{
seccaoA.visible=true;
seccaoB.visible=false;
}

function menuOpcaoBClickHandler(ev:MouseEvent):void
{
seccaoA.visible=false;
seccaoB.visible=true;
}

Ou seja, se só o Stage é que sabe que existem secções, só o Stage é que pode mudar de secções. Então o menu simplesmente lança um aviso “olha, está na altura de mudar para a seccaoA”. O Stage apanha o aviso, e faz então o que é necessário para mostrar a secção correspondente.

Mais correcto ainda, seria criar um Custom Event, que possuiria uma String como propriedade pública onde seria colocado o nome da secção. Porém, isso fica para uma posterior lição.

Conclusões

• Qualquer componente ou MovieClip nunca pode saber *nada* sobre quem o está a usar.
• Não usar o parent.
• Não usar o parent.
• Não usar o parent.
• Sempre que surge um caso de “aqui ficava mesmo bem um parent”, usamos o dispatchEvent como descrito acima.

Desta forma, o nosso menu já não sofre de problemas de reutilização nem de refactoring:

• se quisermos usar o menu noutro projecto, é só colocá-lo noutro projecto: não é preciso mudar o código do menu, pois este é completamente independente do projecto onde é usado;
• se o projecto sofrer alterações de estrutura, é só alterar o projecto sem mexermos no menu: não é preciso mudar o código do menu, pois este é completamente independente do projecto onde é usado.

É de realçar que este raciocínio não deve ser aplicado só a menus, mas a TUDO. Vai usar o parent? Esqueça. Use o dispatchEvent!

• Serge Jespers & Enrique Duvos – Intro to the Adobe RIA Platform / FB3 features and AIR 1.0 features /Adobe Open-source strategy
• Carlos Rovira – Using Flash and Flex Together
• João Fernandes – BlazeDS e LCDS
• João Saleiro – Integração de aplicações Flex com PHP através de AMFPHP (Flash Remoting for PHP) e o código fonte

Vou ver ainda se consigo que me entreguem os vídeos das apresentações, embora não saiba se será possível.