Android na Prática - Revista Mobile Magazine 37

Artigo no estilo: Curso

O profissional que desenvolve aplicações utilizando Java ME e que começou a se aventurar no mundo do Android ficou sem dúvida deslumbrado com as possibilidades que esta plataforma oferece.

Para construir interfaces gráficas no Android podemos criar os componentes separadamente em um arquivo XML, e deixar a parte do comportamento desses componentes para o código Java. Já no Java ME, geralmente os componentes são criados e os comportamentos são tratados na mesma classe, usando as famosas bibliotecas gráficas LCDUI (Limited Connected Device User Interface) ou LWUIT (LightWeight User Interface Toolkit). Existe também o framework J2ME Polish, que pode ajudar muito o desenvolvedor nessa etapa do código, mas o seu uso não é tão comum por se tratar de um framework que não é open source.

Em termos de persistência de dados, o Android faz uso de uma poderosa ferramenta, o SQLite, que funciona como um SGBD e chama atenção por ser leve e muito confiável. No entanto, se você não tem tanto conhecimento em códigos SQL, pode fazer uso do Db4o, um banco de dados Orientado a Objetos que é de fácil integração com o Android (para mais informações sobre o Db4o, consulte a seção Links).

No Java ME fazemos uso do sistema de RMS (Record Management System) para armazenar nossos dados. O RMS é uma estrutura muito simples projetada para funcionar em dispositivos limitados. Armazena apenas array de bytes (byte[]) que ao serem salvos receberão um int que servirá como identificador desse registro. Por trabalhar apenas com bytes, é necessário que o desenvolvedor se preocupe em serializar e desserializar os dados que serão salvos, tarefa que pode ser evitada graças ao framework open source Floggy. Ele encapsula o contato da aplicação com o RMS, deixando o código mais simples e agilizando a vida do profissional que trabalha com Java ME. Para mais informações sobre o Floggy, consulte a seção Links.

Além dessas diferenças, o Android possui recursos do Java 5, como: for each, coleções, generics, uso de reflexão, entre outros. Sua arquitetura favorece o compartilhamento de informações e funcionalidades entre aplicações, isto é, você consegue fazer uso de recursos de outros aplicativos no seu próprio sistema, sejam eles nativos do Android ou não.

Para exemplificar, imagine que você queira implementar um aplicativo que simule um álbum de fotografias. O objetivo é capturar fotos e fazer vínculos dessas imagens com informações dos seus amigos. No Android faríamos desse modo: para recuperar as informações dos amigos, usaríamos a base de dados da aplicação nativa do Android responsável por manter os contatos do celular, ou seja, a agenda. Dessa maneira teremos uma funcionalidade extremamente confiável com o mínimo de esforço, pois estamos usando a base de dados de um sistema já implementado e testado. Agora nos resta desenvolver a funcionalidade de captura de imagens via câmera, ou poderíamos novamente fazer uso de outro aplicativo do Android, o responsável pela captura de fotos.

Veja que todos os requisitos críticos do nosso sistema podem ser atendidos por aplicativos externos ao nosso. Assim, conseguimos poupar trabalho e código, reduzindo o tempo de entrega do projeto e os pontos que poderão acarretar em bugs no sistema. Esse artigo visa demonstrar de maneira prática como usufruir dessas facilidades providas pelo Android.

Criando interfaces gráficas no Android

O Android proporciona uma forma muito interessante de se criar interfaces gráficas. Podemos criar layouts com inúmeros componentes a partir de arquivos XML e deixar a parte de tratamento de eventos para as classes Activity. Dessa forma, o código melhora muito em termos de arquitetura, pois a aplicação ganha um nível extra de desacoplamento na parte referente a interfaces gráficas (ver Figura 1).

Figura 1. Ciclo de vida de uma Activity.

O Android possui uma classe que se chama Activity. Embora seu conceito seja mais abrangente, podemos pensar nessa classe como uma tela no sistema. Portanto, em alguns momentos, podemos nos referir à classe Activity usando a palavra “tela”.

O Android trata as activities como se estivessem em uma pilha, chamada de activity stack (pilha de atividades). Logo, a tela que está interagindo com o usuário é a que está no topo dessa pilha, podendo existir várias outras activities abaixo dela em estado parado ou pausado. Desse modo, uma Activity que for chamada e ficar em contato com o usuário ocupará o topo da pilha e a Activity que estava interagindo anteriormente ficará logo abaixo da nova.

Uma Activity possui um ciclo de vida (apresentado na Figura 1) que deve ser entendido pelo desenvolvedor para que ele consiga ter controle total da tela que será exibida. É através dos métodos do ciclo de vida que conseguimos, por exemplo, iniciar os componentes da tela momentos antes de sua exibição para o usuário, ou eventualmente executar ações como persistir dados antes que ela seja finalizada.

Basicamente o ciclo de vida indica as fases em que uma Activity vai passar. Essas fases são definidas como:

• Parada: A Activity não chegou a ser executada. A tela ainda não foi exibida;

• Ativa: A Activity está executando, ou seja, a tela foi criada e está sendo exibida para o usuário;"

[...] continue lendo...