Resources

Como temos estudado até agora, sabemos que uma aplicação Android é composta por diversos recursos, tais como imagens, animações, arquivos de áudio e vídeo, estilos, etc. Por padrão, todos esses recursos são organizados dentro da pasta res e são organizados em subpastas, e, a seguir, veremos mais detalhes dessa estrutura. Além das pastas padrão de recursos, podemos, também, definir pastas específicas que serão utilizadas pelo Android, de acordo com as configurações do ambiente de execução da aplicação, bastando utilizar os qualificadores de recursos pré-definidos pela plataforma. A Tabela 1 trás os principais modificadores de recursos relacionados a características de tela. A tabela contendo todos os modificadores disponíveis pode ser encontrada em http://developer.android.com/guide/topics/resources/providing-resources.html. Perceba que alguns modificadores dependem de uma versão específica de API a ser utilizada, como indicado na própria tabela.

Característica da Tela	Qualificador	Descrição
Largura Disponível	w<N>dp	Especifica uma largura mínima de tela, em dp, para aquele recurso ser utilizado. Ex: w720dp para telas com no mínimo 720 dp de largura. Esse valor leva em consideração a orientação do dispositivos para determinar qual dimensão é a largura. API 13
Altura Disponível	h<N>dp	Especifica uma altura mínima de tela, em dp, para que o recurso seja utilizado. Ex: h720dp para telas com no mínimo 720 dp de altura. Esse valor também leva em consideração a orientação do dispositivo. API 13
Tamanho	small	Recursos para telas pequenas.
	normal	Recursos para telas de tamanho normal. (Tamanho padrão)
	large	Recursos para telas grandes.
	xlarge	Recursos para telas extragrandes.
Aspecto da tela (AspectRatio)	long	Recursos para telas com proporções muito diferentes da altura e largura das medidas padrão.
	notlong	Recursos para telas com proporções similares à altura e à largura das medidas padrão.
Orientação	land	Recursos para telas em modo paisagem.
	port	Recursos para telas em modo retrato.
Densidade	ldpi	Recursos para telas de baixa densidade (~120dpi).
	mdpi	Recursos para telas de média densidade (~160dpi). (Densidade padrão)
	hdpi	Recursos para telas de alta densidade (~240dpi).
	xhdpi	Recursos para telas de densidade extra-alta (~320dpi).
	nodpi	Recursos para telas de todas as densidades. Devem ser imagens, independente de densidade, uma vez que o sistema não irá redimensioná-las.
	tvdpi	Recursos para telas de TV. Sua densidade real ficaria em torno da média e da alta.

Tabela 1 – Qualificadores de Recursos do Android

Para cada tipo de recurso, deve-se definir uma pasta padrão (sem nenhum qualificador), que será utilizada quando não existem pastas qualificadas ou ainda quando o ambiente de execução atual não se encaixa em nenhuma das condições impostas pelos qualificadores utilizados. Isso é importante principalmente quando se utilizam qualificadores que dependem de uma versão específica de API, para garantir que haja a disponibilidade de recursos em qualquer versão.

Um exemplo disso é o seguinte cenário: imagine que desejamos definir layouts independentes para as diferentes orientações de tela (retrato ou paisagem). Será que precisamos criar duas pastas classificadas, uma para layout-land e outra layout-port? A resposta é não. Como o Android utiliza a pasta layout como padrão, basta definirmos uma outra pasta layout-land, armazenando os layouts específicos da orientação paisagem. Nesse caso, haverá um conjunto de arquivos de layout genéricos, que serão usados sempre que não houver arquivos de layout específicos para uma determinada orientação.

Outro ponto importante é em relação à utilização de múltiplos qualificadores para uma única pasta. Nesse caso, deve-se separar os qualificadores por hífens e utilizá-los na ordem em que foram apresentados na tabela. Por exemplo: layout-port-hdpi. Tenha em mente também que não são diferenciadas maiúsculas de minúsculas e que só é possível ter um recurso do mesmo tipo em cada pasta, ou seja, não é possível ter um layout-hdpi-ldpi.

Para melhor exemplificar o uso dos qualificadores, observe a Figura 1 a seguir.

Na Figura 1, observamos que o layout definido na aplicação para telas pequenas, como a de um smartphone, é o mesmo utilizado para telas grandes, como a de um tablet. Nem sempre esse tipo de comportamento é otimizado para todos os casos e, por isso, caberia o uso de qualificadores do tamanho da tela, melhorando a usabilidade da aplicação. Após seu uso, a aplicação, que antes se comportava como na Figura 1, se comportará como na Figura 2, com diferentes telas.

A estrutura de organização dos recursos de nossa aplicação é bem simples e pode ser observada na Figura 3.

Como pode ser observado, a estrutura de um projeto é organizada de tal forma a realizar uma separação entre os arquivos de configuração, as classes (geradas automaticamente e criadas) e os recursos. Conforme já dito anteriormente, todos os recursos são armazenados na pasta res e são separados em subpastas de acordo com o tipo de recurso armazenado. As subpastas suportadas são mostradas no Tabela 2.

Directory	ResourceType
animator/	Arquivos XML para definir animações de propriedades.
anim/	Arquivos XML para definir tweensanimations (pode salvar arquivos de animações de propriedades, apesar de ser recomendado apenas para tweenanimations).
color/	Arquivos XML para listar cores.
drawable/	Arquivos de imagem (.png, .9.png, .jpg, .gif) ou XMLs que podem ser convertidos em imagens.
mipmap/	Arquivos de imagem para diferentes densidades de ícones da aplicação.
layout/	Arquivos que definem a interface com o usuário.
menu/	Arquivos de menu, seja de contexto ou de opções.
raw/	Arquivos em formato raw. Devem ser abertos utilizando-se um InputStream através da chamada do método Resources.openRawResource.
values/	Arquivos XML contendo valores simples, como strings, inteiros, cores, etc. Diferentemente das outras pastas, os recursos mostrados nessa pasta são definidos pelos filhos da tag <resource> dos arquivos XML. Por exemplo, um resource que contenha uma tag <string> irá gerar um registro em R.string, e não em R.values. Apesar do nome dos arquivos não ser importante para a classe R, existem convenções em relação à nomeação deles: - arrays.xml para arrays - colors.xml para cores - dimens.xml para dimensões - strings.xml para strings - styles.xml para estilos
xml/	Arquivos XML arbitrários, que podem ser lidos através do método Resources.getXml.

Tabela 2 - Subpastas de recursos suportados

Muitas vezes, precisamos acessar esses recursos que definimos dentro das classes do programa. Para isso, referenciamos os recursos utilizando seu identificador único, mais especificamente, o seu nome. Esse identificador único é criado automaticamente no arquivo R.java, durante o processo de compilação da aplicação.

A classe R.java armazena os IDs de todos os recursos adicionados na pasta res e segue uma estrutura bem simples. Para cada tipo de recurso utilizado no projeto, é adicionada uma subclasse estática à classe R (por exemplo, R.layout contém os ids de todos os layouts definidos) e para cada recurso adicionado àquele tipo, é criado um inteiro, também estático, cujo valor é o identificador único a ser utilizado para futuras referências. O valor desses IDs são criados e gerenciados automaticamente pelo ADT (AndroidDevelopment Tools).

Como já viemos estudando até agora, sabendo que o nome dos recursos na classe R é o nome do arquivo (sem sua extensão) ou o valor definido na propriedade android:name no XML do recurso, podemos facilmente acessá-los. Se quisermos, por exemplo, acessar o arquivo de layout main.xml através de uma classe, devemos referenciá-lo pelo nome R.layout.main.

Se necessitamos referenciar um recurso a partir de um arquivo XML, utilizamos uma estrutura similar. Para acessar uma imagem com o nome "minhaImagem", que foi adicionada na pasta drawable, fazemos a referência ao seu id através da estrutura @drawable/minhaImagem, como pode ser visto no trecho de definição de um ImageView na Listagem 1.

<ImageView android:id="@+id/imageId" android:src="@drawable/minhaImagem"/> Listagem 1 – Referência a uma imagem definida em uma das pastas drawable

É importante perceber que as pastas qualificadas são utilizadas direto pelo sistema Android e não pelo programador para escolher qual recurso será exibido. Sendo assim, se temos um layout main.xml que possui três variações possíveis (ldpi, mdpi e hdpi, por exemplo), devemos apenas criar um arquivo main.xml em cada uma das pastas qualificadas (layout-ldpi, layout-mdpi e layout-hdpi, no caso) e referenciar o layout através de R.layout.main, deixando para o Android escolher, durante a execução, em qual pasta o recurso será buscado.