Compatibilidade - pt.2

A densidade da tela faz referência à quantidade de pixels que consegue ser armazenada em uma determinada região da tela e geralmente é expressada em dpi (dots per inch – pontos por polegada). O Android também provê uma separação de configurações de tela de acordo com suas densidades de tela. Tal separação pode ser observada na Figura 5.

Juntamente com o conceito de densidade, temos o de pixel independente de densidade, o density-independent pixel (dp), que é uma unidade virtual utilizada quando desejamos definir nossos layouts com medidas independentes da densidade da tela trabalhada. A medida de 1 dp equivale à medida de um pixel físico, mostrado em uma tela com densidade de 160dpi (que é a densidade utilizada pelo sistema como base para telas com densidade média).

Ainda relacionado à densidade da tela, temos mais uma medida, dessa vez definida para utilização com trabalhos de fontes. Essa medida é o pixel independente de escala (scale-independent pixel – sp), que trabalha de forma semelhante ao dp, com a diferença de levar em consideração as configurações de fontes definidas pelo usuário.

Outro importante conceito que deve ser cuidadosamente trabalhado em uma aplicação é a orientação da tela, que é como a tela está disposta ao usuário naquele momento. A disposição é separada em duas: horizontal (landscape) ou vertical (portrait). Para cada uma dessas disposições, pode ser interessante apresentar o conteúdo de forma diferente ao usuário, uma vez que a tela fica mais alta ou larga de acordo com sua disposição.

Uma medida muito vista nos detalhes de qualquer aparelho é a resolução da sua tela. Essa medida faz referência ao total de pixels armazenados na tela. É importante notar que, ao trabalhar a fim de suportar múltiplas telas, esse tipo de medida não deve ser levado em consideração, mas sim as medidas de tamanho e densidade.

Mas, no final, qual a importância de se estudar todos esses conceitos para a implementação de um aplicativo? Isso é notado apenas quando testamos nossa aplicação em diversas configurações de tela diferentes. Na Figura 6, podemos observar como ficaria uma aplicação desenvolvida sem preocupação com a densidade da tela.

Conforme observado, levando em conta os conhecimentos previamente adquiridos a respeito de densidade de tela, sabemos que a medida de 1 pixel em telas de diferentes densidades irá ocupar porções também diferentes da tela. Dessa forma, um botão cujo tamanho é definido em pixels ou uma imagem que não possui o devido tratamento vão aparecer maiores em telas de densidade pequena e, à medida que formos aumentando a densidade da tela, esses componentes irão ocupando cada vez menos espaço na tela.

Se modificarmos a aplicação mostrada na Figura 6, levando em consideração as possíveis mudanças de densidade, podemos atingir o resultado mostrado logo abaixo, na Figura 7.

Como pudemos ver, na forma apresentada na Figura 7, independente da densidade da tela, temos a nossa interface, conforme planejado na hora do desenvolvimento. Para se atingir esse resultado, muitas vezes, basta declarar todas as unidades utilizadas pela aplicação como dp, no lugar de outras medidas que vão variar com a densidade da tela.

Existem algumas formas de realizar o tratamento específico de diferentes configurações de telas, que vão desde flexibilizar o layout da aplicação para funcionar como esperado, independente das condições, até indicar quais telas são suportadas pela aplicação.

Para fazer a declaração dos tamanhos de tela suportados, é necessário o uso da tag supports-screen no AndroidManifest. Feito isso, você garante o uso do seu aplicativo de maneira adequada àquelas pessoas que possuírem aparelhos dentro das suas telas, ditas como suportadas.

Apesar de ser uma forma mais simples de garantir o correto funcionamento da aplicação, limitamos o número de possíveis usuários do nosso sistema, o que nem sempre é interessante. Para os demais casos, quando desejamos disponibilizar uma interface sólida para o maior número possível de aparelhos, podemos — e, muitas vezes, devemos — utilizar de duas formas de tratamento dos layouts e imagens, além de utilizar medidas independentes de pixel.

Para suportar a questão de layouts, podemos definir layouts independentes para os diferentes tamanhos de tela existentes. Devemos utilizar essa técnica quando a configuração de auto redimensionamento do Android não for satisfatória para o nosso propósito. Para tal, devemos criar novas pastas de layout, indicando que essas pastas serão utilizadas pelo Android (essa indicação é feita de forma automática, desde que as pastas que criemos, sigam os padrões definidos pelo Android, mostrados na Tabela 1). Os arquivos que essas novas pastas armazenarão devem ter o mesmo nome de seus arquivos armazenados na pasta padrão (sem qualificador), para que o Android possa fazer a escolha de recursos de acordo com seus qualificadores. Caso o arquivo contido na pasta com qualificador não possua o mesmo nome do arquivo padrão, o Android não conseguirá tratar esses dois recursos como versões de um só recurso.

É importante salientar que, a partir da API 13, os conceitos de tamanho de tela foram extintos, e substituídos por outro tipo de qualificador. Esse novo qualificador não limita os tamanhos por padrão, mas deixa por responsabilidade do programador o fazer, dando mais liberdade na modificação de seus layouts. Para utilizar o novo qualificador, basta seguir o modelo: sw<N>dp (Sendo <N> um número inteiro que indica o tamanho mínimo que a tela deve ter para que os layouts contidos nela sejam aplicados). Por exemplo, uma tela que precise de pelo menos 500 dp para funcionar adequadamente deve ser colocada em uma pasta layout-sw500dp/.