Adapters em diferentes views no Android

Com a crescente demanda de aplicativos no mercado, desenvolvedores necessitam minimizar o tempo de desenvolvimento e ao mesmo tempo prover novas e melhores soluções em suas aplicações que exijam disponibilidade de dados em um formato claro e intuitivo para os usuários cada vez mais exigentes.

Na plataforma Android existem vários modos de se apresentar dados para os usuários de aplicativos. Essa variedade se dá desde o uso de simples objetos como caixas de texto, tabelas (semelhantes a uma planilha), painéis, quanto o uso de objetos mais complexos, como listas que podem possuir linhas com uma diversidade de objetos e grades.

Neste artigo serão apresentados alguns dos objetos citados, como usá-los e boas práticas em relação às APIs da plataforma focando no reaproveitamento de código em diferentes Views.

Para iniciarmos, é indispensável abordar a arquitetura da plataforma e o entendimento sobre o funcionamento de aplicativos, o ciclo de vida de Atividades (Activities), o uso de bibliotecas em diferentes versões e as permissões.

As aplicações Android são diferentes porque possuem comportamento particular e estão sendo executadas em ambientes que diferem de desktops ou servidores. Por isso, o desenvolvedor deve atentar para as características essenciais dessa plataforma, tais como:

· Recursos de hardware atualmente não são comparáveis a desktops e servidores, portanto há limitações. Uma dessas limitações é a bateria e o seu consumo. Hoje a bateria é um componente muito limitado e restringe o uso de processamento por muito tempo;

· Reuso de código é essencial para esse ambiente. Uma vez limitado ao hardware, comparado a um computador, o dispositivo móvel possui menos memória e processamento. Assim, a solução é a reutilização de componentes e serviços bases que a plataforma provê para outras aplicações;

· Na plataforma Android não há aplicações específicas como, por exemplo, navegador de internet único. Se o usuário quer navegar na internet o Android provê a navegação, não importando o navegador instalado, ou seja, tanto faz se um navegador padrão já está instalado ou um navegador de terceiros (e.g. Opera). Não há uma aplicação específica para ação ou ambiente específico.

O Android é uma pilha de software para dispositivos móveis que inclui um sistema operacional, middleware e aplicações chave. O sistema operacional é o “elo” entre hardware e software. A camada de middleware é onde estão as bibliotecas responsáveis pela reprodução de áudio, vídeo, gravação de imagens, armazenamento em banco de dados, etc. As aplicações chaves são os softwares que proveem a interatividade para outras aplicações. Esses três componentes combinados constroem essa relação sistêmica comparada a uma pilha, na qual se tem o sistema operacional na base da pilha, o middleware por cima da base e no topo da pilha as aplicações. A arquitetura do Android pode ser vista na Figura 1.

abrir imagem em nova janela

Figura 1. Visão geral da plataforma Android.

Na base da pilha de software é encontrado o sistema operacional (SO) Linux. Linux é um SO aberto e gratuito para desenvolvimento e distribuição. O kernel do Linux é o núcleo desse sistema operacional. Na Figura 1 pode ser observado que o kernel do Linux faz a interação entre hardware (parte física) e software (programas) do dispositivo móvel. O SO contém os drivers que fazem a comunicação com os dispositivos de hardware. Existe, por exemplo, driver Wi-Fi para conexão e comunicação em redes wireless, driver de áudio, gerenciamento de energia, driver para o vídeo, GPS (Global Positioning System), acelerômetros, bússola, Bluetooth e telefonia GSM (Global System for Mobile). O kernel utilizado no Android é da versão 2.6 do Linux.

Na segunda camada da pilha de software é encontrado o middleware. No middleware existem aplicações que servem como base para que algumas aplicações da camada de cima possam ser executadas. Nessa camada são encontradas bibliotecas de áudio, aceleração tridimensional (e.g. OpenGL), armazenamento de dados (e.g. SQLite), framework de mídia (e.g. codecs), entre outros.

Ainda na mesma camada, pode ser encontrada a máquina virtual do Android, chamada DVM (Dalvik Virtual Machine). A DVM foi criada com o intuito de aperfeiçoar o runtime das aplicações no dispositivo móvel. Ela não é uma JVM (Java Virtual Machine), porém tem o comportamento parecido. Enquanto que na JVM ocorre a interpretação e execução do código Java, no caso da DVM o sistema operacional Android usa máquinas virtuais para executar cada aplicação num processo. Isso permite independência entre as aplicações. Caso alguma aplicação pare, ela não afetará quaisquer outras aplicações em execução no dispositivo e, por último, simplifica o gerenciamento de memória. Mesmo que o desenvolvimento de aplicativos para a plataforma Android seja em Java, a DVM converte os arquivos .class e/ou .jar para arquivos .dex (arquivo “executável” da DVM).

Essa conversão de arquivos nativos do Java (.class e.jar) para. dex tem como propósito diminuir o espaço total usado no armazenamento de aplicações. Cada arquivo .class contém pools de constantes, os quais são muito redundantes para a aplicação e são frequentemente a maior parte do arquivo. Como existem vários pools de constantes em vários arquivos .class com o mesmo valor, não é necessário usar valores repetidos mas somente um "