Ricardo Ogliari

Os desenvolvedores Android, em geral, compartilham de uma mesma opinião: a estrutura de desenvolvimento com a API da plataforma é muito inteligente, tudo está co-relacionado e os aplicativos de terceiros seguem a mesma linha de raciocínio de todas as aplicações nativas do próprio sistema operacional. Esta opinião se torna ainda mais extremista quando o desenvolvedor é oriundo de mundos mais obscuros, como Java ME e BlackBerry. Neste breve artigo pretendo mostrar e provar como estas opiniões estão certas, através das três principais facilidades (na minha opinião) que o Android nos fornece.

 a)       Interfaces gráficas

A construção das interfaces gráficas em aplicativos Android é facilitada por diversos motivos. O primeiro deles é a possibilidade e a liberdade dado ao desenvolvedor para escolher: utilizar a linguagem Java ou a linguagem de marcação XML.

O segundo motivo pode ser a alma Model-View-Controller que o Android possui. Falo isso porque cada tela é chamada na plataforma de Activity. Cada atividade está declarada em um arquivo de configuração central, chamado de AndroidManifest. xml. Como é indicado pelo site de desenvolvedores da Google e também por mim (a opinião do Google conta mais ok) devemos criar nossas interfaces utilizando XML. Deste modo, a lógica da aplicação fica separada, toda no código Java. As informações que populam estas telas, quando necessárias, também estarão separadas, podendo estar em um SharedPrefenre, no banco de dados SQLite, na pasta de recursos do projeto (res) ou em adapters . Ou seja, total separação de camadas.

Além disso, é importante ressaltar que o ambiente de desenvolvimento, principalmente no Eclipse, ajuda em muito o desenvolvedor. Tendo inclusive a possibilidade de criar interfaces apenas “clicando e arrastando” componente, e, posteriormente, editando suas principais propriedades, como largura, altura, borda, cor da fonte, cor de background, dentre outros.

b)       Internacionalização

Para você que estiver lendo este texto – imagino que as chances de seu um programador são grandes – imagine o seguinte cenário: temos um local específico dentro do nosso projeto onde definimos todos os textos utilizados na nossa aplicação. Este conjunto de strings pode estar em um arquivo XML para facilitar a compreensão. Para adicionar um novo idioma, basta ter um novo conjunto de strings, apenas mudando o nome do arquivo e acrescentando um hífen e o código do país. Por exemplo: string-es.xml.

Agora, na codificação de nosso aplicativo, tudo que devemos fazer é informar a chave do texto que desejamos. Sendo que, esta chave estará presente em todos os arquivos de internacionalização que citamos acima. Por exemplo, na tela de listagem de nomes teremos um texto identificado por labelName. Este rótulo estará disponíveis nos arquivos strings-es.xml, strings-pt.xml, strings-ch.xml e assim por diante. Em tempo de execução, o próprio sistema operacional reconhece qual idioma está sendo usado e busca no XML apropriado a versão correta do texto para aquele idioma.

Conseguiram visualizar este cenário? Isso é o que acontece no Android. Temos uma pasta res, com uma sub-pasta chamada values. Dentro dela poderemos ter inúmeros arquivos string-<IDIOMA>.xml. Quando construímos nosso aplicativo, basta indicar o uso de um destes textos e o próprio Android saberá qual versão utilizar em tempo de execução.

c)       Versão de imagens específicas para determinadas resoluções

O Android trabalha com separação de imagens por resolução de tela, de uma forma muito semelhante ao descrito na internacionalização anteriormente.

Na mesma pasta res, teremos três sub-pastas: drawable-hdpi, drawable-mdpi e drawable-ldpi. Perceba que as mudanças ocorrem somente em uma letra, h (high), m (medium) e l (low). Elas servem para que o desenvolvedor coloque as imagens específicas de cada resolução.

Na codificação de nossa aplicação, provavelmente uma Activity, basta aponta pro recurso da imagem. Sendo que está não estará separada por resolução, veremos apenas seu nome. Por exemplo, se colocarmos uma imagem chamada ícone nas três pastas descritas acima, no código Java chamaremos este caminho: R.drawable.icone. Tudo bem, mas o leitor deve estar se perguntando: e quem decidirá de qual pasta pegar a imagem? Não vou programar isso? As respostas são: o sistema operacional e não.

Explicando melhor. Em tempo de execução, o sistema operacional Android verificará a imagem que está sendo solicitada, vai checar qual sua resolução e vai devolver ao aplicativo a versão da imagem mais apropriada àquela tela. Simples, claro e rápido.

—————————–//—————————————-

Espero ter atingido meu objetivo, que foi mostrar três grandes facilitadores no desenvolvimento de aplicativos Android. O leitor pode, e deve, contribuir, comentando se aprova a escolha dos três itens, se acrescentaria mais algum, ou ainda, se discorda.

Se ficaram algumas dúvidas em relação ao desenvolvimento, também comente sua dúvida e responderei o mais rápido possível.