Adobe AIR 101/ AIR 1.0/ AIR 1.1/ AIR 2.0/ AIR 2.7/ AIR 3.0/ AIR Mobile/ Flash Player

Adobe AIR perde o foco para criar Apps para dispositivos móveis

air_2_lg.jpg.adimg.mw.138

A Adobe hoje atualizou o Flash Player e Adobe AIR Whitepapers, que é um documento público mostrando as intenções da empresa desde sua mudança de foco nos últimos 2 anos.

Hoje ela acredita que suas plataformas Flash Player/ Adobe AIR continuaram fortes na arquitetura atual e abandorá todos os esforços na criação da próxima versão do Actionscript Next e Flash Player Next, que possivelmente seriam o Actionscript 4.0 e o Flash Player 12.

Ela voltará seu foco em novas VM como o V8 por exemplo do Google Chrome ou o Webkit amplamente utilizado por vários fabricantes de navegadores.
Com essas novas atualizações dos documentos, houve Buzz e ainda vai ter, veja alguns destaques de pessoas importantes dentro da empresa, e suas visões em relação à plataforma.

Já que a regra vale a máxima, Uma imagem vale mais do que mil palavras, quanto mais uma declaração como essa.

adobe_airmobile

 

Sim, nós não estamos promovendo o AIR para criação de apps para smartphones. Eu concordo que o AIR é ótimo com o Starling e o Feathers, já que você tem uma velocidade quase nativa.

 

Essa foi uma das declarações feita por alguns dos evangelistas da Adobe, em especial o Lee no Google Plus e está disponível para quem quiser ler, que hoje lidera a parte de evangelismo para Jogos.

Não é polêmica a declaração, só reafirma que o compromisso da Adobe não é só manter o foco na plataforma Flash/AIR em sí, mas dar ênfase à outra parcela de desenvolvedores que adotam o padrão aberto.

Na mesma discussão Mike Chambers reforça que o foco da Adobe para plataforma Flash é Jogos.

adobe_airmobile2

 

 

Não é que você precisa ficar desesperado por que o suporte ao Adobe AIR vai sumir do mapa e você não vai mais conseguir criar Apps usando o Adobe AIR, só para você saber quando e como usar o AIR em suas Apps, mesmo usando ele embedado na sua App.
Essa ficará para história de como destruir um eco-sistema enorme de desenvolvedores para concorrentes.

AIR 2.0/ Dicas/ Flash/ Flash Player

Flash é uma pequena parte de nossa empresa,afirma Shantanu Narayen, CEO da Adobe

Seria esse um recado para os próximos 5 anos que o Flash Player e todo o ecosistema da plataforma Flash irá signitivamente diminuir no cenário mundial e nos investimentos da Adobe para a plataforma, e acabar adotando o HTML5 como padrão?

Assista o video do Shantanu Narayen,CEO da Adobe para o D9.

O entrevistador foi honesto e duro com as perguntas, mesmo assim treinado como o Shantanu Narayen é, consegiu escapar e deixar mais complicado para desenvolvedores e usuários finais qual seria o formato para daqui à 5 ou 10 anos.

AIR 2.0/ Dicas/ Dicas e truques/ Flex/ Flex Builder 4/ Livros/ RIA

Livro Flex 4 Avançado

A editora Novatec, recentemente lançou o livro Flex 4 Avançado, que conta com um excelente conteúdo programático e uma ótima tradução.

Se você quer aprender mais a fundo o Adobe Flex 4 e Adobe AIR, você deve comprar esse livro, nós indicamos por que avaliarmos o livro técnicamente, e ele passou pela nossa análise.

Analisamos pontos de referencia, técnicas e macetes já dados no livro em Inglês e querendo ou não acabam se perdendo com traduções mal feitas. Esse livro me surpreendeu por que sua tradução está muito bem feita, e preservou também esses macetes que salvam em horas turbulentas.

O melhor disso tudo é que não só avaliamos o livro como também conseguimos um desconto para todos os leitores desse blog e também a comunidade Flex Brasileira.

Valendo até 31/12/2011 quando você comprar esse livro ou qualquer outro livro no site da Novatec, você ganha 20% de desconto inserindo o código promocional FLEXBRA

Estamos sorteando 1 cópia desse livro Flex 4 Avançado, veja meu Tweet. E também siga também a @novateceditora no Twitter, eles fazem diariamente outras promoções.

AIR 2.0/ AIR Mobile/ Flex

Adobe AIR Launchpad, ferramenta útil para todo desenvolvedor AIR

Não tem idéia alguma de como criar uma aplicação Flex usando o AIR? Acredite segundo Homer Simpson, 1 em cada 3 desenvolvedores Flex, nunca, mais nunca usou ou criou um aplicativo AIR em sua vida.

Dessa teroria, tiramos duas conclusões, ou o marmanjo não manja muito, ou tem preguiça de configurar um aplicativo AIR do zero.

A primeira opção não tem solução rápida, você vai ter que melhorar e/ou vender água de coco na praia. A segunda temos o então útil Adobe AIR Launchpad.

O que é o Launchpad? É um aplicativo utilitário que vai configurar para você todas as opções possíveis que uma aplicação feita para o AIR possa ser criada, ele te ajuda a definir tudo que o Application descriptor do AIR possa suportar. Em suma geral, é um gerador de projeto.

O atual versão beta, além de te ajudar a criar essa estrutura, ele gera um arquivo de projeto para o Flash Builder, onde você pode facilmente importar.

Vamos a um passo-a-passo?

Supondo que você tenha já o Adobe AIR run-time instalado em sua máquina (versão 2.5) ok?

Primeira coisa que você deve fazer é baixar o AIR Launchpad do Labs da Adobe. Clique aqui e baixe.
airlaunchpad

A primeira tela que você vai ter do launchpad é essa ai que você está vendo. Você escolhe criar projetos para Mobile ou Desktop. Eu escolhi Desktop. Então a próxima tela é essa.
airlaunchpad2

Veja que eu coloquei algumas configurações ao meu projeto, por exemplo tamanho de 700×500, usar o recurso de auto-update e de resize.

Clique em Next e você vai direto para a aba de configuration. Nela você define outros comportamentos mais “avançados” para seu projeto AIR. Nessa parte ele não influencia no Application description, ele vai além disso criar algum código fonte já pronto para você. Olha que massa!

Eu escolhi as seguintes opções.

airlaunchpad3

Clique em Next e vamos adicionar mais alguns exemplos, na aba de “Samples”. Tem 10 opções que você pode adicionar ao seu gerador de projeto.

airlaunchpad4

Adicionei apenas 2 opções, Drag-N-Drop e usando o HTML Component, como é demonstração eu não preciso ir além disso.

A última parte do Launchpad é gerar a estrutura do projeto em sí, não só isso como também um arquivo de projeto para o Flash Builder. Um dos recursos extras como você ver na imagem abaixo é a possibilidade de gerar um Badge para meu projeto. Muitos esquecem de fazer isso, e simplesmente passa apenas o arquivo .air para amigos ou empresa instalar, o Badge é bom que fideliza e dá uma aparência profissional para seu projeto.

O Launchpad faz isso ridiculamente simples, tudo que você precisa é de uma imagem (215×100)pixels, seja ela PNG, JPEG, você basta arrastar na área demarcada por ele. Selecione depois o local onde você quer salvar seu projeto e clique no botão vermelho “Generate AIR Project”.

airlaunchpad6

Se você fez tudo certinho, então você vai ver essa tela acima, além do programa abrir o diretório contendo o projeto que você acabou de criar, com 1 diretório para o projeto e 1 projeto em .zip para você importar para o Flash Builder.

airlaunchpad7

Ok, eu particularmente deletei meu arquivo .zip e fiquei só com o diretório. Agora meu próximo passo é importar esse projeto para o meu workspace do Flash Builder e apertar o gatilho do “Run”.

Para isso, basta eu ir em File > Import > General > Existing Project into Workspace > Next.

E logo em seguida essa tela abaixo aparece, onde eu marquei a opção de selecionar o diretório onde estava o projeto gerado e lembrei de marcar a opção “Copy into workspace”. Assim eu consigo deletar da minha área de trabalho e não deixar ela poluída, guardando o projeto no local certo.

airlaunchpad8

E o projeto vai aparecer como uma luva em meu Flash Builder. Com os códigos gerados e tudo mais, fácil aprender AIR assim não é?

airlaunchpad9

Dica importante para quem usa o Flex SDK 4.5, Vai dar erro no Application Descriptor, já que o AIR Launchpad foi feito para 4.1 e não para o 4.5. Solução? Basta abrir o Application descriptor e mudar o namespace de 2.0 para 2.5 e Voilá!


  MeuProjeto

Até a próxima!

AIR 2.0/ Cursos/ Flex 4

Ganhador dos cursos de Flex 4 Essencial e AIR 2.0 Essencial

Foi mais divertido que dificil. Dos 20 participantes do pequeno concurso que fizemos no post anterior rendeu muito assunto para jornal.

O pessoal solta a criatividade geral para ganhar as bolsas do Flex 4 Essencial e AIR 2.0 Essencial.

A parte dificil é escolher a melhor, e para isso chamei o pessoal do escritório para me ajudar. E a que foi mais votada aqui foi essa.

Já disseram que o homem não poderia voar, hoje temos o avião. Anos atrás a infecção era sinal de morte, até por acaso descobrirem a penicilina. Um dia pensaram que a internet não daria certo, hoje o mundo não consegue viver sem ela. Com a internet surgiu uma questão: “Precisamos ter interfaces mais dinâmicas, flexíveis e bonitas”! Nasce então o Flex. Eu quero participar da história da humanidade. Eu quero aprender Flex com vocês!

Essa justificativa foi bem interessante, e escrita pelo Raphael Vinícius do Rio de Janeiro. Ele trabalha ou é dono do site www.b2all.com.br .Parabéns Raphael, você realmente estava inspirado.

Para quem não ganhou, e mesmo assim quer fazer só que as coisas estão apertadas por ai. Fala comigo, pelo igorcosta AT gmail.com que eu dou um jeito de te ajudar como sempre fazemos.

AIR 2.0/ Flex/ Flex 4/ Flex Builder 4

Concorra a uma bolsa de estudos para o curso on-line Flex 4 Essencial

Vamos vender um pouco de jabá aqui.

Vocês sabem que temos cursos on-line dos mais variados tipos para e exclusivamente para a plataforma Flash. Não somos tão bons em propaganda, acreditamos que o boca-a-boca gera rendimento, tanto que estamos com quase 1mil alunos já capacitados em 6 meses de operações. (Vlw pessoal).

No próximo sábado dia 25/09 vai ter mais uma turma, e como é de costume, sempre que tem novas turmas, sorteamos 1 até 4 vagas pelo nosso twitter ou no twitter da RIACycle.

Porém, eu sei que nem todo mundo tem twitter ou gosta da onda, então quero sortear uma vaga para esse curso de sábado, aos nossos leitores que vem acompanhando a série de posts sobre o Flex 4 que temos feito por aqui.

Como participar?
É bem e muito simples, Escreva um comentário dizendo por que quer aprender Flex conosco.
Preencha seu nome, e-mail e telefone logo após o porque. Não iremos publicar seu telefone, pode ficar tranquilo.

Regras
O comentário que for mais inteligente, ganha uma bolsa não só para o curso de Flex 4 Essencial como também para o de AIR 2.0 Essencial.

Quantidade?
1 vaga.
Indique aos seus amigos, colegas de trampo.

AIR 2.0/ Flash Builder/ Flex/ Flex 4/ Notícias/ Open-source

Lançados o Flex 4.1 e Flash Builder 4.0.1 update

Para quem estava com problemas no Flex SDK 4.0, a Flex Team lançou ontem uma atualização para corrigir essas falhas, que não foram poucas.
Apenas duas novidades nesse lançamento que é o suporte a Mirroring Layout e suporte nativo ao Flash Player 10.1 e AIR 2.0.

Faça o update do seu Flash Builder 4.0.1 aqui.

Faça o download do novo SDK 4.1 aqui.

O próximo lançamento do Flex SDK,será o codename Hero SDK, saiba mais aqui.

AIR 2.0/ Flash Lite/ Flash Player/ Flex/ Flex 4/ Flex Mobile Framework

Flex Hero SDK

A Adobe anunciou ontem que abandonou o projeto Slider Framework, aquele framework em que ela estava trabalhando para criar aplicativos Flex para dispositivos móveis. Porém, não fique chateado, os motivos que ela levou a abandonar o projeto Slider Framework, foram significativos e decisivos, eu realmente acredito que tais movimentos foram necessários, devido:

Aumento de capacidade dos smartphones – Hoje tem celulares com mínimo de 400Mhz de processamento, o Flash Player 10.1 consegue ser executado normalmente em até uma arquitetura de 233Mhz sem problemas. Então temos celulares com maior processamento fazendo com que o Flash Player seja executado mais rápido sem a necessidade de termos players diferenciados como existe hoje. Flash Player para Celulares o famoso Flash Lite. Então isso pode deixar de existir, forçando os fabricantes de smartphones a adotar já o Flash Player 10.1 em seus dispositivos. Acreditamos que até o final do ano teremos ai cerca de 10 novos modelos de smartphones no mercado.

Arquitetura Spark – O Slider Framework seria um framework a parte para desenvolvimento de aplicações ricas para dispositivos móveis, costumamos chamar de RIMA (Rich Interactive Mobile Application); Porém como temos uma arquitetura mais leve, mais robusta, suportando o re-desenho de telas cada vez mais rápido, não custava nada a Adobe trabalhar em um único SDK que desse suporte não só para Desktop, como também para dispositivos móveis.
Foi ai que ela re-pensou sobre o conceito levando em consideração o aumento de performance, e assim lançou o Hero SDK. O novo futuro do Flex SDK.

Levando todos esses fatores em consideração e a rápida adoção do Flash Player 10.1 em dispositivos móveis (smartphones) com maior capacidade, quem é da área de desktop só tem a ganhar, já que a unificação de um só SDK, você terá a chance de aproveitar 100% do conhecimento que você já tem em Flex para criar RIMA.

Devido a constante mudança, acredito eu que tanto o Flash Player 10.1 quanto o AIR 2.0, sofrerá ainda esse ano a Adobe decidiu não compartilhar ainda o SDK para download, ainda está em especificação e você pode acompanhar no site oficial do Hero SDK, já tem alguams especificações já prontas como o ActionBar, que a principio precisa de mais alguns elementos como o autoHide que ainda não foi criado.

Leia mais informações:
Flex Mobile Application FAQ
Site Oficial do Hero SDK
Flex e Mobile Whitepaper

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.