Mostrando postagens com marcador actionscript. Mostrar todas as postagens
Mostrando postagens com marcador actionscript. Mostrar todas as postagens

quinta-feira, 17 de novembro de 2011

My Questions about Adobe Changes on FlashPlayer and Roadmaps

Learning from the mistakes Adobe?

CONTEXT:
I'm on Flash related business since 1996, when I downloaded a software called FutureSplash from a company called FutureWare and found a definitive solution for what I used to develop using Java Applets. Since that that, I just became so dedicated to the platform (and ColdFusion as well), that it even leaded myself to be part of the brazilian Macromedia team as a consultant and evangelist until 2003. After that, I kept my own business as an independent consultant.

Now, a lot of years after, I find myself very disappointed (as I believe a lot of people is as well) with the decisions made by Adobe recently.
Flash was always for me the only technology able to deliver what other technologies, like HTML specifically couldn't, that is ubiquity between platforms. I mean: That ubiquity was always the key feature on to adopt Actionscript/MXML and for everyone this was understood. Even Apple agreed, and it was clear when they took a step back and allowed cross-compiling on its 4.1 developer agreement regarding this issue.

The problem to the market was ALWAYS on Flash Player itself. Adobe seems to be not able to find a way to have FlashPlayer working as it would be for the market to accept it. Now Adobe just throw the towel leaving an entire community developers who sustained the platform growing, with the following message (in other soft words, of course):

Hey, there's no problem, FlashPlayer will still be there for desktop browsers and AIR will still be capable to allow you to cross-compile your AS3/MXML code for you to deliver proper HTML5/CSS/JS instead of SWF (in the future). And better, Flex SDK will be opened via Apache Foundation, as well as interested third party companies will also get the FlashPlayer sources and keep their on versions (Just like RIM announced it will do right now). 

QUESTIONS: 

  1. Do you Adobe really believe the market will still keep developing anything to run on FlashPlayer after that? As what justified and was keeping people thrusting on SWF was the ability to have this content viewable on any kind of devices - you mentioned that for years! Killing it, don't you just started the process to make FlashPlayer useless anywhere it is today?
  2. As it's only justifiable to have a cross-compiling when you can output multiple different formats from a single source (what maintained the so called and believed "develop onde, run everywhere" that we was requested to spread the word about), do you really believe someone will rely on AS3/MXML to output HTML5/CSS3/JS when we can do it directly using a lot of already mature softwares to do so available on the market, that in addiction allow us to cross-compile it to native executables for multiple platforms (Windows, MacOS, iOS, Android, etc)? 
  3. Don't you think the better decision was only to open source FlashPlayer and let the so called "public development efforts, together with Adobe Team resources made available now", to be able to take FlashPlayer to the level it would be on the multiple platforms including banned Linux and Mobile browser versions?
  4. Don't you know you lost a lot of thrust from people who most defended and worked together for and with you, even privately and at no charge (just for we can call "love", at most), waiting nothing from you then keep the things going on and NEVER even imagining you could someday do such a terrible move?
  5. Why didn't you focused all of that effort you are spending now to, together with the community, keep FlashPlayer as ubiquitous as it ever was, and on the move announce efforts to ADD the proper and necessary capabilities to your development tools and technologies to integrate them more and more with the HTML5 transition to come, in the format of a).new features on softwares like Dreamweaver, Catalyst, Edge, etc. b). Additional cross-compiling capability to the Flex SDK to output HTML5/CSS3/JS, as announced Falcon is intended to do? This would AVOIDED all that NEGATIVE BUZZ on the Community we are having to support together (remeber that most of us have business running on top of what we defended and spread from Adobe decisions, just to help Adobe to be stronger, even when it seems to have no value anymore) because of your tremendous and erroneous way to announce things and decisions. 
  6. Don't you think you need better marketing and press office to support you on such kind of announcements?"

domingo, 12 de setembro de 2010

Adobe vs Apple END WAR?

Lembram?

Pois é... acabou!
http://www.apple.com/pr/library/2010/09/09statement.html

Em outras palavras e bem resumidamente, o que havia sido restringido era o uso de LLVM (Low Level Virtual Machine) para fazer com que aplicações escritas em outras linguagens rodassem no iOS (o sistema operacional do iPhone, iPad e iPod). Toda a API da linguagem escolhida (por exemplo o Actionscript do Flash) era traduzida para Objective C e então as aplicações escritas nessa linguagem rodavam normalmente nesses equipamentos da Apple.

Esse anúncio determina que o LLVM está liberado, e a única restrição agora é a execução de código externo carregado em tempo real. Ou seja, a aplicação não poderá carregar módulos externos através de uma conexão HTTP (por exemplo) ou de qualquer outro protocolo ou método que seja. Aliás isso seria considerado falha de segurança em qualquer OS de software embarcado, como é o caso.

Outra coisa bem interessante que veio deste anúncio foi a notícia de que a Apple pela primeira vez está publicando no seu portal para desenvolvedores, o Guideline do processo de revisão pelo o qual toda a aplicação enviada para aprovação passa. Isso irá garantir uma transparência inédita do processo, além de agir como facilitador para a solução de problemas vez que uma aplicação não aprovada irá ter o conhecimento de qual (ou quais) pontos foram infringidos em tal processo.
Enfim, tudo em paz! Será?

Vale lembrarmos de que o FlashPlayer ainda não terá versão compativel com o iOS, e portanto essa discussão ainda não está terminada. Aliás, pelo contrário! Eu particularmente temo um pouco o que está por vir.

Tenho medo de que a tecnologia Flash tenha finalmente as portas abertas para infelizmente determinar por sí só uma imagem ruim no exigente mundo da Apple. O pior é que isso não aconteceria pela tecnologia em sí ou por menos esforço da Adobe. Isso pode acontecer simplesmente por causa dos desenvolvedores!

E não é por causa dos "sobrinhos" que eu temo. Estes, eu espero que sejam barrados pela própria Apple, embora eu tenho certeza de que ainda existirão teorias conspiratórias bizarras de que a própria Apple teria feito isso para que os sobrinhos finalmente provassem o que ela gostaria. Ironia à parte, ainda me lembro muito bem daquela "Carta aberta do Steve Jobs".

Mas enfim, particularmente, minha preocupação não são os sobrinhos. O mercado Apple é muito bem qualificado e nesse sentido irá se auto-filtrar. O que me preocupa é o fato de que nós desenvolvedores temos que nos re-educar para esse novo ambiente de desenvolvimento. A Adobe ainda não finalizou uma versão otimizada do SDK do Flex e isso acaba por exigir um esforço bem peculiar em cautelas por parte do programador na arquitetura de um software para estes dispositivos. Há mais um fator que tende a exigir esse esforço do desenvolvedor: Muitas das reclamações "ATUAIS" quanto as aplicações para iOS geradas com o PFI (Packager For iPhone), é quanto ao resultado do binary final, os problemas de uso excessivo de memória e consumo de bateria.

Ou seja, a Adobe ainda tem muito trabalho a retomar nesse Packager e nós muito a aprender para que essa notícia seja finalmente uma notícia de paz entre a Apple, seus produtos, a Adobe e nós desenvolvedores dedicados ao FlashPlatform.

sexta-feira, 16 de janeiro de 2009

RIA-BA Grupo de Desenvolvedores RIA na Bahia

mini_banner

Essa é uma grande notícia!
Recebemos o “sinal verde” por parte da Adobe para iniciarmos uma comunidade oficial Adobe destinada a desenvolvedores e interessados no desenvolvimento de soluções RIA baseadas e suas tecnologias.
Surge assim o RIA-BA. Acesse o link no site de comunidades da Adobe, que será o site principal do grupo, inscreva-se e conheça mais detalhes sobre como será a nossa atuação.

As tecnologias que abordaremos, são basicamente as que são voltadas diretamente ao desenvolvimento de soluções RIA, que hoje são o Flash, o Flex/FlexBuilder, AIR, ColdFusion (e frameworks), Flash Media Server, BlazeDS, Cairngorm (e outros frameworks) e diretamente ligadas ao Flash Platform, assim como o Flash Catalyst (Thermo) e outras ferramentas que forem anunciadas.

À frente do grupo estaremos eu (Vicente Maciel Jr) e o meu amigo Jefferson Petilo.

Como alguns sabem, atuamos na Bahia (independentemente, por hora) com consultoria, treinamento e principalmente o desenvolvimento de soluções RIA. Nossa intenção com o grupo é concentrarmos esforços, para cada vez mais aumentar o potencial e resposta de demanda de mercado na região, através da distribuição de informação e acesso às novidades que surgirem no setor, de maneira mais rápida e eficiente possível. Para isso, estaremos abertos e firmando boas parcerias que possibilitem alcançar tal objetivo, bem como atender a outras necessidades dos usuários do grupo em relação a outras tecnologias Adobe que não sejam exatamente o foco do nosso grupo abordar, tais como Fireworks, Illustrator, Photoshop, Premiere, etc.

Enfim, interessados, mantenham-se ligados no site, que será nossa principal ferramenta de abordagem, efetivação e comunicação com a comunidade.

Sugestões e criticas construtivas serão sempre muito bem-vindas!

terça-feira, 2 de dezembro de 2008

Flex Grafico de Barra no DataGrid sem usar Visualization Framework

igorcostaBlog

Hoje no MSN o Igor Costa me apresentou um hack , para de forma muito criativa apresentar um gráfico de barras usando linhas do DataGrid referente a cada valor apresentado. Veja o post: http://www.igorcosta.org/wp-trackback.php?p=190

sábado, 29 de novembro de 2008

RIP Rich Internet Presentation

thesecret_for_ria

Foi simplesmente a melhor apresentação a respeito de RIA que já tive a oportunidade de assistir, não só no tocante ao conteúdo, que foi de uma riqueza impressionante e muito bem elaborado, mas também pela performance do apresentator, Beck Novaes (DClick), que conseguiu de uma maneira extremamente clara, objetiva e didática, abordar temas “obscuros” (e às vezes até pouco conhecidos/ignorados) da produção de um RIA.

Fico extremamente orgulhoso de saber que um material dessa qualidade tenha sido desenvolvido por um brasileiro e gostaria muito de ve-lo publicado no Adobe Developer Connection como uma referência importante, tanto para quem vai iniciar-se no desenvolvimento de RIAs, quanto para quem quer atingir um nivel superior na realização e redesenho de seus trabalhos atuais.

Por isso, digo que o Beck consegiu inaugurar o termo RIP (Rich Internet Presentation)

Isso porque ele conseguiu colocar na execução da sua apresentação, exatamente tudo o que ele abordou como importante no desenvolvimento de um RIA. Quer saber o quê foi? Como foi? Só assistindo.

http://blog.dclick.com.br/2008/11/29/60-pessoas-ja-sabem-o-segredo/trackback/pt/

quarta-feira, 19 de novembro de 2008

Alchemy Flash C++

20080330_atoms_and_alchemy

A imagem ao lado não se refere ao logo do projeto que a Adobe anunciou no MAX 2007 e que disponibilizou para testes e avaliação da comunidade no MAX 2008 que ocorre esta semana.

A imagem refere-se a capa de um livro que pode se conhecido neste link. Simplesmente achei o logo do mesmo interessante e resolvi usar a imagem para ilustrar o post.

OK! Justificativas feitas, vamos ao que realmente interessa!

No MAX 2007, este projeto originalmente chamado de FLACC foi apresentado, anunciando a possibilidade de compilação de código escrito em C/C++ em uma biblioteca com bytecode possível de ser consumido e rodado em uma “futura” versão do FlashPlayer.

Pois bem. Essa semana, no MAX 2008 que ocorre em San Francisco/CA/USA, o projeto foi aberto ao público e encontra-se disponível no Adobe Labs afim de que programadores C/C++ possam efetivamente testá-lo, bem como sugerir implementações, ou simplesmente dar a sua opinião. O “futuro” FlashPlayer traduz-se no recém disponibilizado FlashPlayer10 e extende-se ao Adobe AIR 1.5 disponibilizado paralelamente ao anúncio do Alchemy.

A pergunta é: Qual o objetivo prático do Alchemy?

Inicialmente, e confesso que eu fui uma dessas pessoas, me pareceu que esta sería a declaração de liberdade de recursos do FlashPlayer, abrindo ai a possibilidade de valer-se de bibliotecas C/C++ destinadas até mesmo co controle de hardware (impressoras fiscais, equipamentos de biometria, joysticks, etc.), mas infelizmente não é do que se trata.
O principal objetivo do Alchemy é expandir a capacidade do FlashPlayer no que se refere a processamento de dados. Ou seja, algoritimos de criptografia; leitura, análise e processamento de áudio e vídeo; leitura, escrita de renderização dos mais diversos tipos de formatos de arquivos e coisas do tipo. Ao invés de portar/reescrever um código originalmente escrito em C/C++, o mesmo pode ser simplesmente  compilado em um SWF/SWC e consumido por um código AS3 (Flash/Flex/AIR).
Ou seja, os recursos capazes de serem explorados em C/C++ no FlashPlayer10/AIR 1.5, são limitados exatamente aos recursos presentes nos respectivos players, o que acaba soando óbvio mas que não precisaria ser necessariamente assim. Porém, de qualquer maneira é um avanço impressionante nas capacidades que o Adobe Flash Platform passa a oferecer. Aliás, gostei deste termo ter sido resgatado pela Adobe para referenciar toda a linha de produtos relacionados à produção ou a execução/controle de conteúdo utilizando ActionScript.

Então o que muda? O que poderá surgir a partir disso?

Mais uma vez as possibilidades estão apenas limitadas à critividade, mas com ainda mais opções. Pense numa formula tipo “infinito² - direct_hardware_access”.
Primeiro a gente tem que pensar que a maioria das possibilidades de uso desses recursos que serão implementados daqui por diante já estavam disponíveis e eram possíveis por causa do recurso de “ByteArray” (Classe ByteArray) introduzida no FlashPlayer9/AIR 1.0, porém sendo necessário um esforço muito maior do que será necessário agora, vez que para alcança-los era necessário reinventar a roda reescrevendo tudo o que já existia antes para tal. Hoje, com o Alchemy, bastará compilar um código pré-existente que tenha a base da funcionalidade deseja e implementá-la com AS3. Alguns recursos, como os relacionados diretamente a som (Dynamic Sound Sampplig) e alguns em relação a formato de vídeo (H.264 por exemplo) só serão possíveis pela disponibilidade do recurso internamente no FlashPlayer10/AIR 1.5, assim como também a aceleração de vídeo por software e por hardware.
Dentre as possibilidades práticas que podemos imaginar estão desde as já apresentadas como exemplo pela própria Adobe no MAX 2007/2008 como jogos famosos sendo disponibilizados para rodar com o FlashPlayer/AIR onde o jogo Quake I foi utilizando como exemplo, players de vários formatos de audio/video (não apenas MP3/FLV), conversores de arquivos, serviços de criptografia/descriptografia de dados, implementação de protocolos de comunicação cliente-servidor e até mesmo um maior avanço no uso desses players de maneira mais abrangente em dispositivos como celulares, set-top-boxes (tv-digital), pocketPCs, console de games, etc.

E você? O que você acha que pode ser possível a partir do Alchemy?

Lembre-se, se você quiser começar a portar um eventual código C/C++, na página dedicada ao Alchemy no Adobe Labs, você encontra além dos binaries do projeto, exemplos e instruções de como preparar o ambiente e usar o compilador no Windows, MacOS e Linux.

ColdFusion 9 Centaur

Logo ColdFusion 9 - Centaur

Das novidades anunciadas, umas da que eu mais esperava!

O ColdFusion 9, de code-nome Centaur, na minha opinião apresenta-se com um pacote de inovações técnicas na sua infra-estrutura que remetem à força e dedicação da Adobe em torná-lo cada vez mais uma plataforma competitiva em relação a outros servidores de aplicação disponíveis no mercado.

As novidades desta versão, conforme o que já foi publicado oficialmente pela Adobe (há mais, acreditem), deixam isso bem claro. Faço abaixo meus comentários pessoais a respeito de cada recurso:

Mapeamento de Objetos Relacionais (ORM)

A idéia é diminuir a necessidade de implementação personalizada e geralmente repetitiva para que se obtenha consistência e agilidade no desenvolvimento de aplicações no que se refere à dados. Com este recurso, de uma forma bastante simples o ColdFusion irá expor ao desenvolvedor, a partir de uma configuração bastante simples, objetos que representam dados do banco de dados, considerando a relação existente entre os mesmos.
Hoje, para atingir uma situação/ambiente de desenvolvimento semelhante, utilizo o framework Transfer-ORM desenvolvido, mantido e disponibilizado por Mark Mandell.
Infelizmente acho que códigos que exponham tal recurso ainda não podem ser publicados, mas se você deseja ter uma prévia do que será este recurso no ColdFusion 9 Centaur, conhecer o Transfer-ORM é uma boa introdução.

Melhorias na linguagem em sí

Até mesmo para expor o recurso de mapeamento de objetos relacionais (orm) citado acima, a linguagem necessitava de implementações. Haja visto que o próprio Transfer-ORM acaba pecando em alguns dos seus aspectos internos e capacidade de integração com outras camadas da aplicação, justamente por algumas limitações que o CFML/CFScript apresentavam até então. No caso do Transfer-ORM isso é notável principalmente quando implementa-se uma integração com o Flex/AIR por exemplo. Em resumo, é necessário criar algumas soluções alternativas para integrar os objetos gerados pelo Transfer (os TransferObjects) às capacidades AMF (Remoting/LiveCycle) do ColdFusion.

Essas melhorias na linguagem são basicamente:

  • Possibilidade de escrever componentes (CFCs) totalmente utilizando CFScript
  • Palavra chave “new” para simplificar o instanciamento de componentes bem como sua inicialização
  • Palavra chave “import” para definir o acesso a objetos de dependência em um componente
  • Definição explícita de getters e setters (métodos com diretivas get/set)
  • Definição de um escopo para variáveis locais que simplificará até mesmo a estrutura de um componente
  • CFFINALLY e CFCONTINUE que complementam a logica do TRY/CATCH e LOOPs
  • Enfim, a eliminação das diferenças entre CFTAGs e CFSCript

Ao mesmo tempo que temos que avaliar que isso tudo é extremamente positivo em termos de recursos, capacidade e robustez do ColdFusion, acho que foi importante a preocupação em manter a simplicidade do CFML em sí afim de que o ColdFusion não perca a agilidade da programação declarativa.

Outro fator importante é a proximidade de sintaxe, na questão dos scripts, da estrutura de código e da lógica que será possível de se implementar com o CFSCRIPT em relação às tecnologias concorrentes. Creio eu que além de diminuir uma resistência – que é imediata em relação as TAGs – aumenta a capacidade de se compreender o ColdFusion por parte de desenvolvedores PHP, ASP/.Net, Java, etc.

Serviços ColdFusion expostos ao Flex/AIR através de bibliotecas AS3 específicas (SWCs)

Como desenvolvedor Flash/Flex/AIR, este para mim é o principal recurso que fará diferença no meu dia-a-dia a respeito do ColdFusion 9 Centaur. Vários recursos, que não sei se já podem ser citados publicamente ainda por isso não o farei agora, que hoje dependem de uma implementação manual e repetitiva de aplicação para aplicação, já será abstraída pelo ColdFusion, permitindo o consumo direto desses recursos por meio de objetos em uma API definida em AS3 que poderá ser implementada nas aplicações como RSLs (Runtime Shared Libraries) assinadas digitalmente, que farão parte do framework compartilhado de distribuição única, ou seja, que o usuário baixa uma única vez ao primeiro acesso à aplicação Flex (o AIR não necessita desse download adicional).
Este recurso será certamente considerado um grande diferencial na adoção do ColdFusion para integração com Flex em aplicações RIA robustas.

Método “onServerStart” no Application.cfc

Bom, para quem é usuário do CF e já implementa o Application.cfc em suas soluções, a importância já é implícita. Mas enfim, dá ao desenvolvedor a capacidade de executar uma rotina personalizada na inicialização de um servidor.

 

Para ler dados oficiais do anúncio e candidatar-se a Beta Tester, visite a página dedicada ao lançamento no Adobe Labs:
http://labs.adobe.com/wiki/index.php/Centaur

Adicionalmente, eu não poderia deixar de comentar que ainda espero que exista alguma novidade em relação a politica comercial do ColdFusion. Mas como ainda estamos em fase de discutir o produto em sí, o que nos resta é aguardar.

De qualquer forma, repito, na minha opinião a Adobe encontrou várias formas de justificar e reforçar o diferencial do ColdFusion em relação aos seus concorrentes. E digo isso sustentando que eu mesmo me surpreendi.

sexta-feira, 19 de setembro de 2008

Produtividade Flex e Cairngorm com o Factory IDE

riaptblog Recebi essa dica do @vedovelli (Fábio Vedovelli) no Twitter, fui conferir no blog do RiaPT e achei simplesmente sensacional! Eu já tinha procurado por algo assim e não tinha encontrado.

Além de aumentar a produtividade, aumenta também a qualidade do código que produzimos, e nos incentiva a produzir uma boa documentação.

Veja post original no RiaPT

quarta-feira, 3 de setembro de 2008

Google Chrome. OK! Adobe browser. Por que nao?

Adobe CS3_thumb Analisando os comentários que surgiram após o anúncio do Google Chrome, um pensamento que na verdade já tenho há tempos voltou a "passear" na minha mente: Por que não um navegador da Adobe?

Se você analisar as principais características do Chrome, fica ainda mais evidente que a Adobe tem total condições de colocar uma opção de navegador à disposição, que teria excelentes condições de se tornar o melhor dentre todos.

Relaciono aqui alguns dos principais recursos técnicos presentes no Chrome, e como a Adobe pode correspondê-los:

Recurso Google Chrome Adobe
Javascript Engine V8 Tamarim (doado ao Mozilla.org)
Runtime (?) Google Gears AIR
Browser engine WebKit / Safari engine WebKit / Safari engine (??)
? - Ainda não sei se é correto especificar o recurso como Runtime Virtual Machine
?? - O WebKit não é da Adobe, mas é o engine implementado no AIR para renderizar XHTML/Javascript atualmente no controle mx.controls.HTML (Flex SDK). Portanto, já existe domínio em como implementá-lo

quinta-feira, 24 de julho de 2008

Usando flash.net.Socket para enviar emails via SMTP

smtpmailer

 

 

 

Em um projeto que estou desenvolvendo em AIR surgiu a necessidade do envio de email. Para uma aplicação desktop não ficava nada interessante utilizar um script server-side para fazer isso, então, conhecendo a classe flash.net.Socket disponibilizada tanto na API do FlashPlayer quanto do AIR, que explorada pode oferecer tal funcionalidade, resolvi pesquisar se já havia algo desenvolvido e dentre algumas poucas soluções que encontrei, resolvi testar o SMTPMailer desenvolvido pelo Thibault Imbert do blog ByteArray.org.

Como na lista de discussão Flexdev surgiu um post sobre o assunto na semana que antecedeu essa minha pesquisa, achei conveniente publicar o resultado do teste que fiz afim de que outros possam também ter mais um exemplo do uso da solução criada pelo Thibault.

Tive que fazer algumas alterações e coloquei comentários sobre as mesmas no código original.

Vou tentar manter contato com o Thibault ou até mesmo, adiante, tentar implementar outros recursos bem como a autenticação SSL pois sem esse recurso não é possível utilizar por exemplo servidores SMTP como o do Gmail que requerem este passo.

Exemplo compilado: SMTPMailerLab.air (AIR 1.0/1.1)
Fonte (incluindo as classes originais do ByteArray.org)*: SMTPMailerLab.zip
*FlexBuilder Archive

sexta-feira, 23 de maio de 2008

1a Reuniao - Grupo de estudos Flash Flex AIR AS3

grupo_estudos_banner01

A primeira reunião do grupo foi um sucesso!

Parabéns ao Osmundo pela iniciativa, à Monica da iTraining por ceder o espaço e à todos os presentes pela qualidade das discussões que pudemos iniciar. E claro, obrigado pelo convite.

Para quem não pôde estar presente nesta primeira reunião, segue uma tentativa de sumarizar o que entrou em pauta:

  1. Esclarecimento do objetivo do grupo: Esclarecemos o objetivo e sistemática das reuniões. Em resumo, que não se trata de um treinamento, não há uma figura central e que o conteúdo do estudo se dará sempre pela sugestão definida na reunião anterior, com a apresentação dos resultados, dúvidas e esclarecimentos das mesmas com participação e colaboração de todos.
  2. Discutimos sobre as diferenças de um treinamento e um grupo de estudos, bem como definimos o que esperar de um e de outro. Também aproveitamos para refletir sobre como tirar melhor proveito de um ou outro treinamento e qual o benefício para os centros de treinamento locais da criação de grupo(s) de estudo.
  3. Diferenças principais entre o AS2 e AS3 onde usamos como "cenário" um projeto recente no qual participei, para ilustrar o tipo de influência que essa migração (AS2 p/ AS3) pode apresentar. Nesta oportunidade discutimos performance, metodologias, influência de padrões e outras características.
  4. Esclarecimento sobre Flash, Flex, AIR, Silverlight, Prism, JavaFX. Discutimos suas peculiaridades, suas definições, praticamos alguma previsão sobre o futuro de cada uma baseado em fatores atuais a respeito destas. Neste tópico, ainda há bastante o que se discutir e dismistificar. Muitos me procuraram para continuar o assunto particularmente por MSN e email, mas sugiro que isso seja feito na lista de discussões do MUGBA, para que a discussão possa ficar ainda mais rica e não limitar-se a uma única opinião/definição/visão.
  5. Iniciamos a definição de um roteiro de assuntos para os estudos, analisando o porque adotar uma ou outra ordem. À princípio resolvemos convencionar, baseado no maior interesse dos presentes, uma introdução ao Actionscript 3.0 e MXML baseando-se no Quick Start do Adobe Devnet. Porém creio que teremos que fazer, na proxima reunião uma introdução básica, à estrutura e aplicação de uma Classe AS3 no Flash CS3 por parte de algum presente que possa fazê-lo.
  6. Para poder ilustrar a aplicação do Flex e sua comparação com a adoção de AJAX para projetos similares, fizemos um breve estudo do exemplo FlexStore  onde através de uma explicação teórica sobre o desenvolvimento do mesmo, pudemos verificar as diferenças produtivas entre o desenvolvimento baseado em Javascript e o desenvolvimento baseado em MXML/AS3. Eu sugiro que algum membro do grupo de estudos que esteja apto, desenvolva um exemplo de uma interface simples desenvolvida em AJAX (pode-se usar alguma das APIs citadas, como ExtJS e JQuery), e similiar em MXML/AS3. Eu me disponibilizo a ajudar.
  7. À princípio as reuniões serão mensais com a próxima reunião pré-sugerida para 21 de junho (sábado) com horário à definir. o conteúdo desta reunião será o resultado (dificuldades, problemas, idéias) surgidas com o estudo dos QuickStarts.

quarta-feira, 14 de maio de 2008

Tutoriais Papervision3D

papervision3d Resolvi ir atrás de algum conteúdo para poder iniciar algum estudo melhor organizado no meu tempo livre e vou procurar partilhar o que achar aqui no TeclandoAlto. Há na verdade bastante conteúdo. Então, vou postar aqui os conteúdos seguindo a forma como vou me organizar para estudar. Quem tiver interesse, é só seguir, ajudar, compartilhar, etc. Ah! Cobrar tb pode!

Para começar, quem quiser ter acesso à API, disponibilizada como componente para o Flash, ou através do SVN no GoogleCode, seguem os caminhos:

Home Page no GoogleCode

Repositório SVN AS2

Repositório SVN AS3

Achei também uma listagem de tutoriais no site Flash Enabled:
http://flashenabledblog.com/2008/05/12/papervision3d-tutorials-in-flex-3/

Ao longo dos meus estudos, o que eu conseguir reunir no tempo que vou tentar dedicar, postarei aqui.

terça-feira, 13 de maio de 2008

MSNBC Spectra Visual Newsreader - Papervision3D

MSNBC Spectra Visual Newsreader Visualmente espetacular, leve (pelo menos tratando-se de bytes) e funcionalmente muito bem desenvolvido. Quem desenvolve na plataforma Flash da Adobe, sabe que a criatividade dos designers é o limite para o que se pode desenvolver com esta tecnologia. Porém nem sempre o criativo anda de braços dados com o funcional e é justamente este equilíbrio que me chamou a atenção neste excelente trabalho.

O PaperVision3D é definitivamente uma das melhores (senão a melhor) API para implementação de renderização 3D de elementos visuais, e este, foi um trabalho onde os seus recursos foram bem aplicados.

Para não deixar de obtervar de maneira crítica o conteúdo, só achei que o 3D podería ter sido ainda melhor aproveitado, usando por exemplo algo como o 3D Wall (componente), desenvolvido e comercializado pela equipe do FlashLoaded.

FlashPlayer x Silverlight

Vale citar que, para a comunidade de desenvolvedores da plataforma Flash (e da própria Adobe) outra grande importância do lançamento de um site deste nível baseado no FlashPlayer, é muito importante para confirmar que a Microsoft (e o Silverlight), mesmo com seu grande poder de disseminar tecnologia, tem um grande competidor à sua frente, em constante e pleno crescimento.

domingo, 24 de fevereiro de 2008

Flex Team anuncia novidades sobre o SDK

flex3_fx_124x120 Essa semana já fomos muito bem "preparados" para a chegada do Release final do Flex 3 SDK junto com o FlexBuilder com o post bem humorado do Ted Patrick (A long time ago in a galaxy far, far away...).

Agora a notícia vem diretamente da equipe de desenvolvimento do Flex, recheada com informações sobre como será o primeiro release como projeto open-source.

Dentre as informações importantes para quem já planejava fazer uso disso de alguma forma, seja participando ou apenas observando o desenvolvimento, já ficou claro como isso vai funcionar. O projeto tá possui inclusive, conforme o anúncio, um repositório SVN configurado.

Na verdade, creio que o mais importante era mesmo saber "o quê" sería realmente publicado lá, e o anúncio deixou tudo bem esclarecido.

AS3 & MXML Compilers / Debugger: Já era esperado, mas nem por isso é menos empolgante saber desta informação, pois o que isso vai trazer de melhoras para os desenvolvedores em torno da tecnologia, é praticamente impossível de se medir. Embora o FlexBuilder não faça parte deste projeto open-source, os desenvolvedores podem aguardar o aprimoramente de ferramentas IDE já existentes para o desenvolvimento em MXML/AS3, além é claro de novas ferramentas que surgirão à partir disso.

SWFUtils Java Library: Essa, pelo menos pra mim foi uma boa novidade! Trata-se de uma biblioteca Java que permitirá não apenas LER dados de arquivos SWF para o formato do FlashPlayer 9.x, bem como escrevê-los.

Todos esses recursos reunidos certamente irão resultar não apenas em grandes novidades para nós desenvolvedores, como também para os consumidores dessa tecnologia. Ao menos as portas estão abertas para que novos produtos em torno do Flash Platform venham a surgir.

sexta-feira, 22 de fevereiro de 2008

Flex, Cairngorm e desenvolvimento progressivo independente de Business / Delegate usando "FakeData Factory"

flex3_fx_124x120 Eu já estava para fazer esse post desde ontem quando passei a adotar essa metodologia que vou apresentar aqui para o devido propósito anunciado como título, mas no momento de pausa para me atualizar do conteúdo de outros blogs que leio, acabei, por pura coincidência, me deparanto com um artigo publicado pelo Ricardo Pettine no Blog da DClick com o título “A EVOLUÇÃO DO MOCK USANDO O CAIRNGORM”, o que me levou a antecipar e mudar um pouco o objetivo desta postagem.

Na verdade, se observarem os 3 comments que fiz no Blog da DClick, vão ver que eu tentei fazer o assunto progredir lá mesmo, mas acabei esbarrando no problema de caracteres do código de exemplo que tentei postar.

(que vergonha a minha... enferrujando no uso de blogs... acho que se eu tivesse colocado um <code>, resolveria talvez).

Bom, vamos lá...

A minha intenção com o que eu fiz e proponho usar, é permitir o desenvolvimento de toda a estrutura de front-end no Flex, usando Cairngorm, independente da parte de Business/Delegate que referem-se justamente à integração com o Back-end.

Não fiz isso baseado em nenhum modelo, nem ao menos pesquisei alternativas. Simplesmente adotei e apliquei para uma necessidade atual que tive em um projeto no qual estamos redefinindo todo um framework de backend (ColdFusion), mas que por já ter todos os dados e requisitos especificados, obviamente permitia o progresso individual do desenvolvimento do Front-end.

Então, são os requisitos para aplicar esse recurso:

  1. Utilizar o framework Cairngorm (embora possa ser aplicado em qualquer situação onde o MVC seja a base de desenvolvimento)
  2. Ter os ValueObjects (VO) ou DataTransferObjects (DTO) definidos.

Com os requisitos atendidos você imediatamente compreenderá que a implementação proposta será aplicada nos Commands, no caso da arquitetura do Cairngorm.

Meu exemplo se baseia em um EmailLoadAllCommand, que por sua vez instanciaria um EmailDelegate e então o método loadAll(). O Result nesse caso trabalharia com o recebimento de uma array de instancias de EmailVO.

Apenas para referência, o método execute() de EmailLoadAllCommand:

public function execute(event:CairngormEvent):void{
var delegate:EmailDelegate = new EmailDelegate(this);
delegate.loadAll();
}

A alteração seria feita exatamente aqui, eliminando neste momento o Delegate e consequentemente a implementação de Responders para tratar o resultado da atividade do Delegate. O código acima alterado para usar a solução proposta pela implementação da classe EmailFakeCollection.as que apresentarei logo após:

public function execute(event:CairngormEvent):void{
//var delegate:PessoaFisicaDelegate = new PessoaFisicaDelegate(this);
//delegate.loadAll();
EmailModel.getInstance().emailCollection = EmailFakeCollection.generate();
}

Repare que estamos no método execute(), alterando o Model diretamente, com o dado solicitado. Neste caso apenas antecipamos o que só ocorrería no result() do responder que sería especificado no instanciamento do Delegate.´

Considerando o exemplo acima, onde o Command teoricamente implementa mx.rpc.IResponder e portanto conterá o método result(), simplesmente mudamos a instrução de associação dos dados ao model de lugar.

A idéia então consiste em que a classe EmailFakeCollection (e todos os eventuais FakeCollections que o sistema necessitar) implementem um método estático generate() que por sua vez retorne um ArrayCollection simulando dados que seríam recebidos no result da classe apontada para ser o responder da aplicação.

Eu pessoalmente preferi implementar um parâmetro para o método estático generate() afim de que eu possa especificar um número de itens que desejo receber como retorno.

No caso do exemplo citado então, a proposta da classe EmailFakeCollection seria a mostrada abaixo, seguido da classe EmailVO para referência apenas:

package br.com.ir.pessoas.factory{
 
import br.com.ir.pessoas.vo.EmailVO;
 
import mx.collections.ArrayCollection;
 
public class EmailFakeCollection{
 
private static var fakeRawData:Array = [
{
id: 1,
email: "macieljr@gmail.com",
padrao: 1
},
{
id: 2,
email: "macieljr@interfacerica.com.br",
padrao: 0
},
{
id: 3,
email: "macieljr@ir.com.br",
padrao: 0
},
{
id: 4,
email: "owner@vpmjr.com",
padrao: 0
},
{
id: 5,
email: "publisher@teclandoalto.com.br",
padrao: 0
}
];
 
public function EmailFakeCollection(){}
 
public static function generate(_qty:int = 0):ArrayCollection{
 
var returnData:ArrayCollection = new ArrayCollection();
 
var totalItems:int = (_qty > 0 && _qty <= fakeRawData.length) ? _qty : fakeRawData.length;
 
for(var i:int = 0; i < totalItems; i++){
 
var email:EmailVO = new EmailVO(
fakeRawData[i].id,
fakeRawData[i].email,
fakeRawData[i].padrao
);
 
returnData.addItem(email);
 
}
 
return returnData;
 
}
 
}
 
}
package br.com.ir.pessoas.vo{
 
import com.adobe.cairngorm.vo.IValueObject;
 
[RemoteClass(alias="br.com.ir.pessoas.EmailVO")]
[Bindable] public class EmailVO implements IValueObject{
 
public var id:int;
public var usuario:String;
public var provedor:String;
public var padrao:uint;
 
public function set email(_email:String):void{
 
if(_email.length){
 
var emailParts:Array = _email.split("@");
this.usuario = emailParts[0];
this.provedor = emailParts[1];
 
}
 
}
 
public function get email():String{
 
return this.usuario + "@" + this.provedor;
 
}
 
public function EmailVO(_id:int = 0, _email:String = "", _padrao:uint = 0){
 
this.id = _id;
this.email = _email;
this.padrao = _padrao;
 
}
 
}
 
}

Eu acabei batizando isso de FakeDataFactory. Nem sei se o nome ja foi usado. Mas agora vou ficar de olho em temas como o abordado pelo Ricardo no blog da DClick para conhecer e aprender melhor formas alternativas de implementar isso.

Por enquanto esta forma me atende completamente. Inclusive, caso a aplicação especificasse a necessidade de criar um Factory (no padrão costumeiro da palavra mesmo) para o recebimento de dados no formato JSON, um XML ou qualquer outro tipo de serialização, eu simplesmente implementaría a classe normalmente e simularia dentro do meu FakeDataFactory o recebimento de dados e instanciamento através desse Factory de desserialização. Depois, na implementação final de integração com o Back-End, bastaría mover a chamada dessa implementação no seu local apropriado.

Qualquer dica à respeito do fundamento, outras formas de implementação e padrões já existentes é muito bem vinda!

segunda-feira, 23 de julho de 2007

Tutoriais - Venda antecipada - 50% desconto


Seguindo o POST anterior, uma outra novidade.
Quem leu o POST a respeito do que estarei fazendo nas novas empreitadas, viu que um dos tópicos são treinamentos online. Só pra dar uma aguçada no pessoal, devo antecipar que esses treinamentos serão inéditos aqui no Brasil e serão oferecidos via Breeze (hj conhecido como Adobe Connect).

Então estou em fase de desenvolver os conteúdos. Os treinamentos disponibilizados inicialmente serão de ColdFusion, Actionscript 3.0, Flash e Flex. Depois virão outros treinamentos, inclusive de tecnologias que não são da Adobe.

Na tentativa de financiar este trabalho inicial, estarei promovendo a venda antecipada dos conteúdos, no formato de slides, textos e arquivos de exemplo, com 50% de desconto.

Os conteúdos, custos iniciais e suas respectivas datas previstas de entrega são:

1 - Flash intermediário - Prazo: 10/ago - Valor: R$150*
2 - ColdFusion intermediário - Prazo: 10/ago - Valor: R$300*
3 - Flex intermediário - Prazo: 25/ago - Valor: R$200*
4 - Actionscript 3 intermediário - Prazo: 25/ago - Valor: R$225*
5 - Flex Avançado - Prazo: 10/set - Valor: R$300*

*(estes são os valores com 50% de desconto, relativo aos valores previstos para os treinamentos online que serão disponibilizados via Breeze)

IMPORTANTE:
O prazo citado é para entrega DA ÚLTIMA PARTE do conteúdo que será disponibilizado conforme estiver pronto. Os conteúdos 1 e 2 começarão a estar disponíveis a partir do dia 26/jul. Os conteúdos 3 e 4 a partir do dia 13/ago. O conteúdo 5 a partir de 28/ago. Ou seja, o conteúdo mais breve já estará sendo entregue a partir de 3 dias e o mais tardio em aproximadamente 30 dias.

Vale citar que esta pacote NÃO inclui suporte. São materiais de estudo individual que prefiro chamar de tutoriais por este motivo.

Estaremos planejando descontos para quem quiser adquirir os treinamentos online, via Breeze, incluindo suporte, posteriormente. Certamente existirão. Só não posso confirmar ainda o montante, mas estarei confirmando isso ainda esta semana aqui no Blog.

Interessados, por favor entrem contato através do meu email: macieljr@gmail.com

sexta-feira, 13 de julho de 2007

YouTube AS3 API ColdFusion Proxy

Eu estava utilizando a biblioteca AS3 de acesso a API do YouTube desenvolvida pelo Mike Chambers, Daniel Dura e etc, para desenvolver uma aplicação de exemplo com o Flex 2.01 (ainda) e tudo rolou direitinho até a hora de colocar o "brinquedo" pra rodar online.

Essa biblioteca, foi escrita há muito tempo e durante esse período o YouTube fez a famosa e já tão comentada alteração no seu crossdomain.xml que causou a impossibilidade do Flash de fazer requests diretos à sua API. Para quem não sabe, pode ler a respeito aqui ou aqui, por exemplo...

A solução:
Criar um script server-side como proxy para as chamadas da API AS3. Assim, você configura o crossdomain.xml no seu domínio e tá tudo resolvido.

Na preguiça, meu primeiro passo foi procurar no Google pra ver se alguém já tinha escrito um em ColdFusion e disponibilizado. Não sei se não procurei direito mas não encontrei nenhum. Então, não teve outra saída. Criei o meu. E depois de ficar simplificando pra lá e pra cá, ví que apenas 4 linhas de código resolviam a questão:


  1. <cfhttp method="get" url="http://www.youtube.com/api2_rest?#CGI.QUERY_STRING#" charset="utf-8" result="data"/>

  2. <cfset xmlData = xmlParse(data.fileContent)/>

  3. <cfcontent type="text/xml; chatset=utf-8"/>

  4. <cfoutput>#toString(xmlData)#</cfoutput>



Depois é só mudar a referência à chamada da API do YouTube na Classe AS3 com.adobe.wepapis.youtube.YouTubeService.as:

De:

  1. public static var END_POINT:String = "http://www.youtube.com/api2_rest";



PARA:

  1. public static var END_POINT:String = "http://seuserver.com.br/Wrapper.cfm";



Isso basta! E espero que sirva para mais alguém.

Detalhe: A montagem da imagem que consta no início deste post, contém uma foto dos disquetes de instalação do ColdFusion 1.5. Eu estava procurando uma imagem com um logo interessante para ilustrar esse post, quando me deparei com ela e resolvi usar. Lembro de quando recebi estes 15 disquetes por correspondência para iniciar o uso desta tecnologia. Interessante depois de ter feito o Download da última versão Beta com mais de 310MB. Seriam hoje, aproximadamente 258 disquetes! Bom... pelo ao menos, o que evoluiu no tamanho, evoluiu também na qualidade e nos recursos. Já o custo, é bastante inferior ao da época dos disquetes. E pra causar polêmica: Muito mais barato inclusive do que muita opção free por aí! ;-)

terça-feira, 10 de julho de 2007

Interscriptável


Mais uma palavra para o nosso meio? Pode ser...
Essa palavra surgiu no meio de uma discussão técnica entre o Rafael Neri da BDG e eu quando discutíamos uma questão interessante a respeito de uma funcionalidade peculiar da nova geração do FlashPlayer (9 em diante) a respeito do AVM (Actionscript Virtual Machine) que o compõe.

Pelo fato de termos 3 versões do Actionscript (1, 2 e 3 ou AS1, AS2 e AS3), o AVM é ainda "dividido" em 2 versões. Temos o AVM1 que interpreta o código Actionscript 1 e 2, e o AVM2 que interpreta a mais recente versão, o Actionscript 3.

Como o termo surgiu?
Finalizando o projeto de re-escrita do site promocional da Preview, o OQueSeFazPorAi (http://www.oquesefazporai.com.br . O que está no ar ainda é a versão original escrita em AS2. Publicarei aqui o anúncio da nova versão quando esta estiver no ar.), esse assunto ficou bastante em pauta quanto tivemos a necessidade de carregar um Movie escrito em AS2, no novo Core que desenvolvemos para o site, todo escritp em AS3. Ocorre que na versão anterior do site, todo escrito em AS2, embora o Core fizesse o carregamento do Movie, o descarregamento (unload) era feito pelo próprio Movie carregado. além de operar outras instruções no própio Core.
Dado o fato do FlashPlayer ser constituído pelo AVM1 e AVM2, podemos em um filme AS3 carregar um filme AS2 ou AS1.
Como isso é feito?
O AVM2 possui uma classe interna chamada justamente AVM1Movie sob a qual o filme AS1 ou AS2 carregado é instanciado, permitindo assim um controle básico e portanto muito limitado deste. Essa classe é constituída basicamente pelas propriedades (limitadas) da Classe MovieClip, a qual óbviamente ele extende, limitando-se também a não possuir nenhum método nem tão pouco acesso aos elementos que fazem parte deste Movie AVM1 carregado.

Daí o surgimento do termo INTERSCRIPTÁVEL!

Em nossa discussão técnica, tive que explicar ao Rafael que um dos procedimentos que teríamos que adotar no desenvolvimento da nossa solução, dava-se pelo fato de que o Core que desenvolvemos não era INTERSCRIPTÁVEL com o Movie escrito em AS2.
Portanto, nossa solução sería re-coordenar o controle dos itens antes controlados no Core, por parte do Movie carregado, para que esse controle fosse todo feito por parte do próprio Core, ou re-escrever todo o Movie geralmente escrito em AS2, traduzindo-o para AS3.

Por questões de prazo, a escolha foi por fazer pequenas alterações no Movie AS2, permitindo e transferindo todo o controle de interações para o Core em AS3.

Está aí a explicação para o termo INTERSCRIPTÁVEL!

Se a galera do AURÉLIO, MICHAELIS e outros dicionários precisarem de uma ajuda (à ser melhorada, claro), aí vai:

Interscriptável: Capacidade de um script (relativo a mini-programas escritos em determinadas linguagens. Ex: Actionscript, Javascript, etc) operar cooperativamente, ou ainda em conjunto, com outro script, da mesma linguagem e versão ou não.

segunda-feira, 28 de maio de 2007

Resenha: Palesta Apollo na UNIFACS

Em primeiro lugar, muito obrigado à todos que compareceram à minha palestra, realizada no último dia 26 de maio na UNIFACS (Imbuí/Salvador/Bahia). Mesmo em um dia de chuva, muita gente acordou cedo para ouvir o que eu tinha a dizer e pude perceber a atenção com a qual o conteúdo foi recebido. Meus sinceros agradecimentos!

Segue aqui, conforme prometido, uma resenha sobre o conteúdo abordado.

1 - Recapitulando o que foi discutido na palestra anterior (21/abr/07).

Na oportunidade anterior, apresentamos o Apollo e seus principais conceitos apresentando-os através dos seguintes tópicos:

  • O que é o Apollo?
  • Qual o objetivo do Apollo?
  • O que se pode fazer com o Apollo?
  • A nova realidade para designers e developers
Foi realizado uma revisão desses itens, aproveitando para nos comunicarmos em uma lingaugem mais direta e desta vez com a utilização de diagramas para explicar o que é o Apollo e como o mesmo apresenta sua funcionalidade em comparação ao FlashPlayer instalado na forma de um controle ActiveX ou Plugin sobre o Sistema Operacional. Desta forma pudemos explicar a diferença das aplicações desenvolvidas utilizando-se a tecnologia Flash-Platform para o modelo anterior ao Apollo e após a sua introdução. Isso ajudou a deixar claro para os participantes, qual o objetivo do Apollo.

Diversos exemplos de aplicações foram apresentados para os participantes presentes, demonstrando o poder do Apollo e principalmente os recursos diferenciais que este disponibiliza aos desenvolvedores. Para uma fácil referência, utilizei os exemplos citados pela própria equipe da Adobe no site http://labs.adobe.com . Dentre os principais:

- Finetune. Discutindo inclusive sobre a importância do Apollo em uma análise particular do modelo de comércio possibilitado a partir de sua introdução.
- Fresh. Demonstrando a riqueza de interação já conhecida possibilitada pelo Flash/Actionscript em Rich Internet Applications, e adicionalmente um uso importante do recurso de renderização de HTML/CSS/Javascript possibilitado pelo controle HTML presente para esta finalidade.
- DryerFox. Demonstrando um uso divertido do controle HTML.
entre outros...
- Tweetr. Mais uma implementação de integração com o site Twitter.com. Para quem ainda não sabe, trata-se de um site estilo Blog Instantâneo onde as pessoas publicam simplesmente o que estão fazendo a cada momento. Curiosamente, aconselho conhecer o projeto TwitterVision 3D que não foi apresentado na palestra. Trata-se de mais uma interessante aplicação de integração com o Twitter, desta vez desenvolvido em Flex, integrando uma API 3D.

Finalizando esta primeira parte da agenda, discutimos sobre um novo cenário de oportunidades para designers e developers, debatendo principalmente sobre o baixo impacto de investimento intelectual (portanto, consequentemente financeiro) para aproveitamento destas oportunidades, uma vez que todo o conhecimento necessário por parte dos desenvolvedores de soluções web, são simplesmente reutilizados para a abordagem de soluções desktop adicionais, complementares ou isoladas de conteúdos e/ou soluções já desenvolvidas utilizando as tradicionais ferramentas Adobe para este propósito (Flash, Actionscript, Flex, Dreamweaver, Fireworks e uma linguagem server-side semelhante em funcionalidade ao Coldfusion).

2 - Últimos acontecimentos:

Nesta segunda parte, apresentei aos participantes do evento, notícias a respeito dos principais acontecimentos que influenciaram o meio relacionado ao Apollo. Os principais temas foram:
Apresentamos a notícia do Flex open-source abordando inclusive assuntos relacionados à mudança de estratégia e importância da aquisição da Macromedia por parte da Adobe no que diz respeito principalmente à influência deste acontecimento na estratégia de comercialização e abordagem comercial sobre os produtos herdados desta aquisição. Foi possível avaliar as boas consequencias disto para a comunidade desenvolvedora e tentar arriscar inclusive apostas em notícias semelhantes quanto à outros produtos da Adobe, inclusive o Apollo, consequencia que parece ser até mesmo óbvia.

Anunciei aos que ainda não sabiam da notícia, a API disponibilizada publicamente por Matt MacLean em seu site, ainda sem um modelo de licença definido por tratar-se de um experimento, que permite o acesso direto (sem o uso de um middleware) ao banco de dados mySQL.
Para exemplificar o seu uso de maneira rápida, apresentei o seguinte código fonte, disponível aqui de forma completa (com comentários inclusive) pois nos slides ele encontrava-se particionado por razões claras aos presentes (resolução de vídeo, melhor apresentação, etc.):

<?xml version="1.0" encoding="utf-8"?>
<mx:ApolloApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" width="400" height="320" resizable="false">
<mx:Script>
<![CDATA[
//importação das classes referentes à API disponibilizada em http://maclema.com/asql
//desenvolvida por Matt MacLean
import pl.mooska.asql.*;
import pl.mooska.asql.events.*;

//declaração da variável que irá manter os dados recebidos.
//a metatag [Bindable] permite que a mesma seja utilizada como valor de
//parametro em tags MXML que necessitem ter acesso à mesma.
//no exemplo atual, vamos defini-la como a fonte de dados do data-grid
//de nome de instância "grid", através do parâmetro "dataProvider" que
//o controle do tipo grid disponibiliza
[Bindable]
public var recordset:Array;

//instancia da conexão com o banco de dados mySQL
private var connector:Asql;

//uma variável para manter as mensagens à serem apresentadas no
//controle tipo label que temos na interface
//o "bind" desta variável será utilizado no parametro "text" do
//controle "label" instanciado como "lblMessage" na porção MXML
//deste código
[Bindable]
public var connectorStatus:String;

public function startApp():void{

connector = new Asql();

connector.addEventListener(SQLEvent.CONNECT, onConnect);
connector.addEventListener(SQLEvent.SQL_OK, onProcessed);
connector.addEventListener(SQLEvent.SQL_DATA, onData);
connector.addEventListener(SQLError.SQL_ERROR, onError);

connector.connect("ip_ou_dominio", "usuario", "s3nh4", "nome_do_banco");
connectorStatus = "Tentando conectar...";

}

private function onConnect(e:SQLEvent):void{
connector.query("SELECT * FROM tabela");
connectorStatus = "Conexão OK! Solicitando dados...";
}

private function onProcessed(e:SQLEvent):void{
//actions for an ok update or insert action result
connectorStatus = "Dados processados!";
}

private function onData(e:SQLEvent):void{
recordset = e.data;
connectorStatus = "Dados recebidos!";
}

private function onError(e:SQLError):void{
connectorStatus = "Erro na conexão!";
}

]]>
</mx:Script>
<mx:Label text="Apollo x MySQL access sample" fontFamily="Verdana" fontWeight="bold" fontSize="16"/>
<mx:DataGrid id="grid" dataProvider="{recordset}" width="298"/>
<mx:Button label="Connect and get data" width="159" id="btn" click="startApp()"/>
<mx:Label text="{connectorStatus}" width="301" textAlign="center" fontWeight="bold" color="#ff0000" id="lblMessage"/>
</mx:ApolloApplication>




ATENÇÃO:
No código acima onde temos:

connector.connect("ip_ou_dominio", "usuario", "s3nh4", "nome_do_banco");


Deve-se alterar o seguinte:
ip_ou_dominio: o IP do servidor onde encontra-se a instância do seu banco de dados mySQL ou o seu nome de domínio. Exemplo: 192.168.0.1 ou localhost
usuario: o usuário no servidor mySQL que possui acesso ao banco de dados que irá ser consultado.
s3nh4: a senha respectiva ao usuário especificado.
nome_do_banco: nome do banco de dados no servidor mySQL contra o qual será feita a consulta.

O seguinte esquema pode ser utilizado para criar a tabela de exemplo no seu servidor mySQL caso você queira testar o código acima:

CREATE TABLE `users` (
`username` varchar(15) default NULL,
`id` int(10) unsigned NOT NULL auto_increment,
`fullname` varchar(45) default NULL,
PRIMARY KEY (`id`)
) TYPE=InnoDB;

INSERT INTO `users` (`username`, `id`, `fullname`) VALUES
('vpmjr', 1, 'Vicente Junior'),
('commander', 2, 'Neil Armstrong'),
('moonPilot', 3, 'Edwin Aldrin'),
('commandPilot', 4, 'Michael Collins');

Você deverá ter instalado e configurado devidamente os seguintes softwares para proceder com o teste e saiba operá-los:
Caso você ainda não tenha instalado e configurado os softwares acima, aguarde pois estarei publicando tutoriais a respeito destes procedimentos em breve.

Adiante, discutimos a respeito dos seguintes temas:

Sería o Silverlight finalmente o tal do FlashKiller? Uma ameaça? (sub-tema: Já não ouvimos esta história antes?) Definitivamente não existe esta comparação e isso ficou muito claro ao final da discussão. O posicionamento de ambos é totalmente diferente. Farei mais posts a respeito deste assunto aqui no Blog.

Após isso, introduzí à questão apenas por intenção de adicionar informação aos presentes, o JavaFX e também discutimos quanto ao seu posicionamento. Ficou evidente que o Silverlight e o JavaFX são concorrentes diretos mas que o Apollo possui algusn diferenciais importantes a começar por seus fundamentos e objetivos que são divergentes a estes dois. Como no tópico do Silverlight, mais posts serão colocados aqui abordando o tema mais profundamente.

Finalizando

Tratamos a respeito de conhecimentos necessários para começar a desenvolver com o framework do Apollo, treinamentos que estou ministrado para implementar ou complementar tais pré-conhecimentos, bem como os treinamentos voltados exclusivamente para o Apollo que já estou ministrando (extra-oficialmente) para os usuários interessados.

Caso você esteja interessado em algum treinamento, leia os detalhes disponíveis neste post e entre em contato a partir do meu email.

Os treinamentos são ministrados individual e particularmente, bem como para grupos/empresas.

Até a próxima! Mais posts a respeito dos assuntos aqui abordados estarão disponíveis nos próximos dias.