13 de setembro de 2011

Por que Titanium?

Titanium mobile

Parece que a moda nos últimos anos tem sido criar ferramentas de desenvolvimento mobile multiplataforma. Se, por um lado, isso indica que esse tipo de ferramenta tem tido crescente demanda por parte dos desenvolvedores, por outro, torna cada vez mais difícil a tarefa de escolher qual delas atende melhor nossas necessidades.

Meu objetivo principal nesse artigo é diferenciar o Titanium de um grupo bastante popular de ferramentas com as quais ele é frequentemente confundido e deixar claro quais são as vantagens e desvantagens advindas dessa diferença.

O problema com o termo “nativo”

Quase todos os fornecedores de ferramentas de desenvolvimento mobile multiplataforma alegam que suas ferramentas geram apps nativas. Bem, eles aparentemente consideram o termo "nativo" aplicável a toda e qualquer app que é empacotada de forma que possa ser publicada nas lojas de apps nativas. Mas, ao passo que o termo "nativo" serve para excluir as web apps, ele não ajuda a diferenciar (1) as apps que fazem uso da API nativa para criar os elementos de interface (2) daquelas que apenas simulam a aparência e o comportamento nativo.

As apps criadas exclusivamente para uma plataforma, usando as ferramentas endossadas pelos seus fornecedores, se encaixam no primeiro caso. E as apps criadas com o Titanium Mobile também. Mas a grande maioria das demais soluções se encaixa no segundo caso. Elas fazem uso do famoso WebKit e dos recursos do HTML5.

Mobile apps só um pouco nativas

O WebKit - uma engine de browser que é o coração do Safari e do Chrome e que começou a ficar popular no mundo mobile a partir do iPhone - possibilitou que os browsers de dispositivos móveis se tornassem muito mais robustos. Isso abriu as portas para diversas empresas criarem ferramentas de desenvolvimento mobile multiplataforma baseadas em modernas tecnologias web como o HTML5 e CSS3. Entre as mais populares que usam essa abordagem estão PhoneGap e Rhodes.

As apps criadas com essa abordagem são empacotadas nos moldes de uma app nativa. Mas a parte delas que roda código nativo (gerado automaticamente) se limita a (1) uma camada que faz a ponte (em tempo de execução) entre a API nativa da plataforma para a qual foi compilada e a API da ferramenta e (2) uma WebView (android.webkit.WebView no Android e UIWebView no iOS) que usa o WebKit para renderizar a interface da aplicação, codificada em HTML/CSS e JavaScript.

A experiência de criar mobile apps com essas ferramentas é bem próxima da experiência de criar web apps, mas com as vantagens de ter acesso a boa parte dos recursos nativos, além da possibilidade de publicar essas apps nas lojas tradicionais. O suporte a um grande número de plataformas (PhoneGap suporta 6 e Rhodes 7) é um outro ponto positivo. O lado não tão bom é que as apps são, na realidade, uma espécie de browser para "web apps offline". Os elementos de interface, bem como os efeitos visuais são, no melhor dos casos, imitações do equivalente nativo. A performance, entretanto, fica bem longe da performance nativa.

Mobile apps realmente nativas

A abordagem do Titanium Mobile é completamente diferente da mencionada acima. A interface de usuário não é codificada em HTML/CSS e renderizada numa WebView, ao contrário do que algumas pessoas desinformadas dizem ou até ao que o site da Appcelerator talvez dê a entender em alguns lugares. As apps são codificadas em JavaScript, usando a API do Titanium, que nos permite criar elementos de interface nativos para cada plataforma. Veja um exemplo:

Na hora do build, o código JavaScript é otimizado e, a partir dele, é gerado código nativo (ObjC/Java) para realizar cada uma das chamadas correspondentes à API da plataforma subjacente. O código JavaScript continua existindo, embutido no código nativo da app; um interpretador JavaScript é responsável por executá-lo, o que torna possível o pleno uso dos recursos de script da linguagem. O código nativo, por fim, é compilado pelas ferramentas de cada plataforma e resulta numa app verdadeiramente nativa. Quando a app está em execução, cada janela roda numa window nativa ao invés de numa janela de browser, portanto não há DOM na história.

Qual a vantagem de uma app verdadeiramente nativa? O seguinte comentário (traduzido livremente) ajuda a responder:

'Queremos proporcionar aos usuários a experiência nativa, no iPhone, iPad e dispositivos Android. Nossa aplicação nesses dispositivos deve se comportar assim como os usuários esperam que elas se comportem. Os usuários querem uma experiência que se integre perfeitamente com a plataforma em que estão usando no momento. Eles querem alta performance, o que normalmente só é obtido través das bibliotecas nativas do dispositivo ou do sistema operacional.' (Karen White, CEO do Syncplicity)[1]

Simular a experiência nativa é caro nas ferramentas baseadas em HTML/CSS. Por isso vemos tantas apps com cara de iOS mesmo quando rodam em outra plataforma. Com o Titanium, esse trabalho não é necessário, visto que os elementos de interface já são nativos. Seguir as guidelines de cada plataforma com o Titanium é muito mais fácil. Quanto a performance, as apps feitas com Titanium são muito superiores àquelas que usam WebView e, ao mesmo tempo, perdem pouco para as inteiramente codificadas na linguagem padrão da sua plataforma.

Write once, adapt everywhere

Cada plataforma tem suas guidelines, seja por limitação dos dispositivos ou por escolha dos seus projetistas. No iOS, por exemplo, as abas dos Tab Groups ficam embaixo, enquanto no Android, elas ficam no topo. No iOS, cada tela secundária tem um botão "voltar" no topo à esquerda. Já no Android, essa função é suprida pelo botão do próprio dispositivo. No Android, algumas ações ficam "escondidas" no menu, exibido a partir de um botão do dispositivo. Já nos dispositivos iOS, não há botão para menu. Seguir as guidelines nem sempre é a única alternativa, mas segui-las faz grande diferença na experiência do usuário. Outro ponto é que cada plataforma possui recursos únicos. No Android, por exemplo, podemos criar serviços que rodam em background, mesmo quando a app que o iniciou já foi encerrada.

O Titanium não é uma ferramenta do tipo "write once, run everywhere" (codifique uma vez, execute em todo lugar). Ele está mais para "write once, adapt everywhere" (codifique uma vez, adapte em todo lugar), dado que sua API deixa de ser genérica em alguns pontos para dar suporte às características únicas de cada plataforma. Isso permite que proporcionemos ao usuário a melhor experiência possível em cada plataforma e ao mesmo tempo maximizemos o reuso do código entre as plataformas.

Nem tudo são flores

Esse trabalho, um tanto sofisticado, feito pelo Titanium para gerar apps realmente nativas tem seu preço. Builds completos são bem demorados, mesmo para apps simples. Além disso, é caro para a Appcelerator introduzir o suporte a uma nova plataforma. O suporte ao BlackBerry está em beta desde o ano passado. O suporte ao Android funciona bem, mas ainda tem um grande campo para melhora. Se você precisa atingir atualmente um público que vai além do iOS e Android, Titanium não é a melhor alternativa.

Um bônus

Além do Titanium Mobile, a Appcelerator possui o Titanium Desktop, que permite criar aplicativos para Windows, Mac e Linux usando tecnologias web da mesma forma que as abordagens mobile mencionadas anteriormente usam HTML/CSS*. O código de negócio pode ser escrito em JavaScript, Ruby e Python. Mas o grande bônus está em manter manter o máximo do código de negócio em JavaScript para poder compartilha-lo entre as versões mobile e desktop.

O Wunderlist, uma app de produtividade que tem versões para iPhone/iPad, Android, Windows e Mac, e que talvez seja a app de maior sucesso feita com Titanium, teve cerca de 90% do seu código compartilhado entre todas as versões, segundo seus desenvolvedores[2].

Poder criar versões desktop para a sua app aproveitando o mesmo código base e a mesma plataforma de desenvolvimento é um belo bônus, não?

Uma palavra final

Para encerrar, gostaria de usar uma citação de uma das fontes que utilizei ao preparar esse artigo:

“Não há uma única ferramenta, framework ou técnica que alcance todos os dispositivos e plataformas sem abrir mão de algumas funcionalidades ou sem a necessidade de portar alguns trechos de código. E essa é a realidade não apenas do desenvolvimento mobile, mas também da maior parte de todo desenvolvimento de software atualmente.” (Mobile Learning Environment)[3]

Espero que tenha gostado do artigo. Se tiver dúvidas, comentários ou sugestões, apreciarei seu feedback.

*** Update: Maio/2012 ***

Como comentei num artigo mais recente, o Wunderlist para Android deixou de ser feito com Titanium e o Titanium Desktop deixou de ser mantido pela Appcelerator.

* ^ Visto que esse blog é focado no Titanium Mobile, quando eu digo apenas "Titanium", estou me referindo ao Titanium Mobile e não ao Desktop. Dependendo do contexto, posso também estar me referindo também à inteira plataforma Titanium, que inclui o Titanium Mobile e o Desktop, mas nesse caso você perceberá a diferença.

Referências:

[1] ^ RWW. "Syncplicity Makes the Case for Native Apps, Not HTML5"

[2] ^ Appcelerator. "Wunderlist, iPhone’s #1 Cloud Connected Productivity App, Crosses One Million Unique Downloads, And Expands Footprint To Android Platform"

[3] ^ Mobile Learning Environment. “Technology report: Cross platform mobile development”

Application Markup Language. "Comparison: App Inventor, DroidDraw, Rhomobile, PhoneGap, Appcelerator, WebView, and AML"

Appcelerator Wiki. "The Titanium Architecture""

Appcelerator Blog. "Titanium Mobile for web developers"

Appcelerator Blog. "The Apple Rejection Economy and Therapy""

Stack Overflow. "How Does Appcelerator Titanium Mobile Work?"

PhoneGap. http://www.phonegap.com

RhoMobile. http://rhomobile.com/products/rhodes

17 comentários:

Jônatan Fróes disse...

Show de bola, cara!

Estou entrando agora no "titanium world" e suas explicações vieram na hora certa.

Por coincidência estava lendo sobre esses comprarações nesse site: http://savagelook.com/blog/portfolio/a-deeper-look-at-appcelerator-and-phonegap

Abs.

Dirlei Dionísio disse...

Obrigado, Jônatan! Muito bom o link que vc compartilhou, ele aborda vários pontos que não comentei aqui. É uma boa leitura complementar :)

[]'s

Bruno Antognoilli disse...

Muito legal Dirlei, parabéns! Gostei do exemplo, já mostra o uso de API!!! ^^

Abs

Dirlei Dionísio disse...

Obrigado, Bruno!

Thiago disse...

Poxa, muito bom o artigo, ressalta bem os beneficios e aonde podemos chegar usando o titanium. Show de bola!

Dirlei Dionísio disse...

Valeu, Thiago!

Jônatan Fróes disse...

Dirlei, Vc já usou o Corona SDK? sabe de algum comparativo Titanium X Corona?

Abs.

Dirlei Dionísio disse...

Nunca usei o Corona, Jônatan, mas até onde sei ele é muito bom para o desenvolvimento de games. A linguagem utilizada é Lua, que é extremamente rápida e muito popular entre os desenvolvedores de jogos.

Luiz Duraes disse...

Obrigado por compartilhar ! De hoje em diante, me tornarei um frequente leitor deste blog !

[]s

GouverMXT disse...

Muito bom seu artigo, só fiquei em dúvida quanto ao Rhodes, pois no site deles diz "These are true native device applications (NOT mobile web apps)...". O Rhodes é nativo então, para mim seria bem mais interessante tendo em vista que já trabalho com Ruby.

Dirlei Dionísio disse...

Esse é o típico problema de usar o termo "nativo", como expliquei no primeiro subtítulo. O que a Rhomobile quer dizer com a frase que você citou é que as apps feitas com o Rhodes não estão na web e não rodam no browser do device. Elas são chamadas "nativas" porque é gerado um aplicativo que pode ser instalado nos devices (e não apenas um bookmark para uma página html). Mas internamente, a app possui um webkit para renderizar html/css. Apesar de o Rhodes prover uma ponte entre o código Ruby e o sdk nativo, as apps continuam sendo web-based. Pelo menos até a escrita desse artigo.

Cláudio disse...

Cara sua explicação foi excelente e está de parabéns, o blog está entrando para meus favoritos.

Dirlei Dionísio disse...

Muito obrigado, Cláudio! Grande abraço.

Anônimo disse...

Consigo desenvolver e testar para Iphone e Android com essa ferramenta?

Dirlei Dionísio disse...

Com certeza. Dê uma olhada nesse artigo em que explico como montar o ambiente de desenvolvimento: http://maisquetitanium.blogspot.com.br/2011/09/montando-o-ambiente-de-desenvolvimento.html

Unknown disse...

Parabéns pela iniciativa Dirlei.

Sou desenvolvedor CoronaSDK e venho agora iniciar uma "caminhada" pelo Titanium haja vista o Corona tenha seu calcanhar de aquiles localizado justamente na UI.

Após ter visto ontem durante 5h quase todos os vídeo disponíveis no site do próprio Appcelerator, encontrei seu blog e fico contente com isso (algo na nossa língua nativa - PT). :)

Como um amigo disse acima, tb estou colocando seu blog nos favoritos.

PS: Te adicionei nas minhas redes sociais e enviei um Tweet pra você também.

Um abraço de outro carioca,

Rodrigo Costa.
@RSCdev

Dirlei Dionísio disse...

Obrigado, Rodrigo. E seja bem-vindo ao Titanium! Grande abraço!