Riopro Blog

Após ler diversos bons posts a respeito do Android (ver no final os links indicados pelo Rodrigo), resolvi dar uma olhada mais próxima. A maior curiosidade era o Dalvik, um fork máquina virtual Java, disponibilizado para rodar as aplicações desenvolvidas para os futuros gPhone’s. Outra curiosidade era avaliar o plugin feito para o Eclipse e o emulador (muito importante já que não existe ainda nenhum celular funcionando com o Android).

O Dalvik é bastante interessante, por delegar ao sistema operacional do Android o isolamento de memória e o suporte a threads. Ou seja, usa com intensidade o ponto forte do kernel do Linux (estrutura básica do SO do Android). Não dá ainda para avaliar a performance real por falta de um protótipo, mas a expectativa é positiva. Nem vou entrar na discussão sobre mais um fork da máquina virtual do Java, porque isso já foi tratado nos links ao final. A minha opinião é positiva em relação a isso. Ainda não existe uma padronização tão grande nos aparelhos de celular, o próprio desenvolvedor se vê obrigado a suportar diversas versões de máquina virtual nos celulares, o que prejudica a compatibilidade total do código desenvolvido.

Outro ponto muito discutido foi a API básica do Android. Enxuta, ou melhor, selecionada, ela excluí similares (por exemplo, não tem a java.io, só a java.nio, mais recente) e coloca para todos os desenvolvedores pacotes úteis como java.util.ResourceBundle, usado para internacionalização e que na JavaME só está disponível para os aparelhos mais avançados, que usam a versão CDC. A API do Java é muito inchada. E não são só os criadores do Android que pensam assim. Já vi muita discussão sobre isso, como essa aqui. E com algumas classes muito pouco evoluídas para uma linguagem há tanto tempo estabelecida, caso clássico da java.util.Date (que não escaparemos de usar no Android, junto com a Calendar). Mas, já que um dos objetivos era reduzir o tamanho do pacote básico disponível, porque não aproveitar e excluir as dezenas de métodos marcados como deprecated?

Quanto ao plugin para o Eclipse e o Emulador, achei ambos excelentes. Raro ver um lançamento inicial tão bem feito, integrado e sem bugs. Somente a edição campos ainda poderia ser melhorado com um ajudante para agilizar a criação de campos dos templates de telas (pelo menos não encontrei nenhum). Pelo menos, o parser do Android xml não deixa errar no momento de criar os campos para cada template. Ou melhor, deixa, mas nesse caso, a compilação não funciona. Se estiver usando o plugin do Eclipse, um problema será informado antes da compilação. Mais rápido ainda para identificar os erros da sua visão.

Gostei também de duas características do sdk do Android: os Content Providers e os Services (leia sobre a anatomia completa do sdk aqui). Os Content Providers são, em linhas gerais, os bancos de dados intercambiáveis, ou melhor, a forma padrão de acesso a dados armazenados no celular. Com isso, desde que especificado no AndroidManifest.xml de sua aplicação, você pode ter acesso aos contatos do celular ou qualquer outro recurso (como a lista de imagens do celular por exemplo). Ter bases intercambiáveis aumenta bastante o poder das suas aplicações. Você pode, por exemplo, ter uma aplicação que baixe a cotação de ações da bolsa de valores e outro aplicativo que acesse a base de dados de cotações e envie um alerta para o usuário quando a cotação atingir ou ultrapassar um determinado valor (veja aqui um vídeo com uma aplicação exemplo).

Ao analisar o exemplo acima você pode se perguntar: “Tá, mas a aplicação que envia as mensagens vai ter que ficar ativa o tempo todo?”. Bom, é aí que entra os Services. Os Services permitem criar “códigos que ficam ativos mesmo sem uma interface de usuário” (numa tradução rápida da própria descrição de Services). Ou seja, é o famoso rodar em background (quem usa linux está acostumado com os Daemons). Essa característica é muito legal, mas tenho medo que os participantes do consórcio inibam essa características para aumentar a “segurança” do celular.

NOTA: No momento que escrevi o artigo esqueci de um  item melhor ou igual aos Services: o Intent Receiver. Diferentemente dos Services, o Intent Receiver permite que o celular chame a aplicação, mesmo que ela não esteja rodando, através de uma notificação (o NotificationManager).
Finalizando, devemos ressaltar que a documentação também foi muito bem feita, com bons exemplos para iniciar no SDK do Android. Inclusive alguns vídeos de aplicações exemplo foram colocadas no YouTube. Um bom início para a Open Handset Alliance, por mais que somente com um protótipo os desenvolvedores vão ficar realmente confiantes.

Links:

Google’s Android parts ways with Java industry group
http://crave.cnet.com/8301-1_105-9815495-1.html?part=rss&tag=feed&

Google’s Android SDK Bypasses Java ME in Favor of Java Lite and Apache Harmony
http://www.infoq.com/news/2007/11/android-java

Off-Topic: gPhone!
http://www.akitaonrails.com/2007/11/13/off-topic-gphone