22 de fevereiro de 2011

Ferramenta da Adobe permite criar aplicações Flash para IPhone

Semana passada eu finalmente me animei a procurar o SDK do iOS para baixá-lo e fazer testes básicos de criação de aplicações para o iPhone e o iPad, só pra ver como é que funciona. Para minha surpresa, descobri pela documentação que a Apple só tem versão do SDK para Mac OS ! Simplesmente não há opção de desenvolvimento em Windows - apenas gambiarras ... Levando em conta que o Windows está presente em mais de 80% dos desktops, é no mínimo estranha a opção da Apple pela exclusividade da versão para Mac.

Por incrível que pareça, a solução para esse impasse pode ser desenvolver em Flash. Apesar da resistência da Apple em implementar na versão mobile de seu navegador Safari o recurso para executar animações Flash, há boas notícias neste campo. É que a Adobe lançou em outubro do ano passado uma release de suas ferramentas focando no desenvolvimento para dispositivos móveis e incluiu no pacote um programa capaz de compilar o código por trás das aplicações Flash - o ActionScript - diretamente como um programa nativo para iOS, sistema operacional de iPads, iPhones e iPods Touch.

O texto abaixo, que é uma tradução de matéria publicada no site Infoworld.com, lança algumas luzes sobre esse assunto. A matéria original em inglês pode ser acessada aqui.

Há algum tempo, o caminho para a Apple App Store era muito simples para desenvolvedores Adobe Flash: abandonar a facilidade dos métodos que eles estavam acostumados e se devotar à pura complexidade do Objective-C. As vistosas ferramentas e bibliotecas de renderização dessa linguagem são boas para os iniciantes mas apenas especialistas em ponteiros e malloc são bem-vindos ao banquete à mesa do iOS. A porta era fechada nos dedos dos demais.

A razão era simples: a Apple se recusava a aceitar programas que usassem bibliotecas ou interpretadores e, tal qual as antigas professoras, insistia que cada um escrevesse seu próprio código. Talvez a Apple temesse vírus, códigos baixados pela internet ou a competição de ferramentas multiplataformas.

Isso foi antes. Agora, a Apple cedeu um pouco e não está mais completamente fechada ao uso de plataformas runtime como o Flash para desenvolvimento de aplicações para iPhone e iPad. São boas novas para aqueles que se especializaram num conjunto de ferramentas que continua a produzir alguns dos conteúdos mais vistosos da Web.

"Basicamente, a renderização da Adobe está há anos sendo construída e eles aperfeiçoaram esta tecnologia", diz Paulius Uza, CEO da InRuntime, criadora do jogo Alchemist. A empresa dele frequentemente prototipa ideias com outras tecnologias, como o OpenGL, mas ele sustenta que "uma versão em Flash sempre parece mais bonita."

Agora, desenvolvedores Flash como Uza têm outros caminhos para o iPhone e o iPad, através da Adobe e de um outro bom competidor, criado por gente que já trabalhou para a Adobe. Ambos abrem oportunidades para que aqueles que já trabalham com o ecossistema Flash possam usar seus talentos e códigos para criar novas aplicações.

A ferramenta Packager for iPhone pega um código em ActionScript 3 e o compila para que execute em dispositivos com iOS 3.0 ou mais recente. O resultado é código nativo e não um código binário Flash interpretado; para a Apple, este passo de empacotamento garante que você não estará entregando novos binários ao dispositivo através da internet e sobrepujando os mecanismos que resguardam a Apple App Store.

O Packager for iPhone é melhor para desenvolvedores que dominam a criação de websites em Flash. Uza disse que seu grupo gosta dessa opção porque ela oferece mais controle para quem prefere pensar em linhas de código, como programadores. "Estamos escrevendo código com o Flash Builder, que é voltado a desenvolvedores somente. Ele não possui qualquer ferramenta relativa ao desenvolvimento do visual de aplicações", nota ele.

Criadores mais casuais, como designers gráficos, ficam mais confortáveis em uma aplicação integrada e podem usar o Flash Professional CS5, o qual agora possui o Packager for iPhone nativo. Ao invés de salvar o projeto para a web, você seleciona a opção que converte o projeto em uma aplicação pronta para ir para o App Store. Ainda é exigido que o desenvolvedor tenha um certificado da Apple, obtido quando você se cadastra no programa deles para desenvolvedores de aplicações. No entanto, a ferramenta da Adobe faz todo o resto.

O outro caminho é o Corona SDK, criado pela Ansca Mobile, companhia fundada por pessoas que trabalharam na equipe do Flash. Embora esse SDK use Lua ao invés do ActionScript como linguagem, a estrutura das aplicações e a API são muito similares ao Flash. O CEO Walter Luh diz "Muita gente achará que esse é um produto extremamente fácil de ser compreendido."

Ambas as ferramentas também prometem oportunidades multiplataformas. A Google deu boas vindas aos desenvolvedores do Flash para Android, assim como a Hewlett-Packard o fez em relação ao WebOS 2.1, que ainda será lançado. A Adobe também planeja assegurar que códigos Flash executem no BlackBerry Tablet OS, sistema do novo tablet da RIM, o PlayBook. O Corona suporta iOS e Android mas poderá acrescentar outras plataformas se surgir demanda.

Estas ferramentas são tentadoras para qualquer desenvolvedor Flash com uma pilha de código que já roda na web.

"Em alguns casos, você terá simplesmente que fazer o porte", diz Richard Galvan, gerente de produtos Flash na Adobe Systems. "Adapte o projeto para uma tela menor e então poderá liberá-lo muito rapidamente para o iOS. Você pode literalmente pegar o mesmo projeto e, num passo seguinte, publicar a aplicação também para Android."

Ele adverte, porém, que embora o Adobe packager faça tudo funcionar corretamente, podem ocorrer problemas com a interface gráfica da aplicação portada. Por exemplo, smartphones têm tela pequena e frequentemente vêm sem teclado, o que não costuma ser preocupação no desenvolvimente de aplicações desktop. Na mesma linha, os eventos touch se comportam ligeiramente diferente dos cliques com o mouse. Assim, muitas aplicações desktop em Flash vão requerer alguma reavaliação na forma como um usuário interage com elas.

Há também uma quantidade considerável de retrabalho a se fazer com os gráficos. Embora todas a parte gráfica seja exibida quando portada sem modificações, a escala das imagens é com frequência inadequada para dispositivos menores. Assim, o que se vê fácilmente na tela de um PC, geralmente fica muito pequeno num iPhone. O maior desafio aparece porque há muito menos espaço numa tela pequena.

Desafios maiores surgem em relação ao estilo de arte. Algumas apresentações em Flash se baseiam em arte vetorial, que permite exibir o mesmo visual em escalas diferentes. Embora isto funcione no iPhone, a renderização de gráficos vetoriais neste aparelho é notadamente menos veloz que um mapa de bits, pois este é processado pelo hardware gráfico do smartphone. Ajustando a propriedade cacheAsBitmap pode acelerar a renderização dos gráficos vetoriais - isto é especialmente importante se a imagem de fundo é vetorial porque todo a imagem é redesenhada, mesmo que apenas algum elemento do primeiro plano tenha sido modificado.

Tom Barclay, gerente de projeto na Adobe, diz que a empresa está procurando maior automatização no processo de conversão de forma que o packager instantaneamente trate a imagem vetorial corretamente, de acordo com o tamanho da tela a que se destina. Os desenvolvedores já sabem que tirar vantagem da resolução extra do novo visor Retina do iPhone requer um conjunto diferente de imagens, redesenhadas em resoluções mais altas. Idealmente, a ferramenta converteria as imagens vetoriais e as prepararia como mapas de bits, tirando vantagem de resoluções ainda mais altas no futuro.

O desafio de mudar para Corona da Ansca é um pouco diferente para programadores Flash porque a linguagem, Lua, não é idêntica ao ActionScript. As diferenças são cosméticas e há relatos de que é preciso apenas retrabalhar o código, junto com passos simples como substituir o "abre chave" por palavras como "do".

Luh, da Ansca, diz que portar o código é geralmente simples porque as estruturas de dados são relativamente similares e descomplicadas. Por exemplo, Lua oferece apenas um tipo de tabela - uma coleção de pares nome-valor não tipados.

Jonathan Beebe, um desenvolvedor que criou jogos como Cavern Drake com sua esposa e os publica sob o nome de Beebe Games, diz que foi atraído pelo Corona porque Lua é muito menos intimidadora que os ponteiros que dominam a sintaxe do C. "A primeira vez que cruzei com ela, eu estava prestes a aprender Objective-C," ele recorda. Ele notou que Lua é muito similar ao PHP, que ele já tinha usado antes. "É muito fácil a transição do PHP para Lua."

Fora a conversão de código ActionScript para Lua, desenvolvedores Corona têm o mesmo desafio de fazer caber uma aplicação desktop dentro da tela pequena dos smartphones - com frequência, um desafio maior do que portar a lógica da aplicação. "O engraçado é que por causa da alta definição do iPhone, desenvolvedores gastam mais tempo atualizando os gráficos e trazendo-os para a qualidade do iOS," nota Luh.

Uma das maiores diferenças entre desenvolver em Flash e em Corona são as bibliotecas. A plataforma Flash está bem estabelecida e há centenas de bibliotecas, tanto comerciais quanto open source, disponíveis aos programadores que queiram usá-las.

O Corona, por outro lado, vem com diversos recursos que desenvolvedores Flash usando as ferramentas da Adobe só obtêm através do uso de bibliotecas externas, o que torna as versões em Corona mais simples. Um exemplo do Corona é chamado "Física em 5 Linhas," um projeto simples que ilustra como objetos podem ser criados e postos em movimento apenas configurando umas poucas propriedades. Você pode usar essa técnica pra construir jogos básicos que empregam física simples na criação de um mundo, e então ver esses objetos se desintegram ao se chocarem. Luh disse que viu desenvolvedores clonarem o Angry Birds em cerca de um dia de trabalho.

Beebe disse que gostou de trabalhar como o engine físico porque ele simplificou muito do trabalho árduo envolvido na criação de jogos arcade que acuradamente simulem o comportamento de objetos bi-dimensionais na Terra. "É realmente bom," diz. Ele também nota que o engine é baseado na biblioteca open source Box2d que oferece um modo de física contínuo para simular como objetos reagem quando batem uns nos outros, afetando a direção em que eles se moviam.

O Corona SDK também oferece acesso a várias bibliotecas para mergulhar nas entranhas do smartphone, incluindo conexão com a câmera, alto falantes, GPS e o acelerômetro. Uma das mais surpreendentes é a biblioteca nativa para postar atualizações no Facebook.

Beebe estava particularmente agradecido pela mais nova biblioteca, que facilita a implementação de compras a partir da aplicação. "Eu tenho lido histórias tenebrosas sobre esta implementação em aplicações," diz. "No Corona, o mais complicado é lidar com o iTunes Connect, mas isso todos tem que fazer, independentemente do SDK usado."

Um dos maiores atrativos das ferramentas da Adobe e da Ansca é a oportunidade de escrever o mesmo código para múltiplas plataformas. Mas a realidade não é nem perto de ser tão atrativa quanto a promessa.

Mark Sigal, co-founder da Unicorn Labs, um desenvolvedor de aplicações móveis, diz que apesar dos desenvolvedores poderem simplesmente escolher a opção "Salvar Como" do menu, eles dificilmente ficam satisfeitos com o resultado. "É como todo o resto: haverá aqueles 10 ou 15 porcento do tempo que você gastará refinando a aplicação para seu dispositivo alvo," explica.

Sigal disse que a proliferação de dispositivos Android é um desafio especialmente oneroso porque há muitos tamanhos e versões diferentes com ligeiras diferenças de configuração de hardware. Mas usando uma plataforma de desenvolvimento neutra como Flash ou Corona mantém essa variabilidade gerenciável, ele diz: "Efetivamente estamos suportando 22 alvos diferentes." Graças à ferramenta, "não é um trabalho complicado."

Não cheguei a testar nenhuma dessas duas ferramentas mas qualquer uma delas pareceu melhor opção do que desenvolver usando diretamente o SDK do iOS. Primeiro, porque eu não teria que abandonar meu ambiente de desenvolvimento em Windows, onde, bem ou mal, eu me sinto em casa. Depois, como a própria matéria aponta, as ferramentas abrem a oportunidade de se construir aplicações para múltiplas platataformas praticamente com o mesmo código e sem muitos traumas.

Um comentário :

José Ricardo disse...

Olá Luiz eu até entendo o por que de ser exclusivo para mac, o XCode que é a ferramenta utilizada pela apple para desenvolver para iOS tbem é usada para desenvolver no Mac usando o Cocoa, então faz sentido, e com certeza tem as questões técnicas tbem tipo o itunes do windows é bem mais lento e tem bugs em relação ao do mac, então nao tem como gastar um esforço tremendo para desenvolver novamente a roda e fazer uma aplicação desse porte pra windows.
Parabéns pelo blog é show de bola, estou indicando para todos os meus amigos.

Postar um comentário

OBS: Os comentários enviados a este Blog são submetidos a moderação. Por isso, eles serão publicados somente após aprovação.

Observação: somente um membro deste blog pode postar um comentário.