É comum as pessoas se referirem aos vários tamanhos e definições de tela no Android como um gigantesco problema. Mas será tudo isso?

Desde a primeira versão do sistema, a plataforma já suportava o posicionamento dinâmico dos elementos, coisa que plataformas como iOS estão adotando só agora. O desenvolvedor Android sempre teve essa questão em mente. Mas será que isso é tão complicado como as pessoas dizem?

Fizemos um talk interno na Concrete Solutions para coletar experiências dos times sobre esse problema. Participaram tanto desenvolvedores (inclusive internacionais), quanto designers.

O primeiro ponto levantado foi nos atentar para a definição base do projeto: qual o formato e definição mais popular entre os dispositivos Android? Essa informação nem sempre é simples de ter, mas o panorama geral é disponibilizado no dashboard do Google. Atualmente temos:

Percebemos que há uma maior concentração para dispositivos hdpi (alta densidade de pixels independentes) com tela tamanho normal. Porém, mdpi (média densidade) ainda possui uma porcentagem representativa. Então, como atacar o problema?

Recomendamos sempre olhar para sua base de usuários para definir o baseline mas, de uma forma geral, por mais que o mdpi ainda seja representativo, gerar assets de hdpi para cima tem suas vantagens:

• Assets serão automaticamente redimensionados para mdpis (ao custo de um pouco de processamento)
• Seu APK (o arquivo executável da aplicação) terá um tamanho reduzido
• Você ainda estará atingindo mais de 80% da base mundial de dispositivos

Assim, caso sua base de usuários não seja um caso muito particular e tendo em mente a abordagem mobile first, recomendamos começar o desenvolvimento pensando em emuladores com telas do tamanho normal e densidade alta (hdpi).

É importante dizer para o Google para quais tamanhos e densidades você está preparando sua aplicação. Fazemos isso no arquivo AndroidManifest.xml com a seguinte declaração (apenas um exemplo):

<compatible-screens>
    <screen android:screenDensity="hdpi" android:screenSize="small"/>
    <screen android:screenDensity="xhdpi" android:screenSize="small"/>
 
    <screen android:screenDensity="hdpi" android:screenSize="normal"/>
    <screen android:screenDensity="xhdpi" android:screenSize="normal"/>
    <screen android:screenDensity="480" android:screenSize="normal"/>
</compatible-screens>

Até aqui temos nosso alvo marcado e declarado. Não há mais nenhum truque?

Durante nosso talk falamos de outras maneiras de melhorar a performance de nossos aplicativos em várias telas. Por exemplo, usar imagens 9 patch. Este é um recurso antigo do Android, porém ninguém gostava de usar por acreditar que era muito complexo para gerar e manter estes 9 patches (eu, inclusive, estava nesse time de desenvolvedores). No entanto, algumas coisas mudaram no Android neste campo.

Welton Carvalho e Edouard Roussillon deram várias dicas de como criar e manter estes recursos. Uma delas é o 9 patches editor do Android Asset Studio. Outro editor é o da Web Look and Feel.

A vantagem de 9 patches é que eles escalam. O desenvolvedor ou designer define áreas do recurso que podem ser repetidas. Um botão, por exemplo, pode ter tudo que está entre as bordas repetido. Assim o recurso fica menor do que uma imagem para cada definição.

A alternativa a 9 patches é usar o esquema de recursos do Android mais a fundo. É possível fazer muita coisa usando apenas definições em xml. Por exemplo: sombras, botões com bordas arredondadas com gradientes de cores e etc. Com isso, você pode definir dimensões específicas para cada densidade e o recurso será altamente performático.

Por fim, ficou ressaltado que os desenvolvedores Android possuem diversos recursos para atacar esse problema. Nem sempre conhecemos todos e por isso a troca de experiências é importante. O Android Studio, por exemplo, possui integrado um editor de 9 patch (uma interface um pouco confusa, mas que pode ser útil), e o gradle nos permite limitar os recursos das dependências que queremos incluir. Exemplo:

android {
 
    defaultConfig {
    // exclui recursos de dependências de outras densidades que não as declaradas aqui
    resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi", "xxxhdpi"
    }
}

Aqui na Concrete Solutions estamos sempre discutindo sobre qual a melhor forma de resolver problemas do desenvolvimento. Para o caso de várias telas e densidades, a conversa é constante, mas não acreditamos que nos complicamos muito por causa disso. Fiquem atentos que ainda vamos falar sobre como os desenvolvedores e UXers trabalham juntos para resolver estes detalhes.

Dúvidas e sugestões: deixem um comentário!