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 pool. Desta forma, somente uma cópia é requerida.

Através desse método de compressão a máquina virtual Dalvik ganha agilidade e velocidade na interpretação e execução de código Java, cumprindo o objetivo de ser otimizada para o uso mínimo de memória em um dispositivo móvel.

Na última camada da pilha de software são encontrados frameworks e aplicativos.

O Android possibilita a criação e o aproveitamento de recursos através do framework. Isso significa que os desenvolvedores podem tirar proveito do hardware, acessar informações sobre localização, entre outras, através dos frameworks que acessam aplicações do núcleo da plataforma. A arquitetura do Android foi projetada para simplificar o reuso de código e componentes já existentes. Qualquer aplicação pode publicar (tornar público métodos, serviços, componentes) e quaisquer outras aplicações podem fazer uso dos mesmos.

Como parte dessas APIs, o Android possui Views que são usadas em vários tipos de componentes em uma aplicação como listas, caixas de textos, botões, grids. Também há uma API chamada Content Providers que possibilita o acesso a dados de uma aplicação por outra. Notification Providers permite o compartilhamento de alertas e mensagens na barra de status. Window Manager auxilia no gerenciamento das janelas e aplicações abertas. E assim por diante, cada framework tem sua particularidade que é compartilhada com as demais aplicações.