Flash/ Flash Player 11

Atualização do Flash Player faz eu voltar atrás sobre o post

500x_adobe-flash

Reclamar sempre é fácil, dificil é admitir o erro e eu errei ao escrever o post sobre o Flash Player aqui.

Na verdade a Adobe havia corrigido o erro no último dia 21 de maio que justamente consertava esse entrave que havia mencionado no post, já que no calor da raiva e não verificando calmamente o erro, passou despercebido que lá 4 dias antes ela já tinha consertado.

fp11.7.169

A Atual versão 11.7.202 corrige o problema que eu relatei de lentidão, falha e cortes.

[quote style=”1″]Fixed Issues Audio stream cuts off on certain websites after 10-60 seconds(3541383)[/quote]

http://helpx.adobe.com/en/flash-player/release-note/fp_117_air_37_release_notes.html#fixed_issues

E o aplicativo que estava dando a manutenção justamente usava esse recurso.

Atualizei manualmente para versão 11.7.202 que é a versão estável para desenvolvedor

fp11.7.202

Quem estiver usando o Flash Player sem ser o debug que no caso é o usuário final, provavelmente já está atualizado para versão 11.7.203 via instalação silenciosa e nem deve ter notado o problema. Já que o intervalo foi de 10 dias até o problema ser resolvido.

Outras versões do Flash Player

A Adobe organizou aqui todas as versões disponíveis do Flash Player para download, inclusive para Android.

Para desenvolvedores Flex

Atualizem o playerglobal.swc para a última versão e adicionem o parametro -swf-version=20 para direcionar os usuários para o último player.

Quem estiver usando o último Apache Flex 4.9 SDK precisa fazer isso também.

Embora o Flash Player posssa ter os dias contados na Web, a Adobe tem se esforçado com seu compromisso de suporte para com o plugin. Dias melhores virão e nunca é tarde para se arrepender de um erro.

Erro corrigido!

Flash Lite/ Flash Player/ Flash Player 11/ Notícias

Adobe desiste do Flash Player plug-in para dispositivos móveis

Eu adoro ler uma boa notícia, mais quando eu leio notícias como essas eu realmente fico triste com a falta de cultura e informação desses redatores.

Pois bem, como você já deve ter lido por algum canal de notícias, a Adobe desistiu de continuar o Flash Player para dispositivos móveis assim como ela fez com o Flash Player para celulares Nokia, vai dizer que você esqueceu do Flash Lite ? Pois eu lembro.

Na lista de discussão flex-mobile eu colei minha opinião sobre o assunto, faço dela um complemento a minha resposta dada em Fevereiro de 2010 com o título (Flex e AIR para dispositivos móveis brigando contra o bixo papão), especialmente, para você que está desacreditado com o Flash, por que leu a notícia de algum site de ao invés de informar, vira senacionalista.

Alguém aqui fazia apps Flex para mobile que rodassem no Browser? Acho que
0,0001% fez ou faz.

O certo é Apps móveis, apps instaladas, o Flash/Flex/AS3 continua
excepcionalmente bem. A única mudança da Adobe é por parte de um plug-in,
que é parte progressiva de uma tecnologia de transição.
Continuem apostando no Flex, continuem apostando no HTML5/CSS3/JS.

Não é Steve Jobs ou coisa do tipo, é realmente questão de acordar, a Adobe
realmente caiu na real sobre o processo de estagnação mórbida que durava
mais de 3 anos em preservar o mesmo erro.

O que é dito hoje, não é mais válido daqui 6 meses. Quem realmente trabalha
com tecnologia sabe que ela muda constantemente.

EU Igor Costa e como CTO da RIACycle, eu continuo apostando em tecnologias
emergentes (HTML5/CSS3/JS) e em tecnologias sólidas(Flex/Flash/AS3/Java), o
que você não pode esquecer é de entregar o produto do cliente.
Se você entra no mercado de TI, você deve ser dinâmico assim como é o
mercado e as tecnologias que são colocadas em nossas mãos.

Positividade galera. O mercado está muito bom com todas essas mudanças.

Entenda as oportunidades, elas sempre estão presentes, não se deixe levar pelo lado impulsivo da notícia.

AIR 2.7/ AIR Mobile/ Flash Player

Adobe AIR 3.0 e Flash Player 11 Beta 2 já disponível no Adobe Labs

Cansado do Flash Player 10.3 e seus erros de HTTPS ?

Então prepare-se, por que além disso o Flash Player 11 vai vir bombando nessa versão. E não é papo de blogueiro não, juntei aqui algumas novidades que vai deixar muita gente com vontade de instalar ele antes mesmo de sair no mercado. Se você é desenvolvedor você já deveria ter instalado ele para testes.

Adobe AIR 3.0

Novidades que realmente valem a pena comentar

Stage3D Accelerated Graphics Rendering (desktop) — Stage3D (“Molehill”) é uma nova arquitetura para aceleração de hardware para renderização de gráficos criada pela Adobe. Stage3D tem API de baixo nível para habilitar gráficos avançados em 2D e 3D que funciona para múltiplas telas, como desktop, mobile e tv.
Ou seja,quem é acostumado com o OpenGL, softwares de 3D vai achar isso o máximo.

H.264/AVC Software Encoding for Cameras (desktop) — Transmitir agora sua webcam 720p virou real, o Flash Player agora dá suporte a isso, imagino as apps de video conferência utilizando isso em tempo real com uma qualidade excepcional. Vale lembrar que tem que ter banda de internet boa.

Native JSON (JavaScript Object Notation) — Suporte nativo a JSON, Uffa! até o JQuery tinha API o Flash Player tinha que ter.

Garbage Collection Advice — Melhorou muito, o lixeirinho querido dos desenvolvedores Flex/Flash, agora tem uma API que até agenda a coleta das informações.

Secure Random Number Generator — Muito bom, você pode gerar números random para encriptar banco de dados local, criar protocolos de comunicação seguras, Eu acredito que a Adobe adicionou isso ao AIR devido a Marinha Americana utilizar ele em alguns apps.

Native Extensions – Essa é uma das Maiores se não a Maior função revelação do AIR seja para Desktop ou Mobile a idéia do Native Extensions é gerar novas bibliotecas em C ou C++ para utilizar novas API. Ou seja é limitless, sem fronteiras.

Native Text Input UI (mobile) — Eles me ouviram, Eu havia postado isso como future request e não é que eles adicionaram, uma das minhas dificuldades em criar apps com AIR para Mobile era justamente em campos de texto, fica muito complexo a utilização das funções nativas que o dispositivo já possui no teclado, nada melhor que interagir com isso de uma forma mais nativa, mesmo programando em AS3. Onde você pode selecionar o texto, dar zoom no campo, pular de campo. E o bom disso tudo é que funciona em todos os dispositivos ( Android, Blackberry Tablet OS e iOs).

No Flash Player 11

Native 64-bit Support (Flash Player desktop) – Finalmente um Flash Player decente para quem tem Windows x64.

Quer ler todas as novidades? Leia aqui o release Notes

AIR 2.0/ Flash Player/ Flex/ Flex 3

Capturando erros no seu aplicativo RIA no FP 10.1 e AIR 2.0

É tão bom quando você tem alguns minutos livres durante a semana para escrever alguma coisa no blog, que ultimamente tem sido tão deixado de lado!
Uma das grandes novidades do Flash Player 10.1 é a possibilidade de capturar todos os erros gerados pela sua aplicação RIA.
Comumente, desenvolvedores e inclusive nós, tinhamos o hábito de capturar os erros apenas comuns em uma aplicação, por exemplo: IOError, Load Errors, Event Erros, Converter Errors, porém querendo ou não acaba escapolindo do nosso controle uns errinhos como 1009,1056,2048 etc. Esses erros é de tirar o fôlego quando se trata de experiência do usuário, e principalmente quando se tem vários deles.

Infelizmente, isso já era para estar pronto desde a versão 9. Como não tinha, faziamos isso como comentei acima. O que, torna uma tarefa repetitiva e acaba virando um saco fazer sempre aquilo, embora você tente ao máximo re-utilizar seu código.

Contudo, para a grande saúde mental de desenvolvedores, a Adobe decidiu criar esse tipo de captura, dando ao desenvolvedor a oportunidade de verificar quais erros estavam ou estão sendo gerados tanto em backgrounds não mostrados no Stacker ou mostrados.

Nem tudo é um mar de rosas, esse tipo de captura de evento só funciona se seu navegador estiver com o Flash Player do tipo debug, inclusive acaba ficando disponivel apenas para usuarios desenvolvedores, impossibilitando assim você de logar automaticamente um erro e captura-lo e adiciona-lo a uma base de análise, que é comumente feito em sistemas enterprise.

Como era feito a captura de erros até então no Flash Player 9 e 10:

Geralmente como nossos requisitos sempre são simples, nada tão complexo, preferimos usar não a classe padrão de Log de erro do SDK do Flex, por que é além do que agente precisa, e como também existem outras ferramentas e frameworks no mercado para log de erros.

A classe LogManager ela adiciona os erros a um arrayCollection:

package com.igorcosta.debug
{
	import mx.collections.ArrayCollection;
 
	public class LogManager
	{
		[Bindable]private static var _arrError:ArrayCollection = new ArrayCollection();
 
 
		public static function get errors():ArrayCollection
		{
			return _arrError;
		}
		public function LogManager()
		{
 
		}
 
		public static function addError(error:LogError):void
		{
				_arrError.addItem(error);
		}
 
	}
}

E a classe que agente costuma chamar de LogError, nada mais é que um VO/DTO, etc:

package com.igorcosta.debug
{
 
	public class LogError
	{
		public function LogError()
		{
		}
		public var stack:String;
		public var name:String;
		public var ID:String;
		public var message:String;
	}
}

Ai para usarmos em um simples teste de erro, veja o aplicativo que fizemos para esse post. Acho que vai ajudar vocês a melhor enxergar como é penoso o trabalho de capturar os eventos.

< ?xml version="1.0" encoding="utf-8"?>
<application xmlns="http://www.adobe.com/2006/mxml" layout="vertical">
 
 
	<script>
		< ![CDATA[
			import mx.controls.Label;
			import com.igorcosta.debug.LogManager;
			import mx.utils.ObjectUtil;
			import com.igorcosta.debug.LogError;
 
 
 
			public var err:LogError;
 
			public function provocarErro(tipo:uint):void
			{
				switch(tipo){
 
						case 1:
 
							try{
								throw new IOError("I/O Error, de leitura ou escrita");
							}catch(erro:IOError){
									err = new LogError();
									err.stack = erro.getStackTrace();
									err.message = erro.message;
									err.ID = String(erro.errorID);
									err.name = erro.name;
									LogManager.addError(err);
							}
							break;
					   case 2:
					   		try{
					   			var temp:Label;
					   			temp.text = 'test';
					   		}catch(erro:Error){
					   				err = new LogError();
					   				err.stack = erro.getStackTrace();
									err.message = erro.message;
									err.ID = String(erro.errorID);
									err.name = erro.name;
									LogManager.addError(err);
 
					   		}
					   break;
					   case 3:
					   		try{
					   				stackTest();
					   		}catch(erro:Error){
					   				err = new LogError();
					   				err.stack = erro.getStackTrace();
									err.message = erro.message;
									err.ID = String(erro.errorID);
									err.name = erro.name;
									LogManager.addError(err);
 
					   		}
				}
			}
			private function stackTest():void
			{
					stackTest();//loop de funcao da um erro de StackOverflow
			}
		]]>
	</script>
 
 
	<hbox width="100%">
		<button label="Provocar erro 1009" click="provocarErro(2)"/>
		<button label="Provocar erro IO" click=" provocarErro(1)"/>
		<button label="Provocar erro Stack Overflow" click=" provocarErro(3)"/>
	</hbox>
	<datagrid dataProvider="{LogManager.errors}" x="103" y="160" width="743" height="308">
		<columns>
			<datagridcolumn headerText="Nome do Erro" dataField="stack"/>
			<datagridcolumn headerText="Nome do Erro" dataField="name"/>
			<datagridcolumn headerText="Mensagem de erro" dataField="message"/>
			<datagridcolumn headerText="ID do erro" dataField="ID"/>
		</columns>
	</datagrid>
 
</application>

Capturando erros gerais ou “Global Error handler” no Flash Player 10.1 e AIR 2.0:

Agora usando o mesmo aplicativo, podemos capturar qualquer tipo de erro gerado pelo Flash Player, ou mau uso do código. Um detalhe é que o novo recurso do Flash Player o Uncaught Error e Uncaught Error Event, são passíveis de receber qualquer erro ocorrido no swf compilado. Veja o exemplo abaixo:

< ?xml version="1.0" encoding="utf-8"?>
<mx :Application xmlns:mx="http://www.adobe.com/2006/mxml" applicationComplete="completou()" layout="vertical">
 
    </mx><mx :Script>
        < ![CDATA[
        	import mx.controls.Label;
        	import com.igorcosta.debug.LogError;
        	import com.igorcosta.debug.LogManager;
            private function completou():void
            {
                loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, capturarErros);
            }
 
            private function capturarErros(e:UncaughtErrorEvent):void
            {
 
	        	if(e.error is Error){
 
	        		Error(e.error).getStackTrace();
	            	LogManager.addError(e.error as Error);
	         	}
	         	if(e.error is ErrorEvent){
	         		LogManager.addErrorEvent(e.error as ErrorEvent);
	         	}
 
            }
 
             private function identifica(e:MouseEvent):void
            {
 
                var minhaVar:Label;
                try
                {
                   minhaVar.text = " Ola Mundo" ;
                }
                catch (e:Error)
                {
                  // capturou o erro
                  minhaVar as Boolean;
                  trace(minhaVar.text);
                }
            }
        ]]>
    </mx>
     <mx :HBox width="100%" >
     <mx :Button label="Causar erro de  acesso indefinido" click="identifica(event);"/>
    </mx>
 
 
 
 
	<mx :DataGrid width="100%" dataProvider="{LogManager.errors}" x="29" y="182">
		</mx><mx :columns>
			<mx :DataGridColumn headerText="ID do Erro" dataField="errorID"/>
			<mx :DataGridColumn headerText="Nome do erro" dataField="name"/>
			<mx :DataGridColumn headerText="Mensagem de erro" dataField="message"/>
		</mx>

Lembrando que para você usar em seu projeto esse recurso do UncaughtError e UncaughtErrorEvent, você precisa ter o playerglobal.swc do Flash player 10.1, tanto para o Flash Player quanto para o AIR 2.0.

Os códigos fontes de ambos os aplicativos vocês podem baixar diretamente aqui.

AIR 2.0/ Flash/ Flash Lite/ Flex/ Flex Mobile Framework/ Open-source/ RIA/ Slider Framework/ Symbian

Flex e AIR para dispositivos móveis brigando contra o bixo papão

Já haviamos comentado aqui no site, que a Adobe estava trabalhando em versões do Flex e AIR para dispositivos móveis.
Essa semana a coisa esquentou, mesmo sendo no Brasil uma época em que todos os olhares estão voltados para a maior festa brasileira “O Carnaval”, algumas pessoas já devem saber da notícia via twitter ou pela lista de discussão.
Foi ai que decidir escrever alguma coisa mais completa, detalhada e que lhe ajudasse a entender melhor quais os principais desafios existentes hoje na plataforma Flash Player e AIR. Durante o texto quando me referir à FP significa que estarei me direcionado ao Flash Player , interop à interoperabilidade, GC ao Garbage Collector e Mobile para qualquer dispositivo móvel, celular, tablets, smartphones.

As mudanças

De 24 meses para cá houve-se uma mudança grande na maneira como as pessoas interagem com aplicações comerciais, tais ações são impulsionadas por toques visuais, realidade aumentada, projeções sobre qualquer superficie, interop entre diversos tamanhos de telas.
Para se ter uma idéia do grande problema, tente criar um design ou um simples site que seja visualmente fiel em TODOS os navegadores existentes no Mundo. imaginou? Fez aquela cara de “é???”. É bem por ai que começa os desafios.
E um dos grandes desafios do projeto Open Screen project é fazer com que outras tecnologias tirem vantagem do FP, já que a idéia do projeto Open Screen Project é fazer com que você escreva para uma única plataforma (FP), e ela seja auto escalonada para qualquer outra plataforma sem se preocupar com resolução de tela.
No ambito geral, o projeto open screen project que facilitar a vida do desenvolvedor e habilitar outras indústrias de criação de conteúdo e fabricação de bens de consumo duráveis, tirar projetos da experiências ricas criadas com o FP.

Telas diferentes
Tal iniciativa do openscreen project tem ajudado bastante ao time de engenheiros do FP e do AIR runtime à adotar uma estratégia singular colocando a plataforma Flash em um ambiente não apenas voltado para monitores, mais também para dispositivos móveis, telas sensíveis a toques, projeções, realidade aumentada.

Voltando ao tamanho de telas, imagine o seguinte, existe hoje smartphones diferentes em tamanho e funcionabilidades, a mesma coisa acontece nos monitores de mesa, que vão desde 9″ até 60″ onde o FP é testado.
Agora no mundo dos telefones, há uma grande diferença entre não só resolução mais área tangível, sensível ou não ao toque, rendenização, matrix de pixels, leds, lcds, existe uma inifinidade de mudanças que agravam e muito o desenvolvimento de uma experiência rica para celulares.

Um exemplo disso é a foto abaixo, que foi retirada do site mobiforge.
screen_sizes_small

A grande jogada é que no mundo PC/MAC muitos usuários tem uma resolução média aplicável, por exemplo 1024×768, tendo isso em mão é fácil escalonar qualquer experiência para o usuário, seja ela feita em Flash /Flex / AIR / HTML. O dificil ocorre quando esse âmbito é mobile, como comentei acima.

Tais dificuldades geram um enorme esoforço em fazer funcionar tudo em uma API que torne simples e que da mesma maneira que você usa em PC você possa usar para TV, HTPC,PC, Tablet e Smartphones.
Ai é onde entre o tal do bixo papão.
Em outras plataformas de desenvolvimento é uma mão de duas vias, você ajeita em um canto e do outro acaba desajeitando o que você havia feito. Como é o caso recente onde o youtube não aguentava mais consertar o suporte para o IE 6 que acabou bloqueando o site para quem usar o IE6 e pedindo para que quem tiver ainda essa raridade, atualizasse para uma versão mais nova e com menos riscos.

Do nível de execução

Outro bixo papão do nível dispositivos móveis é a tal capacidade de processamento. Em média hoje no Brasil um PC popular possui 1GB de RAM, Processador 1.2Ghz, HD de 80GB e tela de 15″. Esse é o padrão de mercado Brasileiro, tendo isso em mente eu consigo gerar grandes experiências sem ter que perder na qualidade final.
No mundo de dispositivos móveis a coisa é totalmente diferente do que você está acostumado a fazer, já que o padrão de mercado atual é 133Mhz de processamento, 64kb de memória e 168kb de HD, levando em consideração as configurações padrões existentes.
O que deve levar que quando se desenvolve experiências ricas para o usuário final que tenha um celular, você deve levar em consideração esse fator de “padrão do mercado” em conta. À não ser que você desenvolva para um padrão já específico que é o caso do próximo bixo papão “Plataformas”.

Quando se trata de desenvolvimento para mobile, você tem que tratar o FP ou AIR com carinho respeitando muito o GC de ambos, uma mão na roda era se você pudesse ler esse documento. Que a Adobe descreve como boas práticas para desenvolvimento móvel com FP e AIR.

Esse sem dúvidas é um grande bixo papão de desenvolvimento para mobile, aproveitar o máximo que o mobile tenha e não prejudicar o ambiente no geral que ele tenha. Afinal celular é também feito para conversar.

Plataformas
Ou grande bixo papão para desenvolvimento Mobile é os sistemas operacionais, cada empresa tem seu próprio sistema operacional ou usam um sistema operacional de código aberto e acaba protegendo desenvolvedores que usam sua própria linguage de programação e se fechando em copas para outras plataformas mais interativas que agrege valor ao conteúdo final.
Exemplo disso é o Symbian, BlackBerry, iPhone OSX. Acabam atrasando o desenvolvimento de novas funções e limitando certos tipos de funcionabilidades para a plataforma FP.

Como é de costume, quem não se abrir acaba sendo engolido pela evolução madura do mercado. Foi pensando nisso que a Symbian recentemente lançou recentemente mão do código fonte do seu sistema operacional para que outros desenvolvedores ajudassem a evoluir a plataforma. Como outro caso de grande sucesso é o da Google, o Android é um OS já open-source e ovacionado por diversas empresas criadoras de dispositivos móveis, eu não falo só em HTC, falo em Sony Erickson, Nokia, LG, Xperia, Helio, Motorola. Todas essas empresas gigante do mundo dos celulares e/ou dispositivos móveis viram que era melhor usar uma plataforma open-source à que usar uma fechada.

A grande barreira do OS aos poucos é quebrada e inclusive ganha motivadores aos desenvolvedores que tem habilidades em desenvolver para aquela plataforma em específico. Não é atoa que a Apple tem o melhor programa de desenvolvimento para seus desenvolvedores para o iphone e ipod touch. Eu não tiro a razão dela em bloquear o o FP para seus smarts phones, mais ao mesmo tempo ela vem a calhar na própria evolução do mercado e faz o “usuario final pensar” Por que não posso ver um site em Flash em meu dispositivo móvel pagando o mesmo preço em outro que toca?
Usuários finais eles sim, são os gerentes e os clientes, onde dedicem qual plataforma ou dispositivo móvel vão usar.

Sem dúvida a Adobe e Apple estão trabalhando em conjunto para trazer o FP ao iPhone/iPod e iPad de forma sustentável para ambas as companhias. Segundo últimos comentários do Tinic Uro um dos grandes engenheiros do FP, o FP para MAC agora é basicamente uma aplicativo 100% escrito em Cocoa/Objective-C. O que prova que a maturidade do FP se adaptar em qualquer plataforma chega a um nincho que é mera medida de tempo.

Já que o grande problema em não ter o FP no iPhone foi erro disproporcional e acabou levando uma coisa a outra. Toda essa “guerrinha” é pura encenação e acredito que logo logo isso será resolvido da melhor maneira possível, agradando não só ao desenvolvedor de ambas as empresas quanto aos usuários finais que poderão ver o conteúdo feito em FP.

Interop entre as plataformas

Outro grande fator que leva ao atraso de adotar o FP e o AIR aos dispositivos móveis é a diferenciação entre as plataformas. Cada uma possui comportamentos específicos e não seguem um padrão exigente como é escrito hoje na esfera WEB. Cada uma possui comportamentos singulares, por exemplo a maneira como o Acelerometro do Android possui é diferente do Acelerometro do iPhone. Os comportamentos são iguais, mais a maneira que eles fizeram cada é que é diferente.
Onde o FP precisa se adaptar e criar apenas uma única API simples que tire vantagem disso e aproveite todo esse potencial que se tem e crie uma experiência para o desenvolvedor final usando uma única API e único código para diferentes dispositivos.

O Flash CS5 é uma das grandes novas apostas da Adobe para isso, Ela demonstrou que está levando muito a sério em portar de forma elegante o AIR e o FP à dispostivos móveis. Como foi visto do Mobile World Congress, no blog do Ted você consegue ver que já é possível rodar AIR e FP no Android tanto no navegador quanto como aplicativos nativos.

Esse mesmo AIR 2.0 Beta 2 você já pode começar a experimentar essa fluidez, porém para testar de fato no dispositivo você vai ter que aguardar um pouco mais de tempo até eles lançarem todas essas novidades no MAX 2010.

Ferramentas de cross-compile:

Existe hoje ferarmentas no mercado que já faz o seu código em AIR / Flex virar uma aplicação nativa, como é o caso da empresa Open Plug, que resolveu sair na frente e lançar uma IDE junto ao Eclipse e que use o mesmo SDK do Flex com algumas modificações para fazer a cross-complicação do seu código feito em AS3/MXML para código nativo da máquina.

O bixo papão disso, é o resultado final. Você passa a não ter controle do que está indo dentro dos binários distribuidos e pode vir a ter sérios problemas de portabilidade e maturidade no futuro. Por exemplo. eu nao arriscaria fazer um produto que fizesse cross-compile no atual momento até chegar Outubro desse ano. Já que muitas definições serão tomadas nesse tempo e muitas mudanças cheguem a ocorrer.
Ok, você pode pensar que tais mudanças não afetariam o código escrito em AS3/MXML, olha não teria certeza quanto a isso, já que a cada mudança sempre sofre com nomeclatura de API, mudanças de nome de métodos, sintaxe, eventos. É coisa a se pensar. Pode começar a explorar, ver como é feito o processo. Porém comercialmente ainda não é o momento ideal. Principalmente quando se está forjando uma plataforma para dispositivos móveis.
A aposta do Open Plug com o Elipse é sem dúvida inovadora, você poder escrever em MXML e traduzir isso para plataformas Mobile como Nokia S60 3 e 5th geração é ótimo. Sem eu me preocupar nenhum pingo com C++. É fantástico ele fazer todo o trabalho sujo que teria que fazer. Porém até mesmo a própria Open Plug depende dessas decições do mercado.

Uma outra empresa que está apostando muito nessa Interop é a Appcelerator, não só voltada para o Flash e AIR, mais na Web como um todo, você faz a tradução da sua Aplicação WEB seja ela feita em JS/HTML ou Flash/Flex, ela consegue gerar instaladores nativos na plataforma alvo. Embora ela tenha a mesma fraqueza do Open plug em esperar a maturidade do mercado.

Esse é o grande Bixo papão de ambas, esperar um pouco mais para ver o que será definido daqui para frente, não tão longe assim, eu arriscaria uma solidez nesse sentido daqui uns 4 meses.

Flex Slider Framework, esse ainda vai demorar a sair, e acredito eu que vai surpreender a muita gente que desenvolve em Flex hoje atualmente, não só no Flex, mais ao todo como no geral.

Conclusão

Com tanta dificuldade de se gerar conteúdo para diferentes plataformas, diferentes telas, diferentes propriedades, eu tiro o Chapéu para o time do FP e AIR, não é fácil organizar todas essas diferenças em uma API interop que funciona da mesma forma que funciona em A ou em B.

Flash Player/ Flex

Flash Player 10.1 Ahha, Uhhu!!!

Antes, pedido de desculpas públicas por ter sumido permanentemente do blog. Aquela velha história para boi dormir, “falta de tempo”.

Fora isso, vamos ao que nos interessa. Temos novidades nessa MAX 2009. Infelizmente aquele velho cadeado chamado NDA não deixa agente falar muito. Mais graças ao tempo, senhor das respostas eis que surgem diversas novidades para o Flash Player.

Entre elas:

Dentre todas as novidades, aos quais são ótimas. As que mais gostei foi a respeito da performance e do global Error Handling. Como temos esperado isso há longos cinco anos.

Esse tipo de informação você pode acessar pelos dois links abaixos:

1 – http://www.adobe.com/devnet/logged_in/jchurch_flashplayer10.1.html
2 – http://labs.adobe.com/technologies/flashplayer10/

Flash Player/ Notícias

Flash Player 10 64bits disponível para Linux

Quem usa o Flex Builder Alpha e usa o Linux como principal plataforma de desenvolvimento e com 64bits , sente a falta de usar o Flash Player para versão de 64bits, demorou quase um ano para lançarem uma versão para o Linux. Embora agora toda nova versão vem para Windows, Mac e Linux.

Ainda não tem uma versão Flash Player 10 debugger de 64bits para linux, tem só 32bits, mais já é uma mão na roda para quem precisa.

O Flash Player 10 64bits já está disponível para download, veja aqui.

Outras versões standard ou debugger para o Flash Player 10 podem ser vistas aqui.