Veio a publico hoje no labs.adobe.com a primeira beta do flash player 10, com bastantes novidades, de entre as quais se destacam:

• Efeitos e filtros personalizados, recorrendo ao Adobe Pixel Blender, que permite a criação de efeitos e filtros personalizados.
• Efeitos 3D.
• Novo motor de texto.
• Componentes de layout de texto.
• Tratamento de cores.
• Melhoramentos:
• Tratamento de cores
• "GPU Compositing"
• "GPU Blitting"
• Motor anti-aliasing (Saffron 3.1)
• Tipo de dados Vectorizados.
• Streaming dinamico.
• Protocolo "Real Time Media Flow."
• Codec Speex Audio.
• "File Reference."
• "Dynamic sound generation."
• Suporte a imagens de grande dimensão.
• Context menu.
• "GB18030 Compliance"
• Suporte ao OS Ubuntu.

Existem alguns demos em video e exemplos como usar efeitos e filtros do pixel blender.

Aqui ficam os links.

Pagina Oficial: Flash Player 10

Notas da versão: Release Notes

Download: Donwload Flash Player 10 (DEVEM DESINSTALAR AS VERSOES ANTERIORES)

Demos e Videos: Demos e Videos

Abraço!

Na hora de desenvolver uma Ria, muitos se questionam qual a tecnologia a usar. Para os amantes de HTML, efeitos simples e cumprimento de padrões SEO, sem duvida o Ajax se torna uma opção viável, mas para os amantes de fiabilidade, rapidez, suporte e uma interface bem agradável, o flex é a opção.

Não vou defender nenhuma destas tecnologias (ou talvez vá!) mas vou colocar algumas características bem interessantes dos 2, retiradas de alguns sites, comentários e artigos.

Vou mostrar alguns pontos, em ambas as tecnologias conforme a necessidade e deixarei a minha analise no final:

1. Animação

Em muitas das ria’s os efeitos são na realidade uma mais valia.

AJAX: Pouco suporte limitado apenas a efeitos lineares.

FLEX: Um grande suporte nativo, bem como possibilidade de personalização.

2. Manipulação de imagens

Possibilidade de manipulação, alteração, edição e efeitos

AJAX: Algum suporte, dependendo do browser e de bastante código server-side

FLEX: Suporte nativo.

3. Suporte a HTML.

AJAX: Suporte nativo.

FLEX: Suporte muito limitado, não permitindo tabelas, css, frames ou javascript

4. Video e audio streaming

AJAX: Sem suporte nativo, dependendo de plugins de terceiros

FLEX: Suportado, embora pouco usado. Suporta também captura de câmaras ou microfones do utilizador.

5. Desenvolvimento, programas e custos.

AJAX: Bastantes aplicativos livres como Google Toolkit, Echo2, jsLINB ou Rico. Existem alguns pagos, mas como são tantas as opções livres não vou nomear.

FLEX: Flex Builder Eclipse Plugin ($500 US ~ 325 €), Flash CS3 ($700 US ~ 450 €) ou um qualquer editor de texto que requer grandes conhecimentos do seu método de programação.

6. Runtime, Execução.

AJAX: Alguns pontos têm que ser programados para os diferentes browsers (alguns problemas de cross-browsers)

FLEX: Uma plugin única (flash player, que se estima que esteja instalada em cerca de 85/90% dos computadores pessoais) que permite cross-browsing e cross-plataform sem problemas.

7. Código e desenvolvimento em equipa. Linguagem orientada a objectos.

AJAX: Suporta linguagem OO em algumas frameworks, mas é sempre compilada a uma estrutura base. A maior parte de librarias não são compatíveis com outras o que causa muitos problemas.

FLEX: Compatibilidade ECMAScript, altamente suportado em aplicações WEB. O seu código é facilmente organizado e partilhado, compilado sobre a base de Action Script 3.

8. Suporte a graficos vectorizados.

AJAX: Já suportado via VML nas recentes versões do IE e apenas suportado em alguns browsers via SVG.

FLEX: Suportado nativamente (AS3).

9. Segurança e seu código.

AJAX: & FLEX: Ambos utilizam (e estão dependentes) da segurança da sandBox dos browsers.

AJAX: O seu código pode sofrer violações de terceiros visto existirem alguns reticências quanto à sua segurança.

FLEX: O código dificilmente será violado, pelo menos nas partes criticas, graças à (já por defeito) distorção do código fonte na compilação, bem como a possibilidade de encriptação.

10. Controlo DOM.

AJAX: Suportado nativamente.

FLEX: Não suportado, dependendo sempre de chamadas externas  a objectos javascript.

11. SEO (Optimização para motores de busca).

AJAX: Suporte amigável aos browsers, embora alguns browsers não sejam capazes de seguir links em javascript. Se parâmetros SEO tiverem que ser cumpridos, o AJAX deve ser cuidadosamente programado.

FLEX: Suporte limitado. As “normas” SEO podem ser cumpridas recorrendo a META TAGS e publicação separada do conteúdo.

12. Acessibilidade.

AJAX: Muito pouca, bem como poucas frameworks anunciam boas praticas de acessibilidade.

FLEX: Acessibilidade compatível com as normas 508

13. Open Source / Código Aberto.

AJAX: Existem muitas lincenças, desde livres a comerciais, variando de framework para framework.

FLEX: O flex e action script são código aberto, e até à pouco tempo a maquina virtual do flash (FVM) era fechada. Recentemente aberta como indica no projecto Adobe Open Screen.

14. Extensibilidade (componentes terceiros).

AJAX: Como o ajax é uma extensão do HTML e Javascript, a framework é por norma extensível.

FLEX: Os seus componentes são facilmente extensíveis, bem como a possibilidade de criação de novos. A plugin para o eclipse é facilmente extensível através de um grande número de extensões.

15. Suporte.

AJAX: O ajax é médiamente suportado, bem como as suas frameworks, com alguns artigos e tutoriais, embora muito ambíguos devido à variedade de frameworks.

FLEX: Grande suporte por parte da adobe, bem como pela crescente comunidade de programadores. A framework está altamente documentada com exemplos na própria pagina da adobe bem como os seus exploradores (Effects, Components e Styles)

Resumo final, como li num artigo bem interessante de onde retirei grande parte destes comparativos, depende muito do objectivo da RIA, embora concorde bastante com a seguinte frase:

“Use AJAX for tactical improvements and Adobe Flex for strategic implementations”

Onde se pode entender que o AJAX deve ser usado quando a nossa RIA necessita de updates constantes e a Ria em si é leve e pequena. Pode ser usado para acrescentar alguns “pontos de RIA” a pequenas aplicações/páginas. Mas deve ter em atenção um possível futuro de abandono de suporte de algumas frameworks, bem como uma possível reformulação dos browsers e seu suporte.

O Flex deve ser opção quando o “cross-browsing” deve ser um factor decisivo, bem como em aplicações medias-grandes. Como existe uma grande marca por detrás (Adobe), é de esperar uma elevada e crescente continuidade do suporte, muito graças à grande capacidade do Action Script e da penetração do Flash Player no mercado, ainda mais agora com a estratégia Open Screen da adobe. A possibilidade de modo offline, graças ao AIR, torna o flex muito versátil.

Nota final e opinião:

Com tudo isto que li, traduzi e aqui escrevi…volto-me mesmo para o desenvolvimento em flex, porque afinal de contas é uma paixão minha.

Espero que estas informações sejam úteis na hora critica de decidirem a linguagem/framework da vossa RIA.

    Este artigo está disponivél em pdf  para download.

Ontem tive um pequeno problema a desenvolver parte de um aplicativo (o frontend para o meu sistema imobiliário) onde necessitava de saber onde estava a correr o aplicativo, bem como o caminho relativo do servidor, já que tinha que obter varios caminhos para fotografias onde esses caminhos poderiam variar. Ou seja, precisava de saber o caminho onde as minhas fotos se encontravam, já que se estivesse a correr apenas em, por exemplo www.msdevstudio.com/immo/frontend/ saberia exactamente onde encontrar as minhas fotos, que estariam no caminho absoluto www.msdevstudio.com/immo/frontend/imgs mas o problema seria se mudasse de servidor, as fotos poderia passar a estar em www.meuserverto.com/imgs e aí teria que programar o flex para ir procurar as fotos a este caminho… mas dizem voces, porque não usar apenas source=”imgs/imgExempo1.png” ? pelo simples motivo que necessito de juntar algumas fotos a um HTML text, bem como dar a possibilidade do user mudar a directoria das imagens e os caminhos relativos. (não encontrei outra solução para já…)

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.

Que os feed’s foi a melhor coisa que inventaram eu não tenho duvida, e já à muito que uso o thunderbird como cliente de email e leitor de feed’s. (recomendo vivamente)

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:

Alterações no "core" do flex tornam-se realidade!

Não se assustem, não vamos ter que re-aprender tudo de novo, mas que se aproximam grandes mudanças é bem verdade. Finalmente vieram a publico algumas das alterações que a adobe começa a implementar no flex, estas principalmente nos states e seus componentes, segundo o artigo da adobe, disponível aqui, os states passarão a trabalhar ao contrário… passo a explicar pelo que percebi.

Antes quando mudava-mos de um state para o outro, as alterações passavam por remover elementos do state base, ou adicionar novos. Agora as coisas serão processadas ao contrário, tendo o componente o seu maior valor. Foram acrescentados alguns parâmetros de entre os quais o includeIn e o excludeFrom, que recebem como parâmetros o nome ou nomes do(s) states onde queremos esse componentes. Usando o exemplo da adobe:

   1: <!– Tendo os states A,B,C –>

   2: <m:states>

   3:     <m:State name="A"/>

   4:     <m:State name="B"/>

   5:     <m:State name="C"/>

   6: </m:states>

   7:  

   8: <!– este botão apenas aparecerá no state A e B–>

   9: <Button label="Click Me" includeIn="A, B"/>

  10:  

  11: <!– este botão aparecerá no state A e B, fazendo o inverso. –>

  12: <Button label="Button C" excludeFrom="C"/>

Para verem as diferenças, e redução do código tomem como exemplo:

Antes:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

   3:     <mx:states>

   4:         <mx:State name="newCheckbox">

   5:             <mx:AddChild relativeTo="{vbox}">

   6:                 <mx:CheckBox id="checkbox" label="Checkbox" />

   7:             </mx:AddChild>

   8:         </mx:State>

   9:         <mx:State name="newTextArea" basedOn="newCheckBox">

  10:             <mx:AddChild relativeTo="{vbox}">

  11:                 <mx:TextArea id="textarea" />

  12:             </mx:AddChild>

  13:         </mx:State>

  14:     </mx:states>

  15:     <mx:VBox id="vbox">

  16:             <mx:Button label="Click" click="currentState=’newCheckbox’" />

  17:             <mx:Button label="Click" click="currentState=’newTextArea’" />

  18:     </mx:VBox>

  19: </mx:Application>

Depois:

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <mx:Application xmlns:mx="library:ns.adobe.com/flex/halo"

   3:    xmlns:m="http://ns.adobe.com/mxml/2009" layout="absolute">

   4:     <m:states>

   5:         <m:State name="default"/>

   6:         <m:State name="newCheckbox"/>

   7:         <m:State name="newTextArea"/>

   8:     </m:states>

   9:     <mx:VBox>

  10:         <mx:Button label="Click" click="currentState=’newCheckbox’" />

  11:         <mx:Button label="Click" click="currentState=’newTextArea’" />

  12:   <mx:CheckBox id="checkbox" label="Checkbox" includeIn="newCheckbox, newTextArea"/>

  13:         <mx:TextArea id="textarea" includeIn="newTextArea"/>

  14:     </mx:VBox>

  15: </mx:Application>

O código acaba por ter lógica e ficar mais limpo, alem de ser de mais fácil compreensão.

No artigo original, temos mais algumas referencias a outras alterações, tais como o parâmetro relativeTo="{componente}", position="before/after" na tag <mx:AddChild>

Falando de uma das alterações que me saltou à vista e que poupará muitas linhas de código é o que a adobe chama de "State Specific Propertys" que passam as estar disponíveis nos componentes definindo o seu "estado" para o devido "State". Vejam como irá simplificar as coisas:

   1: <!– O label do botão em qualquer outro state será "XXX’, e no state A, "YYY", –>

   2: <!– e no state B, "ZZZ" –>

   3: <Button label="XXX" label.A="YYY" label.B="ZZZ" />

   4:  

   5: <!– No state A, a cor é limpa (para default) para que, se for o caso, um possivel

   6: <!– CSS Style possa ser implementado nesse state A –>

   7: <Button color="0xFF0000" color.A="@Clear" />

   8:  

   9: <!– Usando o exemplo em States –>

  10: <m:states>

  11:         <m:State name="landState"/>

  12:         <m:State name="airState"/>

  13:         <m:State name="waterState"/>

  14:     </m:states>

  15:  

  16:         <mx:CheckBox label="Helicopter" color.airState="0xFF0000"/>

  17:         <mx:CheckBox label="Motorcycle" color.landState="0xFF0000" />

  18:         <mx:CheckBox label="Car" color.landState="0xFF0000" />

  19:         <mx:CheckBox label="Airplane" color.airState="0xFF0000"/>

  20:         <mx:CheckBox label="Train" color.landState="0xFF0000" />

  21:         <mx:CheckBox label="Boat" color.waterState="0xFF0000"/>

  22:         <mx:CheckBox label="Submarine" color.waterState="0xFF0000"/>

  23:  

  24: <!– facilmente percebemos que podemos mudar o label também –>

  25:  

  26:<mx:CheckBox label="Boat" color.waterState="0xFF0000" label.waterState="Boat in Water"/>

  27:  

  28: <!– muito util em propriedades como, click, enabled, etc… –>

  29: <mx:Button id="button" label="Enable" label.waterState="Disable"

  30:             click="currentState=’enabled’"

  31:             click.waterState="currentState=”" />

  32:         <mx:TextInput enabled="false" enabled.landState="true"

  33:              text="example text" />

  34:  

  35:  

Não me vou alongar muito mais, até porque o essencial está dito… podem ver o artigo original no link que indiquei em cima..

Parece mesmo que a adobe está decidida a facilitar a vida aos programadores (pelo menos os que já estão com noções médias/avançadas) mas para programadores iniciantes não será muito fácil digerir estas alterações…mas com o tempo as coisas irão ao seu devido lugar…

Bem, estou ansioso de colocar as mãos neste Flex 4 "codename Gumbo", mas pelos visto só para finais de Setembro/Outubro.. vamos a ver no que dá!!

Abraço!

Depois de ter aqui falado de como um componente é apresentado no stage, bem como todos os passos da sua criação, falo agora, em continuação com a documentação da adobe, de como se deve proceder à implementação de um componente, bem com os passos a executar na sua implementação.

Estes procedimentos não são todos obrigatórios, mas deve-se ter em conta as suas dependências. Passo então a citar a fonte original, mas em português e com um exemplo não testado.

Passos para criar um componente

Quando se implementa um componente, regra geral, fazemos o override (re-escrita) de determinado métodos do componente, definimos novas propriedades, disparamos/criaamos eventos e efectuamos quaisquer outras alterações/personalizações tendo em conta o objectivo do nosso componente na aplicação.

Para implementar um componente, devemos seguir a seguinte ordem:

1. Se necessário, criamos skins para o nosso componente;

2. Criamos um ficheiro "Action Script Class file" tendo a estrutura:

1: package meuComponente

2: {

3: //importar o que iremos usar no nosso componente.

4:import mx.core.UIComponent;

5:import mx.controls.Button;

6: import mx.controls.TextArea;

7: import flash.events.Event;

8: 

9: // definimos o nosso evento pessoal que usaremos em baixo

10: [Event(name="change", type="flash.events.Event")]

a) Extendemos uma das classes base, todos os componentes são baseados na class UI, se desejarmos criar um componente de raiz, mais complexo, devemos extender esta class, caso contrario se só desejarmos implementar/extender um componente simples como um botão, extendemos apenas esse componente.

1: //extender a class que desejamos

2: public class Exemplo extends UIComponent {

3: 

8: }

b)  Especificamos as propriedades/variáveis que o utilizador pode definir usando as propriedades ou a tag MXML;

1: private var textObj:TextArea;

2: private var modeObj:Button;   

3: private var _textLabel:String;

1: //usando skins de um swf.

2: [Embed(source="Modal2.swf", symbol="blueCircle")]

3: public var modeUpSkinName:Class;

4: 

5: //importando/incluido uma imagem

6: [Embed(source="img/img1.png")]7: public var imagem1:Class;

d) Implementar o construtor da class.

1: public function Exemplo() {

2: super();

3: }

Chamada na inicialização do componente, util para adicionar-mos um novo child, por exemplo os nossos componentes TextArea e Button declarados em cima:

1: override protected function createChildren():void {

2: super.createChildren();

3: 

4: // Criar e inicializar a nossa TextArea.

5: if (!textObj)

6: {

7: textObj = new TextArea();

8: textObj.explicitWidth = 80;

9: //podemos adicionar um evento:

10: textObj.addEventListener("change", handleChangeEvent);

11: addChild(textObj);

12: }

13: 

14: // Criar e inicializar o nosso Botão

15: if (!modeObj)

16: { modeObj = new Button();

17: modeObj.label = "Exemplo de Btn";

18: addChild(modeObj);

19: }

20: }

Chamado pelo método invalidateProperties(); que actualiza quaisquer as propriedades do nosso componente:

1: override protected function commitProperties():void {

2: super.commitProperties();

3:

4: if (modObj && _textLabel.lenght>0) {

5: //usando o label, se existir, da nossa variavel _textLabel

6: modObj.label=_textLabel;

7: invalidateDisplayList();

8: }

9: }

Chamado para recalcular (ao ser alterado) o tamanho do nosso componente, bem como definirmos as posições dos nosso childs.

1: override protected function measure():void {

2: super.measure();

3: 

4: //o tamanho do nosso UIComponent vai depender do tamanho dos

5: //childs, por isso temos que calcular o tamanho deles pra poder

6: //definir correctamente o layout do nosso componente.

7: 

8: var buttonWidth:Number = modeObj.measuredWidth;

9: var buttonHeight:Number = modeObj.measuredHeight;

10: 

11: // O valor do comprimento, por defeito e minimo são igauis

12: // á measeuredWidth da nossa TextArea mais o measuredWidth

13: // do nosso botão

14: measuredWidth = measuredMinWidth =

15: textObj.measuredWidth + buttonWidth;

16:

17: // O mesmo se passa com a altura do nosso componente que será

18: // igual à measuredHeight da nossa textArea + measuredHeight do

19: // nosso botão.

20: measuredHeight = measuredMinHeight =

21: modeObj.measuredHeight, buttonHeight;

22: }

Podemos definir mais algumas propriedades do nosso layout:

1:protected override function layoutChrome(unscaledWidth:Number, unscaledHeight:Number):void {

2: super.layoutChrome(unscaledWidth, unscaledHeight);

3:

4: this.textObj.disabled = true;

5: }

Chamado pelo método invalidateDisplayList(); para redefinir a nossa DisplayList (caso sejam alterados os tamanhos do nosso componente) :

1: override protected function updateDisplayList(unscaledWidth:Number,

2: unscaledHeight:Number):void {

3: super.updateDisplayList(unscaledWidth, unscaledHeight);

4: 

5: // subtraimos um pixel dos bordos e usamos uma

6: // margem de 3 pixeis à esquerda e direita

7: // 1+1+3+3 = 8;

8: var usableWidth:Number = unscaledWidth - 8;

9: 

10: // Fazemos o mesmo para o topo e fundo

11: var usableHeight:Number = unscaledHeight - 8;

12: 

13: //tamanhos da textArea e botão

14: //a textArea terá o tamanho máximo do nosso compoenente

15: var textWidth:Number = usableWidth;

16: //a altura, definimos a altura maxima, subtraindo apenas a

17: // altura do nosso botão, para este fique logo em baixo da nossa

18: // textArea.

19: var textHeight:Number = usableHeight-modeObj.height;

20: textObj.setActualSize(textWidth, textHeight);

21:

22: //o nosso botão terá todo o comprimento no nosso componente

23: modeObj.setActualSize(usableWidth, modeObj.height);

24: 

25: // Redefinirmos as posições dos nosso childs

26: textObj.move(4,4); //x=y=(margem=3 + bordo=1)= 4

27: //x=margem+bordo=4, y=height+ espaço de 5px entre eles

28: modeObj.move(4,textObj.height+5);

29:

30: // Desenhamos uma linha à volta do nosso componente a negro pra

31: //servir de bordo.

32: graphics.lineStyle(1, 0×000000, 1.0);

33: graphics.drawRect(0, 0, unscaledWidth, unscaledHeight);

34: }

adicionamos o resto das propriedades do nosso componente: