Posso dizer que, de início, pensamos em colocar um limite de 100 pessoas no evento, mas depois pensamos que a procura não iria ser muita, uma vez que no último encontro eramos apenas… três pessoas!

No entanto, lá nos aventuramos em colocar o limite de 70 + 10 speakers e a aposta foi ganha! No final, e totalizando toda a gente, eramos 67 pessoas juntas no evento!

O que correu bem?

• O almoço

- Eramos cerca de doze pessoas e foi interessante falar das expectativas sobre o evento, de conversar com pessoas com quem não tivemos hipótese de trocar ideias noutros eventos, etc. O lombo estava bom e mesmo a queimar as duas, lá conseguimos pagar todos e lá fomos para o local onde ia decorrer o evento.

• O evento

- Como todos notaram, o evento começou com cerca de vinte minutos de atraso. Não havia problema se ninguém se esticasse nas apresentações (o que não foi o caso!).

- Uma coisa a referir foi o espírito de todos! Durante as cerca de cinco horas em que tivemos no edifício Maus Hábitos houve sempre um bom convívio, as piadas típicas dos apresentadores ao qual a plateia correspondia sempre com umas gargalhadas. O que dizer do Luís Martins que arranjou um milagroso projector porque o nosso era “esverdeado”.

• O jantar

Depois de tantas horas no evento, que bem que soube comer umas belas pizzas de… 50 centímetros, no S. Marino! Eramos também cerca de doze pessoas e o convívio foi muito interessante, dando para trocar ideias e falar sobre o que se passou no evento, sobre as novas tecnologias, experiências que tenhamos tido, etc. Tudo acabou, por volta da uma da manhã no Rivolli, onde decorria o Fantasporto.

• Conclusões

Como nunca nada corre perfeito, temos noção que houve várias falhas, mas todas elas devido à pouca experiência que os organizadores tinham em realizar eventos.

1. O local – Embora o local fosse interessante, era notório a falta de condições para a projecção dos conteúdos através do projector. O facto de ter ficado muito escuro a partir do meio do evento, fez com que o público quase não conseguisse ver os speakers.
2. Talvez devêssemos ter apenas uma refeição em conjunto. Assim, podíamos tentar ter mais pessoas no mesmo espaço;
3. O controlo do tempo. Esta sim, uma falha um pouco grave, umas vez que perdemos completamente a noção do tempo;

Apresentações:

Ainda não consegui que os vídeos ficassem todos disponíveis uma vez que temos limite, tanto no Vimeo, como no Youtube, de tempo para os vídeos (só dá para 10 minutos em cada).

No entanto, já podem ver o vídeo de introdução do evento aqui

Sendo assim, ficam aqui as apresentações que já nos foram facultadas pelos speakers. Quando me enviarem mais, actualizarei aqui o post

Mauro Martins:

Web – Construir é diferente de ver

Nuno Gomes:

HTML 5, a Realidade da Utopia

Miguel Pinto:

Zend Framework e Flash

Felipe Ávila:

The Usability Page

Cumprimentos a todos, e preparem-se porque vêm aí mais!

Marca desde já essa data na agenda e prepara-te para passar uma tarde bem disposta juntamente com pessoas que partilham contigo interesses e paixões pela Internet e não só!

Vamos ter speakers a abordar temas de elevado interesse da actualidade que te vão deixar com água na boca para aprender, explorar e procurar as inovações para o design e desenvolvimento das tuas aplicações!

O universo de desenvolvimento de aplicações web está em perfeita erupção! Não são só as tecnologias cliente, mas toda a “pilha” de desenvolvimento com as suas diversas tecnologias, linguagens e ferramentas está a ser posta em causa e cada um quer encontrar o seu nicho nesta realidade. Não perca esta oportunidade de ouvir alguns experts  portugueses na área do desenvolvimento de Rich Internet Applications.

Como se isto não fosse suficiente ainda vamos ter prémios para distribuir pelo pessoal que estiver a assistir que vão desde licenças de software a vouchers de cursos de formação e outros.

Não percam! Dia 6 de Março, no Edifício “Maus Hábitos”, às 14:00, e sim, no Porto!

Inscreve-te em: http://riapt.stagehq.com/events/182/booking/new

Agenda

É sabido que a minha vida roda em redor das RIAs na plataforma Flash, que sou Adobe Certified bla bla, Adobe Community bla bla, etc. Mas também tenho cabecinha para tentar olhar para o mundo de forma imparcial, e acima de tudo pragmática. Até porque, não esqueçamos, há uns anos eu era anti-Flash. E depois ganhei juízo, e aprendi que não se deve criar preconceitos sem conhecermos realmente aquilo de que falamos. E é consoante essa visão que faço este post.

Prólogo

Antes de mais, um pouco de background na coisa.  A Apple lançou este mês o iPad, um meio termo entre um iPhone e um netbook, que em teoria é um dispositivo que se diz por aí ser revolucionário. Porém, o iPad, tal como o iPhone, não traz – nem se prevê que venha a trazer – suporte ao Flash Player. Imediatamente, a blogosfera e o twitter, encheram-se de reacções, onde muitos ditos puristas dos standards, apple-fanboys, ou simplesmente anti-flashers, começaram a festejar o início da morte do Flash. A atitude da Apple é sem dúvida uma afronta à Adobe que vai mexer com a taxa de penetração e credibilidade do Flash Player. E no meio deste hype, li e reli centenas de vezes um conjunto de mitos que por aí circulam, que não me conseguiram deixar impávido e sereno.

Flash vs HTML

Em duas palavras: comparação ridícula. Alhos com bugalhos. Resume-se a:

• HTML-> Documentos
• Flash -> Estados.

Enquanto que o  primeiro (HTML), serve para definir estruturas de dados, o segundo serve para criar aplicações. São duas tecnologias distintas com propósitos distintos. E o problema surge quando um começa a entrar no território do outro: não faz sentido usar o Flash para fazer um blog da mesma forma que não faz sentido usar o HTML para fazer uma ferramenta de manipulação de imagem.

Ambas as tecnologias devem complementar-se.
Para os menos atentos, nós na Webfuel desenvolvemos RIAs na plataforma Flash para a banca (gestão de finanças pessoais) e investimentos (plataformas de trading). Fazêmo-lo usando as boas práticas de Engenharia importadas do mundo J2EE, e puxamos a plataforma ao seu limite (interfaces interactivos e animados, com multimédia, e paradigmas de usabilidade complexos). E fazêmo-lo desta forma porque é possível; porque a plataforma o permite. Perdoem-me os puristas, mas nunca seria possível actualmente fazermos o que fazemos – e como o fazemos – em HTML. Talvez daqui a… 5 anos. E aí o Flash já terá evoluido outros 5 anos…

“O Flash atrasa a minha navegação na net, faz o meu CPU disparar, e os banners irritam”

Verdade seja dita: banners são irritantes. Especialmente aqueles que aparecem sobre o conteúdo das páginas que queremos ver, não nos deixando clicar em nada até que o banner desapareça. Ou aqueles que fazem as ventoinhas do CPU disparar. Ou mesmo aqueles que crasham o browser. Mas a realidade é que tudo é um negócio, e os banners são a maior fonte de receita na internet. E os senhores do marketing ficam todos excitados com animações, sons, e interactividade, e lá surgem os banners em Flash por todo o lado. Colocando realmente a navegação mais irritante. E lenta. E problemática.
E se não existisse Flash (ou outro plugin com penetração semelhante)?
Seria tudo igual. Haveriam banners na mesma. Em Javascript, ou outra tecnologia. Igualmente irritantes, mas possivelmente igualmente (ou mais) pesados para o processador (a performance do Flash Player é superior à do Javascript ).
A culpa não é do Flash Player. Só se for culpado de ser o runtime com a maior taxa de penetração do mercado, e de ser tão fácil e rápido implementar algo impressionante na plataforma Flash.

HTML 5 vai matar o Flash

Há quem julgue que sim, mas Flash não é sinónimo de vídeo. O Flash serve para construir experiências multimédia e software. O HTML 5 não vem para substituir o Flash. Poderá, sim, (e provavelmente assim será) começar a substituir/ser alternativa ao Flash em muitos sites de vídeo (Youtube, etc). Mas mais uma vez, é comparar alhos com bugalhos. É dizer que, assim que o HTML 5 sair, será a plataforma preferencial para fazer aplicações de trading, com realtime data push, advanced charting, acesso à câmara e microfone, etc. Enfim. Nem é fácil comentar este mito, por ser completamente díspare da realidade. O HTML 5 será, na melhor das hipóteses, um substituto daquilo que foi o Flash Player 5. Para não deixar de referir que há sempre o risco das várias implementações de cada browser se tornarem na habitual dor de cabeça dos developers – algo que não existe no mundo da plataforma Flash.

O Flash Player encrava o MacOS…

… tal como o JAVA, o C++, ou mesmo o Javascript ou qualquer outra plataforma. Claro que é rídiculo comparar a estabilidade da Virtual Machine do Flash Player com a da JVM, mas é suficientemente robusta para suportar aplicações críticas de trading a fazer transacções de milhares de dólares diariamente. A acusação à estabilidade do Flash Player não se deve à tecnologia em si, mas sim aos maus developers que andam por aí. E, verdade seja dita, o mundo Flash está repleto deles. Developers que não sabem (nem querem saber) o que são boas práticas. Ou designers que decidiram aventurar-se pelo mundo do desenvolvimento. E aqui, a culpa do Flash Player é mais uma vez a sua alta taxa de penetração, e o facto de ser tão fácil fazer algo impressionante na plataforma Flash.
E depois entram as estatísticas. Se passarmos um dia em frente ao computador, abrimos o Word 4 ou 5 vezes, mas arrancamos o Flash Player umas 50 vezes – pelo menos. Cada SWF – banners, websites, RIAs, vídeos, etc – é uma aplicação diferente feita por pessoas diferentes (sejam bons ou maus developers). Não é preciso ser-se expert em estatística para terminar o raciocínio. A realidade é que diariamente me deparo com tanta coisa mal implementada na web que pessoalmente até fico admirado com a robustez do Flash Player.
Aqui na Webfuel somos pelo menos 6 pessoas a puxar diariamente o Flash Player aos limites, de onde pelo menos uma é adepta (quase fanática) da Apple. E a realidade é que o Flash Player se aguenta perfeitamente com as nossas experiências e produtos.
Ainda assim, admito que há margem de melhoria na robustez do Flash Player, talvez começando por distribuir melhor os recursos consumidos por cada SWF, impedindo que um SWF problemático possa afectar outro.

Falta ainda dizer que, verdade seja dita, o Flash Player não encrava nenhum sistema operativo. Encrava, sim, o browser. E nos melhores browsers encrava apenas o tab onde o SWF ranhoso encravou.

O Flash Player é demasiado lento para correr no iPhone. E no iPad.

A Apple acusa a Adobe do Flash Player consumir demasiados recursos, pelo que não o poderia colocar a correr no iPhone. Mas a realidade é que o Flash Player 10.1 – que foi especificamente optimizado para dispositivos móveis – corre em telemóveis com poder de processamento teoricamente inferior ao do iPhone. O que é suspeito.

No entanto, para piorar, o iPad também não suporta o Flash Player. Quer isto dizer que a Apple lançou um produto de $600 que não tem poder de processamento para o Flash Player?

Segundo a Adobe, ao contrário da Microsoft, a Apple nunca ajudou a Adobe a optimizar o Flash Player para o MacOS. Segundo a Apple, a Adobe é preguiçosa.

Conclusões

A minha preocupação é desenvolver produtos que façam sentido para o consumidor final. Produtos de software ubíquos, acessíveis de qualquer local, computador, sistema operativo, ou browser, com um único codebase, e com preocupações acrescidas ao nível do interface e interactividade. Rich Internet Applications. Este é o futuro, podermos aceder às nossas aplicações e dados a partir de qualquer local.
E estando a trabalhar para isso há alguns anos, a realidade é que me sinto ofendido de ser apanhado no meio de uma guerrazinha de egos (e de milhões de dólares) onde no fundo quem fica a perder somos todos nós – tanto developers como consumidores.

A Adobe publicou ontem uma imagem muito interessante e elucidativa para representar o ecosistema da Flash Platform. Na imagem é possível ver o universo das ferramentas Adobe, e a forma como se interligam.

À esquerda, a azul claro, temos as ferramentas de design: After Effects, Adobe Illustrator, Fireworks e Photoshop. Com estas ferramentas os designers podem criar o aspecto gráfico das aplicações / sites / experiências / etc, sendo este exportado num novo formato, o FXG. O FXG é um novo formato da Adobe baseado em XML para representar elementos gráficos, e que é compatível com o universo que circunda a plataforma Flash.

A azul escuro temos as aplicações de desenvolvimento: o Flash IDE, Flash Catalyst (anteriormente conhecido por Thermo), e o Flex Builder. O Flash IDE e o Flex Builder são os nossos já velhos conhecidos, sendo o primeiro mais virado para Interaction Designers que procuram um IDE visual, e o segundo para developers que procuram um IDE virado para código. O Flash Catalyst é uma ferramenta que ficará no meio, entre o Flash e o Flex Builder que permitirá a Interaction Designers utilizar um ambiente gráfico e intuitivo para importar layouts feitos nas ferramentas de design, e convertê-los através de alguns cliques para aplicações, podendo ser adicionada interactividade. O resultado o Flash Catalyst é MXML (bem formado, segundo dizem) que depois é entregue aos developers para implementarem toda a parte dura do código. Segundo se diz, o Flash Catalyst pode também carregar MXML já alterado pelos developers (corrijam-me se estiver enganado), pelo que permitirá que ambas as equipas – developers e designers – possam trabalhar ao mesmo tempo, recorrendo a um source control. O Flash Catalyst está ainda a um ano de ser lançado em versão final, pelo que durante este período serão certamente disponibilizadas versões beta e de preview.

A cinzento, em cima, temos o Flex SDK, a framework de eleição para desenvolvimento de RIAs. É composta por um conjunto de componentes, e ferramentas que assentam em Actionscript 3, para desenvolvimento rápido de aplicações. O Flex SDK está actualmente na versão 3, mas a versão que se segue (nome de código: Gumbo) vai trazer novidades absolutamente estontantes. Sendo open-source, é possível acompanhar o desenvolvimento do Gumbo, e inclusivé, fazer já aplicações com a actual versão. As milestones do Gumbo são:

• lançamento do MAX preview agora durante o MAX;
• versões Beta 1 e Beta 2 na primeira metade de 2009 (aposto em Fevereiro e Maio);
• versão final na segunda metade de 2009.

As ferramentas acima “não fazem mais” que gerar ficheiros SWF que são depois interpretados e executados nos devidos runtimes: o Flash Player, que corre dentro do browser, e com limitações de acesso à máquina do utilizador (obviamente por motivos de segurança), e o Adobe Air, que permite que os SWFs possam ser instalados nos computadores dos utilizadores e correr como aplicações desktop, com acesso à maquina do utilizador como qualquer outra aplicação (i.e. leitura do disco, clipboard, etc). O Flash Player está neste momento na versão 10 que introduz uma panóplia de funcionalidades fantásticas: suporte nativo a 3D, FileReference local, suporte a filtros avançados (Pixel Bender), suporte avançado a texto, melhor performance com suporte a aceleração pela placa gráfica, etc.

De referir que os runtimes acima são compatíveis com os principais sistemas operativos, nomeadamente Mac, Windows e Linux – e a grande novidades do Max: graças ao Open Screen project temos também o Flash Player 10 em Symbian, Windows Mobile, Wii, Playstation, etc.

As aplicações (SWFs) que assentam sobre os runtimes acima serão fat clients descarregados para as máquinas dos utilizadores (pelo browser, ou instalados com Adobe Air), e que poderão posteriormente comunicar com um servidor para trocar dados. Essa comunicação pode assentar em diversos protocolos e formatos, tais como simples texto, XML, SOAP (web-services), JSON, e AMF – o formato de dados em que assenta o Flash Remoting. Estes formatos podem ser trocados sobre HTTP ou HTTPs, Sockets, RTMP, entre outros.

Esta panóplia de formatos de comunicação permitem comunicar com quase todas as tecnologias server-side existentes no mercado, pelo que aplicações feitas em Flash são facilmente integráveis com plataformas existentes, sejam elas Adobe ou de terceiros. Da Adobe, temos os servidores especificamente criados para Flash: BlazeDS e Flash Media Server que introduzem funcionalidades de Data e Multimedia Streaming, entre outras. Depois temos os servidores ColdFusion e LiveCycle ES, de onde a minha funcionalidade favorita deste último é de longe o facto dos servidores poderem tomar a iniciativa de contactar os clientes e empurrar dados (i.e. dados dos clientes sincronizados automaticamente com o servidor). Apesar da Adobe fornecer as suas próprias soluções server-side, como dito acima aplicações Flash podem ser facilmente integradas com outras soluções de backend de entidades terceiras, como, PHP, JAVA, .NET, etc, desde que implementem algum dos protolocos de comunicação acima referidos. Como exemplos de plataformas, temos BEA, SAP, salesforce.com, WebSphere, Zend, etc.

Vendo esta imagem, é inevitável sentir orgulho de ter acreditado e escolhido um dia o caminho da plataforma Flash. Aquilo que começou um dia como uma ferramenta para adicionar animações a páginas Web, é hoje em dia a mais poderosa plataforma para criar aplicações distribuídas e interactivas. As nossas amigas RIAs.

É a primeira vez, na história do plugin, que é disponibilizado a versão para as plataformas Windows/Mac/Linux/Solaris ao mesmo tempo.

Relembro que das novidades mais importantes:

• Suporte para 3D
• Novo text engine (Saffron 3.1)
• RTMFP ( RTMP sobre UDP )
• Novo Codec de Audio (Speex)
• Novas APIs para desenhar
• Novo tipo de dados <Vector>
• Gerar som dinamicamente
• Acesso local ao FileSystem através de interação do utilizador

No labs encontra-se disponivel as release notes assim como os problemas que ainda persistem e o player pode ser encontrado aqui.

Aparentemente o problema surge quando o utilizador tem uma versão do Flash Player inferior a 9.0.115.0 e:

1. Foi colocado no servidor uma versão de debug do SWF;
2. Foi colocado no servidor uma versão de release do SWF, mas que carrega outros SWF’s compilados para debug.

No nosso caso, o problema era o segundo. Estávamos a colocar no servidor uma versão de release do SWF, mas que carregava um SWF feito no Flash por um designer que tinha deixada activa a opção de debug. A partir daí, todos os visitantes com uma versão do Flash Player inferior à referida acima deparavam-se com a mensagem acima.

Como garantir que um SWF está em versão de release?

Para os utilizadores do Flex 3, é preciso fazer “Project > Export Release Build”. A partir daí serão gerados na pasta “bin-release” SWFs em versão de release que não possuem informação de debug, ocupam relativamente menos Kb’s, e não mostram a mensagem acima. Este é o SWF que deve ser colocado no servidor, e não o da pasta bin-debug.

No Flex 2 não é necessário fazer o “Project > Export Release Build” visto que em cada compilação são criadas duas cópias do SWF: uma de release, e outra de debug. Deve ser colocado no servidor o SWF de release.

Para os utilizadores do Flash CS3, é necessário ir a: “File > Publish Settings > Flash” e desligar a opção “Permit debugging”.

Este problema pode ser chato para quem recebe SWFs feitos por outras pessoas (designers, por exemplo), que podem por vezes não estar compilados para release. Nesse caso a unica solução é pedir à partida aos designers para confirmarem que a referida opção está desligada.

Usar o Flash Switcher para verificar se o erro acima aparece

Habitualmente quem desenvolve costuma ter uma versão actualizada do Flash Player que não mostra o erro acima com SWFs de debug. Assim, como nas máquinas de desenvolvimento não aparece esse erro a solução seria fazer um downgrade do Flash Player e testar. Felizmente existe um plugin para o Firefox chamado “Flash Switcher” que permite ter na mesma máquina instaladas várias versões do Flash Player, trocando a versão com um clique. Assim, com este plugin basta escolher uma versão baixa do Flash Player 9 (por exemplo a r45), e abrir os sites normalmente. Se o erro aparecer, é preciso trocar os SWFs para a versão de release.

A partir da versão 9.0.115.0 do Flash Player este erro deixa de ser apresentado aos utilizadores, como referido neste post do Tinic Uro. Ainda assim, convém colocar as versões correctas de todos os SWFs no servidor para garantir que o erro não é apresentado a ninguém.

]]> http://www.riapt.org/2008/09/14/erro-where-is-the-debugger-or-host-application-running/feed/ 0 http://www.riapt.org/2008/05/16/flash-player-10-beta-disponivel-no-adobe-labs/ http://www.riapt.org/2008/05/16/flash-player-10-beta-disponivel-no-adobe-labs/#comments Fri, 16 May 2008 09:33:47 +0000 João Saleiro http://www.riapt.org/?p=264 A Adobe disponibilizou o Flash Player 10 no Adobe Labs. Esta nova versão do Flash Player traz novidades revolucionárias, como suporte de 3D nativo, aceleração por hardware, e suporte para filtros e efeitos criados pelo utilizador.

A versão do Flash Player disponibilizada é compatível com Windows, MacOS (>=10.4), Linux e Ubuntu.

Novas funcionalidades

Filtros e efeitos criados pelo utilizador > ver vídeo

Através do Adobe Pixel Bender quem quiser pode agora criar novos filtros e aplicá-los nas suas aplicações Flash de uma forma tão simples como fazia anteriormente com os filtros existentes. Os filtros criados pelo utilizador podem ser aplicados a qualquer tipo de DisplayObject, desde imagens e vectores a vídeo. Os filtros podem depois ser animados em runtime.

Suporte 3D nativo > ver vídeo

Podemos finalmente usar 3D nas nossas aplicações sem termos que recorrer ao Papervision 3D, Sandy ou Away3D, graças ao suporte embutido da coordenada Z. O melhor é ver o vídeo acima.

Melhorias drásticas no suporte a texto > ver vídeo

O suporte a texto foi drasticamente melhorado, permitindo:

• Aplicar anti-alias, rotações, etc, às fontes de sistema (device fonts);
• Suporte a texto right-to-left;
• Suporte a elementos tipográficos, como ligaduras tipográficas;
• Controlo do layout do texto através de tabelas, imagens inline, colunas;
• Suporte de anti-aliasing avançado (Saffron 3.1), que aumenta a performance e a qualidade das fontes anti-aliased;

Melhorias à Drawing API > ver vídeo

É agora muito mais fácil desenhar sem ser necessário recorremos à técnica do “lineTo”, “lineTo”, “lineTo”, sendo possível construir figuras complexas com relativa simplicidade. Uma das características da nova Drawing API é a possibilidade de alterar figuras já construídas – o que simplificará largamente o processo de se animarem figuras desenhadas pelo utilizador.

Aumento da performance visual graças a aceleração por hardware > ver vídeo

Através de um parâmetro no código de Embed do SWF o Flash Player passará a utilizar a placa gráfica para calcular efeitos de composição de bitmaps, filtros, blend modes, vídeo, etc, deixando mais espaço para o CPU respirar. Em utilizadores cuja gráfica na seja suportada, o Flash Player adapta-se para utilizar o processador, tal como acontecia antes.

Suporte de audio e vídeo melhorados

Foi introduzido o suporte de Dynamic Streaming que permite que seja ajustada automaticamente do lado do servidor a qualidade do vídeo de forma a optimizar a experiência de visualização do utilizador, evitando-se o efeito de “vídeo aos soluços”. Este ajustamento é feito através de cálculos de qualidade do serviço que medem tanto as condições da rede (largura de banda) ao longo do tempo, como informações do CPU.

O suporte de streaming por RTMP também foi melhorado, sendo introduzido o protocolo RTMFP que não é mais do que o RTMP a correr sobre UDP, obtendo-se uma performance muito superior.

O audio também foi melhorado com a introdução de um novo codec – Speex – que permitirá uma melhor qualidade de som com menores necessidades de largura de banda.

Acesso ao FileReference em runtime

Esta é uma das minhas funcionalidades favoritas! É agora possível utilizar a janela de browse para escolher um ou mais ficheiros no disco, manipulá-los localmente (sem ser preciso enviar para o servidor), e depois voltar a colocá-los no disco. Basicamente, o utilizador poderá agora escolher, por exemplo, uma imagem com vários megas, sendo imediatamente carregada no Flash Player (sem ser preciso ser enviada para o servidor). Poderão posteriormente ser aplicadas transformações à imagem, e ser gravadas localmente ou no servidor, caso o pretendamos.

Outras funcionalidades

• Gestão de cor – os SWFs podem ser convertidos para sRGB, e podem utilizar os perfis de cor (ICC) dos monitores;
• Geração dinâmica de som;
• Novo tipo de dados: Vector - este novo tipo de dados foi introduzido em conformidade com a norma EcmaScript 4, resultando em ganhos de performance. Um Vector é o mesmo que uma matriz, com a particularidade de que todos os elementos que agrega são do mesmo tipo de dados;
• Suporte de bitmaps até 16,777,216 pixeis (4096×4096)
• Controlo do context menu: temos agora mais poder sobre o context menu, sendo inclusivé possível colocar Rich Text nas opções do context menu;
• Suporte à norma GB18030 (o conjunto de caracteres chineses mais recente);
• Suporte ao Ubuntu OS.

Para experimentar a nova versão do Flash Player será preciso remover a anterior. Para quem trabalha com Flash/Flex e não quiser perder o Flash Debug Player, é recomendado que removam o Flash Player 9 apenas no Internet Explorer e instalem o Flash Player 10 para IE, mantendo o Flash Debug Player 9 no Firefox.

Mais informações sobre o Flash Player 10 aqui.

Porém, cada vez mais o futuro passa por usarmos outros dispositivos para ligar à Internet, além do nosso PC. Telemóveis, PDAs, a própria televisão, e até o nosso carro. Se pensarmos desta forma a penetração de 98% já não parece tão relevante…

Conscientes desta realidade, a Adobe deu um passo em frente ao anunciar o Open Screen Project. Este projecto consiste essencialmente em remover restrições de várias licenças, a publicação de alguns protocolos, e a consolidação de esforços com entidades como a Cisco, Intel, LG, Motorola, Nokia, Samsung, Ericsson, Toshiba, etc, etc, no desenvolvimento de uma solução verdadeiramente ubíqua a correr nos mais variados dispositivos.

O que se pretende é que o mesmo Rich Content que designers e developers colocam na Internet para correr nos nossos PCs através do Flash Player passe também a poder correr da mesma forma em qualquer dispositivo. Ou seja, os nossos sites, RIAs, e experiências multimédia passam realmente a poder ser acedidas de qualquer local e dispositivo.

Os primeiros passos que a Adobe vai tomar são:

Remoção das restrições na utilização das especificações SWF e FLV/F4V e
publicação das APIs de portabilidade do Flash Player para dispositivos

Com isto, quem quiser instalar o Flash Player num dispositivo pessoal poderá fazê-lo. O objectivo não é fazer com que comecem a surgir uma panóplia de versões do Flash Player incompatíveis entre si (perdendo-se a ubiquidade), mas sim permitir que outros vendedores possam desenvolver a camada necessária que permita integrar e correr o flash player nos seus próprios dispositivos.

Publicação dos protocolos Adobe Flash Cast e AMF

Não só foram publicadas as especificações SWF e FLV/F4V, como as especificações dos formatos de comunicação de dados usados pelo Flash Player. Pretende-se com esta iniciativa em específico que os mais variados dispositivos possam utilizar Flash/Flex Remoting e os protocolos Flash Cast para comunicar com o servidor.

Remoção dos custos de licenciamento do Flash Player e Adobe Air

Passa a tornar-se gratuíto distribuir o Flash Player e o Adobe Air. Quer isto dizer que quem quiser colocar uma versão do Flash Player junto da sua aplicação, ou mesmo equipar um modelo de telemóvel ou outro dispositivo com o Flash Player, poderá fazê-lo gratuitamente.

São no fundo notícias importantes tanto para o utilizador final como para quem desenvolve na plataforma Flash. Caminha-se para a ubiquidade, e cada vez mais teremos acesso às suas aplicações e experiências multimédia a partir de qualquer local e dispositivo.

Mais informações

• Press Release da Adobe
• Página oficial do projecto
• Vídeo do Kevin Lynch a explicar a iniciativa
• Explicação do Ryan Stewart

O bugtracker irá listar todos os bugs actuais que não estejam relacionados com segurança visto esses tornarem-se privados para evitar que se utilizem como exploits até serem corrigidos.

Não encontrou o bug no sistema? Têm a certeza que é um bug? Então já pode, não só adiciona-lo, como acompanhar a evolução da resolução do mesmo.

Mais um passo da Adobe que confirma o seu empenho em colaborar com a comunidade.

Justin Everett-Church ( Product Manager ) diz mesmo que poderão influenciar o que o próximo Flash Player irá suportar, bastando para isso, inserir um Enhancement Request ou comentar/votar num já existente.