http://analytics.blogspot.com/2008/11/want-to-track-adobe-flash-now-you-can.html

Abaixo um vídeo que explica melhor:

Documentação
Código para download

Muito interessante essa iniciativa da Adobe, mas qual será o real objetivo?

A principal delas é introspecção, ou seja, se você instanciar algum .cfc com a IDE irá lhe mostrar métodos e propriedades quanto digitar . Além disso datasources e outras variáveis do CF são encontradas, start e stop do CF a partir do Eclipse etc.

Ainda não está diponível para download, mas fiquem ligados no labs.

Para que os que ficaram desanimados por não terem um mac para testar o Catalyst, estão anunciando a versão beta para o 1o trimestre de 2009 para mac e windows. Não está tão longe assim!!!

O Calalyst foi disponibilizado apenas para MAC e o Builder para MAC e Windows.

Junto com os arquivos irei colocar as novidades que vi nesta última palestra sobre as duas ferramentas. O negócio tá ficando ainda melhor.

O projeto já está disponível com o codenome Gumbo. O próprio Ely disse que o projeto possui diversos bugs, mas que já podemos ver como irá funcionar a próxima versão.

Muitos pontos interessantes foram colocados, como a separação total entre Designers e Desenvolvedores que o Catalyst irá proporcionar e como isso vai funcionar em termos de código. Nos exemplos pudemos ver um novo namespace e toda uma nova linha se componentes chamada FxComponents. Novos metas também foram mostrados como [SkinPart] e [SkinStates]. Não vale a pena explicar todas essas novidades no detalhe, pois muita coisa ainda vai mudar. Vale sim a pena mencionar um novo formato que o After Effects, Illustrator, Fireworks e Photoshop irão exportar, o .fxg. Essa extensão nada mais é que a tradução de um vertor/imagem/skin em mxml.

Também foi mostrada a nova sintaxe de States:

Como vocês podem ver, no estado "stateX" o label terá o nome de Flex.

Pudemos ver alguns exemplos de novas propriedades e também como o novo SDK explora o Player 10 =, usando X, Y, Z. Irei colocar em outro post dois vídeos com pedaços da apresentação. A qualidade não está muito boa, mas vale a pena ver pelas animações. Tudo, absolutamente tudo que você podem ver, foi feito com MXML.

Quanto a compatibilidade, essa é a primeira premissa. Poderemos ter, nas mesmas aplicações, pedaços em Flex 3 e Flex 4 e o compilador se encarregara do trabalho. Existirão algumas limitações como no caso de States. Se usarmos a nova sintaxe, não poderemos fazer isso em um arquivo antigo. Mas poderemos ter arquivos com ambas as sintaxes dos states na mesma aplicação em arquivos diferentes. Acredito que é cedo para falarmos nisso, mas é importante sabermos da preocupação da Adobe.

Por fim, também estão trabalhando na velocidade do compilador, chegando a um ganho de até 5x em aplicações realmente grandes.

Nas apresentações estamos vendo diversas features do Player 10, mas o que mais me impressionou foram as novas features de texto renderização em tempo de execução. Particularmente não li sobre essas features, mas fiquei curioso para conhecer depois de ver as demos.

Kevin Lynch também mostrou um dispositivo (um pouco maior que um celular) com Linux e Air 1.5 instalado. Todas as aplicações mostradas rodaram, mostrando o conceito Cliente+Cloud, além do Air rodando em Linux.

Outra aplicação bem interessante foi Tour de Flex. É uma aplicação em air com vários exemplos de aplicações (mais de 200), integrações, com código fonte e demos. Muito bom.

Adobe Cocomo (Building Realtime Social Applications in Flex). O nome já diz tudo. A Adobe irá prover toda a infra-estrutura para usarmos Real Time Data Messaging, áudio, vídeo etc. Ou seja, as features do Data Services. Já está disponível em beta no labs.

Adobe Wave (Displaying a desktop notification is a simple as sending a email). Parece uma espécie de RSS com notificação. O exemplo era colocar um convite para uma festa e receber as respostas no Desktop. Ainda não sei o objetivo da Adobe com isso. Quem sabe?

Flash Full no celular. Ficou claro que a Adobe vai voltar os esforços da área de mobile para colocar o Flash Player Full nos celulares. Foi mostrado alguns celulares da Nokia (N95), Sansung, telefone do Google etc, funcionando com aplicações como YouTube (vídeo) e Last.fm (áudio). Sobre o IPhone foi dito que estão trabalhando, mas não foi mostrado. Todo esse esforço deve-se ao fato do grande crescimento dos dispositivos móveis no acesso a Internet, superando desktops e notebooks.

Maria Shriver (primeira dama da Califórnia - ela mesmo, esposa do Terminator) esteve falando sobre o projeto que ela dirige: California Legacy Trails. O projeto parece ser interessante. Na verdade não tenho muito o que falar, achei a presença ilustre.

O filtro seria parecido com o like das queries SQL de consulta ao banco de dados. Fazendo a minha busca, encontrei duas opções para concluir essa tarefa: O filterFunction do XmlListCollection e o search do e4x.

As duas implementações são simples e interessantes. Falta testar o desempenho(deixo com vcs...hehehe)

Segue a aplicação implementando as duas soluções:

Seguem os fontes:

O XML usado no dataProvider:

Em ambos os casos terá como resultado uma consulta semelhante ao like %...% do SQL.

No primeiro dataGrid é feito o filtro baseado no filterFunction, ao preencher o campo de texto é disparada a função filterFunc(item:Object):Boolean por meio do método xmlListFilterFunc.refresh(), retornando true somente para as linhas do xml que satisfazem a consulta. Ou seja, indexOf(..) > -1.

No segundo dataGrid é pelo E4X que fazemos a consulta. Para cada linha do xml é comparada com o texto digitado no campo. O search funciona igual à função indexOf da classe String. O intessante a observar neste segundo exemplo é que qualquer consulta feita por meio do texto do xml, ou seja, se vc tem como nó do xml <state code="AB">Alberta</state>  o texto é Alberta. Isso é representado no E4X por (*).

Qualquer dúvida será bem vinda.

Abraços

A Internet ainda não está muito boa no evento, mas assim que puder disponibilizo. Não esqueçam que estamos com 6h a menos.

Geralmente, o que encontramos são implementações monolíticas do ModelLocator no Cairngorm, com centenas de linhas de código para armazenar estados da aplicação, na tentativa insana de centralizar o modelo de dados da aplicação num ponto único, de fácil acesso. Confesso que isso sempre me incomodou, uma vez que torna o ModelLocator um anti-pattern, um repositório de variáveis globais e scripts procedurais (digo, Commands .... rs).

O binding para variáveis globais torna os componentes menos reutilizáveis, dificultando os testes, a substituição do modelo, a modificações das views da aplicação, a divisão de responsabilidade, promovendo assim um forte acoplamento entre as partes, justamente o oposto do que um design pattern deveria fazer: promover reutilização de código, programação orientada à interface, baixo acoplamento, divisão de responsabilidade, etc.

Além do mais, o nome “ModelLocator” sugere que os objetos desse tipo serão utilizados para alocar modelos, ainda mais pelo fato dele implementar o padrão Service Locator. Mas não, no Cairngorm o que encontramos é um Model Locator que na verdade é o próprio modelo.

Outro fato que me incomoda bastante, é o da implementação do ModelLocator no Cairngorm ser vendido como um exemplo do padrão Singleton, uma vez que na verdade é mais um exemplo do padrão Monostate, que pode ser descrito como uma classe com membros estáticos, de forma que todas as instâncias dessa classe compartilham a mesma informação.

Bom, tudo bem, mas agora você deve estar se perguntando: “Como posso resolver esse problema?”. Resposta: Domain Models, Presentation Models e Injeção de Dependência.

Com o uso do padrão Domain Model, podemos atribuir à ele a tarefa de estruturar os dados da nossa aplicação e definir seus comportamentos (lógica de dados), retirando assim essa responsabilidade do ModelLocator. Aqui cabe uma discussão com relação à distribuição de responsabilidades, uma vez que muitos irão consider mais adequado (e talvez o seja mesmo) manter a definição de comportamentos nos Commands.

Um dos papéis do padrão Presentation Model é o de separar a view do model, adicionando um objeto mediador entre eles, tornando tanto a view quanto o modelo substituíveis, isso é, desacoplados. Isso faz com que tudo que a view precise, tanto dados quanto métodos, esteja presente nesse objeto presentation model.

Com a injeção de dependência, o componente não é mais responsável por recuperar uma instância do modelo, ao invés disso a responsabilidade é repassada a outro componente que deseja utilizá-lo.

Por exemplo, ao invés de:

Teríamos:

Isso nos leva a crer que não exista a necessidade do ModelLocator ser um Singleton, mas sim uma interface (talvez com um nome menos confuso...), de forma que não importe qual será sua implementação. Podem assim existir implementações diferentes para desenvolvimento, teste e produção.

Essa arquitetura faz com que o ModelLocator deixe de ser usado como um repositório de dados, e passe finalmente a ser usado como um repositório de modelos, um local onde poderemos encontrar objetos que armazenam dados, através dos Domain Models e Presentation Models.

Steven Webster vem defendendo junto a Adobe Consulting a incorporação do padrão Presentation Model (também conhecido como Application Model) no Cairngorm, uma vez que ele diz estar utilizando esse padrão em seus projetos de grande escala. Embora haja essa “preferência” de Webster, aparentemente a versão 3.0 do Cairngorm ainda não irá adotá-lo.

No próximo post vamos desenvolver uma aplicação Flex utilizando framework Cairngorm, da forma como estamos acostumados a ver. Depois vamos refatorá-la para aplicar os padrões que apresentei a vocês.

Até a próxima, e fiquem a vontade para perguntar!

Referências:

Steven Webster comenta sobre a adoção do padrão Presentation Model no Cairngorm 3.0:
http://www.adobeforums.com/webx/.59b654d0

Martin Fowler explicando o padrão Presentation Model:
http://martinfowler.com/eaaDev/PresentationModel.html

Paul Williams explicando o padrão Presentation Model:
http://weblogs.macromedia.com/paulw/archives/2007/09/presentation_pa.html

Grande abraço.

Bem, pode não parecer, mas isto tem um bom motivo para ser assim. Este post fala sobre este motivo e mostra como fazer isto no Flex (que pode não parecer, mas também não é tão simples assim).

Se tem uma coisa que pode deixar o visual da sua aplicação Flex mais bonita é o uso do alpha. Mas o segredo para usar isto bem é equilibrar o quanto de transparência aplicar sem prejudicar a legibilidade de determinados elementos.

No Flex, por padrão, um TitleWindow vai usar a transparência desta forma:

Porém, observe no exemplo acima como a leitura do título do Painel é prejudicada por causa da transparência. Mas eu não quero diminuir muito o nível de transparência. Então eu aplico um Blur apenas no que está em baixo do TitleWindow:

Neste exemplo em Flex, enquanto você move o Title Window, o Blur é mostrado apenas nos elementos que estão em baixo dele.

Até parece simples fazer isto não é mesmo? Mas saiba que o Blur não pode ser aplicado no TitleWindow (isto deixaria apenas o TitleWindow desfocado ). Então a saída foi mesmo usar PopUpManager e máscara do Flash Player para resolver a questão. Curioso? Veja o código fonte (código fonte Botão Direito -> View Source). Não está nem aí para o código? Bem, se um dia você precisar deste efeito sabe onde encontrar.

As pessoas apenas pragmáticas não costumam ter blogs. Já as pessoas teóricas costumam ter, embora com um conteúdo geralmente prolixo e chato. Mas tem um outro tipo de pessoa, nem pragmática nem teórica, que costuma ter blog: o marketeiro. Estes geralmente tem muitas visitas, mas de cada 10 posts 9 são puro marketing pessoal. Confesso que isso me incomoda na medida em que os marketeiros costumam se gabar do número de visitas do seu blog e gostam de se vender como os melhores do mercado. Mas o que me deixa tranqüilo é o fato de saber que eles não constroem sua reputação em cima de algo louvável. Eles se elegem como os políticos do Brasil. Eles ficam famosos como os big Brothers. Eles, eventualmente, conseguem algumas vantagens competitivas como a Micro$oft. E de fato, eles não sabem aliar teoria e prática.

Bem, críticas a parte, analisando novamente um código que surgiu como resposta a um problema na FlexDev, eu senti a oportunidade de aliar teoria e prática. Não julgo que sei fazer isto bem, mas pelo menos é algo que eu busco.

Primeiro, algo útil para você usar caso precise um dia (prática). O exemplo abaixo mostra a utilização de um componente que permite facilmente associar funções a teclas de atalho no Flex.

(Para ver o código fonte: Botão direito - View Source)

O ponto forte deste componente é a sua simplicidade de uso como mostra o exemplo:

Você só precisa o trecho acima para que toda vez que a usuário pressionar CTRL + HOME a função "homeHandler" seja chamada recebendo os argumentos "arg1" e "arg2".

Agora um pouco de teoria que espero que também lhe seja útil de alguma forma. Isto tem a ver com abstração, pesquisa, nomes de variáveis e métodos e Refactoring. Tudo isto usando algo em torno de 10 linhas de código do componente e, prometo, tentarei não ser prolixo (se bem que ao dizer que não serei prolixo eu já estou sendo uma vez que a palavra "prolixo" é prolixa em si).

A primeira versão do componente tem o seguinte trecho de código:

Exemplo 1

Bem, eu posso reescrever o trecho de código acima usando vários "ifs":

Exemplo 2

O que tornou possível remover os "ifs" (exemplo 2) foi o uso do Bitwise XOR (o sinal ^ no exemplo 1). E o que tornou possível o uso do XOR foi a abstração. Eu percebi que o que importava para resolver meu problema é que o resultado da comparação entre dois valores booleanos fosse verdadeira caso os valores fossem iguais (verdadeiro e verdadeiro = verdadeiro ou falso e falso = verdadeiro). Então, se houvesse uma maneira de verificar isto eu não precisaria de vários "ifs" para testar diversas situações. Eu lembrava das aulas de lógica da faculdade de Ciência da Computação que tinha uma notação que representava este cenário. Logo, imaginei que deveria haver uma forma de escrever isto numa linguagem de programação como o ActionScript. Isto foi comprovado minutos depois de uma rápida pesquisa no Help. Assim, a linha 3 e a linha 4 do exemplo 1 garantem que o resultado será verdadeiro caso ambos os valores envolvidos no XOR sejam verdadeiros ou ambos sejam falsos.

O "if", assim como as estruturas de repetição, são alguns dos itens que adicionam complexidade num algoritmo e sempre que posso eu tento reduzi-los. Mas neste caso o uso do operador Bitwise XOR conseguiu deixar as coisas mais complexas ainda.

Então pensei em adicionar comentários para deixar as coisas mais claras:

Exemplo 3