Aqui fica a apresentação de amanhã. Tem poucos slides, mas desta vez optámos mais por uma estratégia visual que acompanharemos oralmente.
A notar que, dentro desta apresentação, apesar de parecer existir um erro de numeração, não é o caso: o 2º ponto é omisso pois será esclarecido durante a apresentação do protótipo.
A apresentação encontra-se aqui. Em pdf, pois então.
Contra todas as nossas expectativas conseguimos realizar uma parte do nosso projecto que ambicionávamos muito, mas por não conseguirmos descobrir como a implementar, esteve muito perto de ser abandonada.
Num último esforço de pesquisa e trabalho, conseguimos chegar a terra depois de alguns dias à deriva. Neste momento já é possível colocar o ícone do estado que escolhemos na StatusBar, que será visível nas imagens deste post.
Uma vez escolhido o nosso estado é exibida uma mensagem numa caixa popup para confirmar a inserção de uma descrição de estado, na qual é possível clicar em “sim” e ir para um ecrã com um campo para escrever a já referida descrição, ou então simplesmente clicar em “não” para rejeitar a descrição. Depois destes passos, aparece em cima o ícone referente ao estado escolhido por nós, mas em tamanho reduzido, de maneira a adequar-se ao espaço destinado para o efeito. Esse ícone estará sempre presente em todos os ecrãs da aplicação, mas com uma particularidade, a de se poder clicar nele em qualquer altura e arrastar um ecrã que exibe uma série de detalhes relativos ao nosso estado.
Mais propriamente esses detalhes são: o nome do estado, o próprio ícone, a descrição se esta existir, a hora a que o estado foi escolhido e também um atalho directo para o ecrã com a lista de estados, possibilitando uma mais rápida “moodança” entre estados.
Em seguida estão as imagens que ilustram algumas partes do processo.
No seguimento do post anterior, esclarecemos aqui mais detalhadamente toda a parte da comunicação.
Para efeitos de visualização, e visto que este post ainda conteria bastante texto, decidimos converter esse texto para pdf. Para visualizar, basta clicar aqui.
Boas leituras!
Terminado o processo de desenvolvimento do protótipo, de seguida publicamos algumas informações e comentários pessoais sobre esse processo (incluindo problemas encontrados, soluções adoptadas, e soluções abandonadas ou arquivadas para a próxima fase). Esta informação estará contida ao longo dos próximos posts (que serão adicionados de seguida), abordando as várias componentes do projecto.
Relativamente à Base de Dados, e após utilização da mesma para a produção do protótipo, foi necessário proceder a pequenos ajustes – campos cujas regras foram alteradas, dois campos que passaram a existir apenas do lado Web, e dois novos campos para armazenar os endereços de memória onde estão armazenados os ícones dos estados. Embora este modelo inclua várias funções que o protótipo não implementa, foi possível testá-lo em vários ângulos (lado Android e Web, para diferentes operações) e não foram encontrados quaisquer problemas. Podemos assim concluir que é um excelente candidato a ser utilizado no modelo final, apresentando suficiente flexibilidade para a introdução de novas funcionalidades.
O protótipo conseguiu cumprir com as metas que inicialmente estabelecemos (a nível funcional), existindo naturalmente algum espaço para melhoramentos. Subsiste, no entanto, um pequeno problema com a actualização dos estados: o processo funciona perfeitamente durante as primeiras três acções, deixando de funcionar a partir desse ponto, até que o programa seja reiniciado.
Não obstante, a aplicação que produzimos representa um avanço tremendo no nosso domínio das diversas linguagens (apesar de parecer por vezes uma gota no oceano…), e foram ultrapassados obstáculos muito importantes, decisivos para a continuação do processo de desenvolvimento. Esta fase de prototipagem marcou um claro crescimento na nossa motivação, factor também decisivo na resolução de problemas complicados (principalmente quando cada problema exigia ao grupo várias horas de trabalho).
O seguinte mapa de navegação ilustra as componentes em que nos concentrámos:
O protótipo permite, assim, escolher o estado a partir de uma lista pré-definida, possibilitando a inserção de uma descrição para o mesmo. Esta descrição pode ser adicionada/alterada posteriormente (sem a necessidade de alterar o estado).
É permitido ainda manter uma lista de contactos (um dos quais pré-definido como um 2º utilizador Moods), disponibilizando as comuns funções de adicionar/editar/remover contactos, permitindo adicionalmente efectuar uma chamada para o contacto seleccionado. Para cada contacto é possível definir um nome, nº de telefone, endereço de e-mail e URL (mais tarde serão adicionados outros 4 números).
Relativamente a esse utilizador Moods, que se encontra no topo da lista para mais fácil visualização, é possível observar directamente o seu estado actual. A actualização desse estado é feita manualmente.
O estado actual do próprio utilizador pode ser visualizado ao topo, na barra de tarefas do Android, a qual (quando expandida) permite visualizar ainda a descrição do estado (se existente), e a hora a que este foi alterado. Por fim, nesse mesmo local existe um ícon que serve de atalho para a alteração do estado.
Não está incluída (embora parcialmente implementada) a funcionalidade de visualizar a descrição do estado do 2º utilizador Moods.
Existem alguns “pop-ups” para a confirmação de acções, ou notificação ao utilizador de problemas.
Nos posts seguintes será possível encontrar mais informação (e mais detalhada) sobre estes processos, e ainda uma cópia da nossa apresentação :~)
Uma simples expressão que representa o elemento chave de toda a construção dinâmica das nossas listas. Assim podemos gerar dinamicamente a nossa lista telefónica de acordo com o número total de contactos que vem da BD, uma vez que todos os elementos que compõem um ecrã têm obrigatoriamente de ter (passo a redundância) id’s diferentes. Tal como mostraremos mais abaixo, cada ecrã possui vários elementos, como as imagens dos estados, os botões de contactos, as caixas de texto com o nome do contacto e o seu respectivo número, e umas caixas de texto utilizadas no alinhamento de todos os elementos no ecrã. Existem vários tipos de layout no android para criar ecrãs, sendo que o tipo de layout define a forma como os elementos são colocados no ecrã. Na lista telefónica e na lista de estados utilizámos o RelativeLayout, que coloca os elementos no ecrã com base em relações posicionais entre eles. Se temos, por exemplo, 2 botões na horizontal, é necessário indicar que o botão 2 está à esquerda do botão 1.
A seguinte imagem representa o esquema do layout referido acima, elaborado numa das sessões de trabalho.
Aqui é possível ver as hierarquias de layouts utilizadas por nós. Todo o ecrã tem como base um LinearLayout. Dentro deste existe um ScrollView que permite o movimento em scroll do ecrã. Posteriormente dentro deste está outro LinearLayout que contém todos os elementos referidos no início com as suas respectivas dependências.
Como se vê na imagem, destacámos as caixas que alinham os elementos com cores diferentes, para se perceber a estratégia utilizada.
Nas imagens seguintes mostraremos o layout actual da lista telefónica ainda sem a ligação à BD, mas gerada dinamicamente e da actual lista de estados. Mostraremos também uma imagem do scroll da lista telefónica onde a barra lateral aparece. Esta barra aparece quando há movimento e desaparece com um fade out quando o movimento cessa.
Os modelos anteriormente apresentados para as bases de dados assentavam na ideia de colocar o protótipo a funcionar, sem preocupações com questões futuras. Com efeito, assumiam algumas limitações (já mencionadas), e não apresentavam todos os campos possíveis (uma vez que estes correspondem a funcionalidades que não vão constar do protótipo).
Ainda assim, fomos aconselhados pelos orientadores a resolver já esta questão da BD, criando algo final e que sirva para a seguintes fase de desenvolvimento. Este novo modelo pretendia, essencialmente, manter duas BDs idênticas (para ambos os lados – Android e Web), para além de acrescentar suporte para as funcionalidades que serão implementadas futuramente.
A construção desse novo modelo, apresentado já de seguida, contou com a preciosa colaboração dos orientadores, aos quais gostaríamos desde já de agradecer =)
Como acima referido, deixa de existir distinção entre o Android e a Web na BD relativamente à estrutura, estando as diferenças limitadas a campos que apenas se aplicam a um ou outro caso.
De forma idêntica ao que acontecia anteriormente, a tabela MOODS armazena os dados relativos aos utilizadores do serviço Moods. Cada utilizador deixa de ser identificado pelo número de telefone, passando a possuir um identificador único: um Username (campo ID_Moods).
Os campos “ID_Moods” e “Password_” são necessários para a autenticação do utilizador (e gerados através do registo deste no serviço Moods). O campo “Email_” permitirá, por exemplo, associar o endereço de e-mail do Sapo para permitir a expansão de futuros serviços. O campo “Name” representa o nome que o utilizador atribui a si mesmo.
Para que um utilizador possa dizer que o número de telefone X é seu, terá de o confirmar de forma segura. Para tal, será desenvolvido um processo no Android que, após introdução do Username e Password, envia o número do SIM que está activo no telemóvel para o servidor. A partir deste momento o número está validado, e o campo “SIM_isValid” terá o valor “true”.
Uma vez que, no Android, o próprio utilizador desse dispositivo Android é também um utilizador Moods, ele também constará dessa lista. Isto significa que, se pretendermos apresentar todos os contactos desse utilizador, o seu próprio contacto será um deles. Uma vez que isto não faz sentido do lado do dispositivo, existe um campo denominado “isMine” que permite esconder da lista telefónica o próprio utilizador.
Por fim, o campo “StatusChanged” permite dizer há quanto tempo foi comutado o estado pela última vez – de forma idêntica ao que já acontecia anteriormente.
Relativamente à tabela STATUS, o anterior campo “Visible” passa a ter o nome de “isSystem” (estados que o utilizador não pode seleccionar), e o novo campo “Visible” representa os estados que o utilizador escolhe ver apresentados (uma das funcionalidades que pretendemos implementar apenas após o protótipo).
São agora introduzidas novas tabelas:
NUMBERS armazena todos os números de telefone do utilizador (do lado Android), e todos os números de todas as listas (do lado Web). O campo “ID_Moods” aqui presente indica se o número X pertence a um utilizador do serviço Moods, ou se é apenas um “contacto normal”.
CONTACTS armazena todos os dados que um telemóvel comum mantém sobre os diversos contactos: o “Alias” (nome que nós atribuímos a outra pessoa), e-mail, URL e uma fotografia escolhida por nós. O campo “ID_Moods” desta tabela indica de que lista telefónica é o contacto. Uma vez que do lado Web estarão todos os contactos de todos os utilizadores, é necessário saber que contactos pertencem a que lista.
TYPE permite relacionar um número com um contacto, adicionando (por meio dos valores armazenados na tabela LABELS) o tipo de número a que se refere. Assim, para um mesmo contacto podemos definir diversos números de telefone com diferentes Labels (“Móvel”, “Fixo”, “Trabalho”, “Fax”, “Outro”), sendo que cada contacto apenas pode incluir um número por label.
GROUPS lista os grupos de contactos (i.e. a forma como podemos catalogar os números). Por defeito, estão criados três grupos (“Família”, “Amigos” e “Trabalho”), podendo o utilizador alterar a designação desses grupos, remover um ou mais deles, ou ainda acrescentar novos grupos (e definir de igual forma as suas designações). Estas funcionalidades não farão parte do protótipo (áreas da BD que não serão utilizadas).
Será necessário efectuar alguns testes no final da semana para verificar se esta BD apresenta algum problema. Pelo menos até lá, será esta a BD que constará do nosso protótipo.
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!
Pesados os compromissos, apresentamos os modelos lógico e físico das duas bases de dados (a do Android e a que se encontra no servidor Web).
Algumas considerações (para além das que se encontram mencionadas no próprio PDF):
- O número de telefone é a chave primária da tabela USERS, pelo que cada número de telefone representa uma identidade única. Possíveis problemas como os números de empresas (que possuem extensões para um mesmo número) são, assim, ignorados.
- O nome de um utilizador é, em última instância, o nome que cada contacto dá a esse utilizador. Por outras palavras, duas pessoas podem ter o mesmo contacto nas suas listas telefónicas, mas descrevê-lo de formas distintas. Desta forma, é a propriedade “Alias”, da auto-relação com a tabela USERS, que define o nome que cada utilizador atribui aos contactos da sua lista.
- O campo “Visible”, da tabela STATUS no Android, representa os estados que o utilizador pode seleccionar (um dos sete que já apresentámos noutro post). No entanto, existem três estados adicionais: “em chamada” (comutado automaticamente caso se efectue uma chamada, regressando ao estado anterior no final da mesma); “em actualização” (sinaliza que o estado está a ser pedido ao servidor); “não disponível” (sinaliza que não foi possível obter o estado do utilizador).
[edit 13.04.2008 16:29]
Acrescentado o campo que permite saber há quanto tempo cada utilizador comutou o estado pela última vez. Outros possíveis ajustes para breve.
Bem, de uma maneira geral o projecto tem evoluído bastante desde o início. Neste caso falamos também do ambiente gráfico da aplicação. Já há várias coisas a funcionar e outras quase quase quase, mas mesmo quase a funcionar. Mostramos então uma imagem de uma versão do layout da lista telefónica, já implementada no emulador, onde se pretende testar as transparências, mudança de wallpaper e também os comportamentos dos botões criados por nós.
Continua o desenvolvimento do protótipo, avançando agora para a integração de um layout mais composto, e para uma comunicação mais elaborada com a BD Web. Relativamente a esta última, os métodos simples que estão a funcionar baseiam-se em ASP+SQL; uma vez que o servidor onde será implementada toda a parte Web é baseado em PHP+MySQL, toda essa parte está a ser também re-escrita.
Dada a semelhança entre os métodos utilizados para comunicar com a BD SQLite do Android, e os que são utilizados para comunicar com a BD MySQL no servidor, ambas as BDs terão uma estrutura muito semelhante. Isso permitirá manter alguma coerência entre o que se passa dos dois lados, até porque foi necessário dividir competências dentro do grupo para o desenvolvimento das diferentes componentes (minimizando assim possíveis problemas de integração).
Até à próxima Terça-Feira, a aplicação pretende adicionar: a funcionalidade de introdução de descrição do estado; uma BD ligeiramente revista, sendo o ID o número de telefone (vamos assumir que cada número corresponde a uma identidade distinta); o sistema de comunicação com a BD Web via PHP/MySQL, sendo os elementos de dados compostos por ficheiros XML; uma interacção para a escolha de contactos/estados baseada em botões, com possibilidade de manipular qualquer elemento do layout (excepto a barra superior do Android).
Existem outras ideias que, dependendo do progresso de desenvolvimento, poderão ser incluídas ainda esta semana, mas vamos concentrar para já esforços no sentido de cumprir os objectivos acima descritos.
Até breve!
