Onde está o Xanax?

A primeira versão funcional da nossa aplicação, finalizada há uma semana, é baseada num modelo de interacção muito simples: um ecrã principal (a lista de todos os contactos), que permite abrir um de outros vários ecrãs (criar/editar um contacto; alterar o estado; ver o estado actual e número de telefone do SIM).

Como tal, não houve grande dificuldade em representar visualmente as várias funções da aplicação, pois estavam todas separadas em ecrãs distintos (a dificuldade estava em fazer funcionar essas operações). Cada um deles é chamado como se de uma função se tratasse: assim que esta é concluída, é devolvido o controlo ao ecrã inicial, existindo a possibilidade de passar parâmetros de um lado para o outro. No Android, um ecrã é representado por uma “Activity”.

Neste momento, e porque estamos a atribuir um layout mais personalizado à nossa aplicação, pretendemos adicionar funcionalidades como por exemplo uma caixa de confirmação, para a operação de eliminar um contacto da lista. Isto implicaria modificar temporariamente, de alguma forma, o layout de um ecrã. Após algum tempo dispendido em pesquisas e muita leitura, descobrimos que tal operação pode ser feita chamando um novo ecrã (iniciando uma nova “Activity”), de fundo transparente. Este processo assegura que o controlo do utilizador se mantém apenas na caixa de diálogo (pois é o ecrã que se encontra em foreground), permitindo no entanto ver em background o ecrã anterior.

Outra alteração necessária prende-se com os novos layouts para a lista de contactos e lista de estados, que deixam de ser representados em forma de lista. O Android possui métodos na classe ListActivity, que permitem criar uma lista com navegação para um cursor (que, no nosso caso, resulta de queries à BD). Estes métodos não são aplicáveis ao nosso layout, pelo que teremos de controlar manualmente que elementos aparecem, e onde aparecem, de forma semelhante ao que seria necessário programar para uma galeria de fotos. Embora o conceito seja simples (e alguns de nós o tenhamos implementado em websites, na disciplina de Laboratório Multimédia 5), fazer funcionar no Android está a revelar-se uma dor de cabeça…

Para a comunicação com o servidor, e porque esta não é instantânea, estamos a explorar a definição de serviços e/ou eventos. Este processo é importante pois permite à aplicação do Android fazer um pedido ao servidor, não tendo de esperar por uma resposta para poder devolver o controlo ao utilizador (caso contrário este irá pensar que o programa bloqueou caso a comunicação demore algum tempo). Para além disso, o estado “Em chamada” requer um serviço a correr em background, para que o estado possa ser comutado sempre que se efectue uma chamada.
Estes métodos parecem neste momento mais complexos de aprender e implementar, utilizando noções de programação bastante avançadas, para lá da nossa formação académica (quem sabe, um dia, incluir uma cadeira sobre Sistemas Operativos em NTC =P). Este motivo, conjugado com a data da próxima apresentação, levou-nos a simplificar nesta fase a forma como são efectuados os pedidos ao servidor. O Android irá apenas comunicar o estado do utilizador, ou abrir directamente um XML no servidor que contém os estados de todos os contactos; o servidor será responsável por gerar esses ficheiros XML (um para cada “cliente” – emulador Android) sempre que é alterado o estado de um deles.

Ao contrário das metas definidas para a semana anterior, que conseguimos cumprir atempadamente, as desta semana estão a revelar-se um bocado mais complexas e morosas. No entanto, esperamos conseguir rematar pelo menos algumas destas questões até Terça-Feira!