Eis uma luz ao fundo do túnel

Depois de muito tempo de estudo gráfico, experiências e soluções apresentadas, chegámos à fase final da interface gráfica da nossa aplicação. Optámos por um grafismo minimalista e simples, mas que permitisse ao utilizador uma fácil e imediata identificação de todos os elementos. Nesta fase tornou-se claro o facto de termos de encontrar uma interface que conseguisse coexistir com a interface do próprio android, mantendo assim a consistência gráfica em todos os ecrãs e entre todos os elementos. Visto não conseguirmos alterar a cor do highlight dos elementos do android, mais propriamente o laranja, decidimos alterar todo o grafismo desenvolvido anteriormente.

Uma parte da aplicação definitivamente abandonada, foi a implementação de animações. O leque de opções no que toca à implementação de animações no android, não nos permitiria fazer aquilo que previmos inicialmente, o que nos levou a pôr de lado essa parte da aplicação.

Mostramos então algumas imagens da nova interface gráfica da nossa aplicação, encarada já como a versão final.

Imagem do menu principal da aplicação, onde se pode observar as quatro opções, das quais está “highlighted” a lista telefónica, tal como indica a descrição do próprio menu. No canto superior esquerdo é também possível ver o ícone correspondente ao estado seleccionado.

Imagem da lista de contactos. É possível observar os contactos que não têm o serviço Moods, acompanhados pelo ícone cinzento, e os contactos que têm o serviço com o ícone do seu estado actual. De notar também o highlight laranja semelhante ao do android, de maneira a manter a consistência visual com o sistema operativo.

Imagem da lista estados onde se pode ver os ícones finais. De notar as diferenças significativas com a versão anterior.

Ainda uma imagem da lista de estados, mas neste caso do momento em que se escolhe um estado. Tal como na versão anterior aparece um popup a perguntar se prendemos inserir uma descrição, mas com um pormenor, que é um efeito de rollover na barra superior mostrando o ícone do estado escolhido, bem como o seu nome. Este desaparece utilizando o mesmo efeito, permanecendo apenas o ícone.

Esta imagem mostra uma funcionalidade já anteriormente demonstrada, mas alterada com os elementos da nova interface gráfica.

10

Nem parece, mas passaram dez dias desde as últimas notícias publicadas sobre o projecto! Mais vale tarde do que nunca, e como tal aqui ficam os últimos pormenores sobre o trabalho desenvolvido, e ponto de situação.

Aproxima-se a data para a realização dos testes, e como tal estamos a ultimar a versão que irá ser testada. Importa referir que, apesar disso, ainda será produzido trabalho até ao prazo final.

O novo estilo gráfico para a aplicação do Android, muito debatido e refinado, encontra-se concluído (num outro post serão mostrados todos os elementos gráficos produzidos). Os diversos elementos (ícones, o novo menu, os novos botões e listas, ícones para o topo, ícon para o drop-down, background) encontram-se já implementados, faltando apenas incluir os ícones que irão acompanhar a descrição de cada elemento dos diversos menus.
Os ecrãs existentes estão a ser reformulados, e em alguns deles incluídos novos elementos de interacção tais como caixas drop-down e checkboxes.

Quanto à aplicação, foi desenvolvido e concluído um extenso trabalho, com resultados muito positivos.

Todas as funções necessárias, previamente definidas, foram trabalhadas/refinadas ao longo das passadas duas semanas, e todas programadas/implementadas do lado Web. Foram necessárias ainda novas funções, para o Android, que de igual modo se encontram já implementadas.
Uma vez que nos encontramos a desenvolver um Website, que necessita também ele de comunicar com a BD (e através dos mesmos recursos de que o Android dispõe), foram também escritas funções especialmente nesse sentido. Ainda estão a ser desenvolvidas algumas delas, um trabalho mais extenso do que inicialmente previsto (devido ao grande número, e à quantidade de lógica envolvida em cada uma delas).

Do lado do Android, e ainda respeitante à comunicação com o servidor, foram implementados métodos dinâmicos para acesso a essas funções, numa perspectiva totalmente modular. Estes diversos “apêndices” permitem à aplicação em si comunicar com o servidor e com a BD interna que se encontra no Android. A forma de implementação permite comunicar da mesma forma para qualquer tipo de função. Foram tidos vários cuidados (após aprendizagem de algumas técnicas) para libertar o máximo de recursos possíveis na comunicação com a BD.

As funções do lado do Android foram totalmente re-escritas para multi-utilizador. No entanto, não foram ainda implementadas todas as que assegurarão uma total sincronização entre o dispositivo e o servidor web. Este processo, embora adiado, não foi completamente colocado de parte, sendo que foi até já discutida a provável solução de implementação.

O sistema de autenticação (login) encontra-se implementado, sem o qual o utilizador se encontra impedido de utilizar a aplicação. Os dados de autenticação são obtidos através do registo no website. Este processo verifica correctamente o número de telefone (cartão SIM) do dispositivo, e faz a sincronização dos dados de registo.

A alteração do estado/descrição foi ligeiramente modificada, para minimizar o número de comunicações feitas com o servidor (uma vez que estas acarretam um delay). Para além disso, a alteração do estado possui agora bidireccionalidade, para que seja possível ordenar a lista de estados pelos mais utilizados - funcionalidade que também se encontra implementada.
Ainda respeitante a esta parte, está também concluído o processo de filtragem de estados (através do qual o utilizador poderá decidir que estados estão disponíveis para escolha).

A lista telefónica encontra-se preparada para multi-utilizador, sendo que ao adicionar um contacto, é verificado se o número associado pertence a outro utilizador. Se tal se verificar, é automaticamente descarregado o estado desse contacto (apesar de termos um sistema que contempla gestão de permissões, estas encontram-se abertas, por defeito, nesta fase).
O estado passa a ser actualizado a cada vez que é aberta a lista telefónica, e o bug que existia no protótipo, e que impedia mais de 3 actualizações, encontra-se resolvido.

Houve também algum trabalho sobre a gestão de ecrãs em memória, afim de garantir que cada ecrã que já não é necessário é correctamente “destruído”. Isto permite-nos um maior controle sobre o funcionamento da aplicação, e libertar o máximo de recursos possível. Foi possível também resolver a questão de atribuição do “focus” de um botão, permitindo por exemplo que após edição de um contacto que está no fundo da lista, esta seja mostrada de novo com o cursor nesse mesmo elemento (evitando que o utilizador tivesse de navegar sobre todos os contactos de novo).

Por implementar, durante os próximos dias, estão os ecrãs de gestão de grupos, filtragem de contactos por estado ou grupo, e a funcionalidade de bloquear contactos. Estes foram considerados aspectos menos relevantes, e como tal adiados algum tempo. A função de bloquear contactos nem era, inicialmente, alvo de desenvolvimento; no entanto, e como tentámos preparar a BD, o mais possível, para implementação de soluções futuras, decidimos acrescentar já esta funcionalidade.

Embora a sincronização, e questões adicionais já mencionadas (processamento com o servidor em paralelo, etc.), não sejam provavelmente incluídas nesta versão beta, todas as restantes funcionalidades e todos os ecrãs, com um layout totalmente revisto, estarão seguramente implementadas na versão que apresentaremos.

Relativamente a avanços no desenvolvimento do website, também será colocado um post mais pormenorizado.

Mais notícias para breve!

Ponto de situação (grafismo)

Da mesma maneira como o resto do projecto tem evoluído, também o grafismo do mesmo tem sofrido uma evolução através de alterações significativas na metáfora gráfica. Em seguida serão mostradas imagens que revelam os avanços e experiências nesse campo, sendo que algumas tenham sido abandonadas.

Menu Principal:

- Evolução do menu principal, com inspiração no estilo PSP da Sony.

- Experiências com highlights.

- Última versão do menu, mais próxima do que pretendemos.

Estados:

- Evolução de alguns estados anteriores, mas já abandonados, devido à mudança de metáfora gráfica.

- Estados já com a metáfora gráfica pretendida, mas ainda não ainda completamente desenvolvidos.

Ponto de situação (funcionamento)

Para tornar a nossa aplicação multi-utilizador, é necessário desenvolver uma série de módulos:

- Projectar todas as funções que são necessárias para que um cliente (Android ou Website) comunique com o sistema de gestão da BD Web. Ter o cuidado de desenhar algo o mais compatível possível com WebServices (ainda que a criação destes não esteja planeada até à data limite de desenvolvimento do projecto). Este trabalho foi concluído durante esta semana:

Lista das Funções

- Implementar cada uma das funções no servidor, em PHP, segundo as regras definidas em cima. Três das funções encontram-se implementadas (1a, 1b e 2), sendo que as restantes serão programadas durante a próxima semana. Serão ainda testadas através dos dois tipos de cliente: Android e Website.

- Desenvolver uma classe, no Android, capaz de comunicar com cada uma das funções, passando os parâmetros necessários e lendo de seguida o XML respectivo (para as funções que devolvem um XML). Este processo deve ter em conta dois aspectos essenciais: deve ser reutilizável (uma vez definidos os URLs de input/output, todo o restante processo deve ser idêntico, independentemente do nº e tipo de campos devolvidos, ou nº e tipo de parâmetros passados); deve armazenar os dados lidos, de cada XML, da forma mais eficiente possível a nível de consumo de memória.
Este processo estava a criar imensa confusão uma vez que desconhecíamos por completo o que é na verdade programar em linguagens orientadas a objectos. Após algumas sessões de tortura ao Prof. Carlos Santos, conseguimos obter informação suficiente para construir uma solução viável, e com a qual nos encontramos bastante satisfeitos, pois cumpre plenamente os dois aspectos acima referidos. Este processo encontra-se, portanto, concluído.

- Actualizar todas as funções, no Android, que comunicam com a sua BD interna. Este processo parte do novo fluxograma (revisto) que estamos a construir, uma vez que é agora bem mais claro como de facto implementar funcionalidades que no início do processo de desenvolvimento definimos. Em primeiro lugar é necessário proceder à listagem de cada uma das funções; depois, definir todos os procedimentos envolvidos (pseudo-código); por fim, proceder à implementação (em Java). Algumas destas funções encontram-se finalizadas, nomeadamente as que possibilitam a gestão de contactos, e as que permitem a autenticação do utilizador. No entanto existem ainda bastantes funções por programar, processo que será continuado (e expectavelmente concluído) durante a próxima semana.

- Desenvolver uma rotina que permita copiar os contactos que se encontram no Android (e/ou cartão SIM) para a BD da nossa aplicação. Este é outro objectivo que tentaremos atingir durante a próxima semana.

- Assegurar todo um processo de sincronização entre a BD da aplicação Android e a BD Web. O desenvolvimento deste módulo apenas será iniciado, na melhor das hipóteses, daqui a uma semana.

Um módulo adicional permitirá garantir uma melhoria no processo de interacção com o utilizador:

- Garantir que, cada vez que existe comunicação com o servidor Web, esse processo é executado em paralelo, para que a resposta seja imediata e para que o utilizador possua o controlo da aplicação. Considerando todos os aspectos referidos, somados ao facto de que somos forçados a dispender de alguns dias para a fase de testes, este processo poderá ser adiado para o 4º módulo.

Finalmente, alguns métodos permitirão assegurar funcionalidades específicas:

- Executar código quando o Android é ligado/desligado, permitindo (por exemplo) mostrar o estado actual no topo do ecrã ao ligar o telemóvel, ou comutar o estado para desligado quando essa operação é efectuada.

- Executar código consoante alteração de certos parâmetros do Android, por exemplo, saber quando está a ser efectuada uma chamada para comutar automaticamente o estado para “Em chamada”.

Ambos os processos, pela mesma razão anteriormente descrita, poderão ser remetidos para o 4º módulo de desenvolvimento.

Até ao final da próxima semana serão ainda publicados todos os documentos actualizados, em especial o fluxograma, modelo da BD (que necessita de crescentes modificações/correcções), e mapa de navegação (com ajustes do que será desenvolvido).

Durante os próximos dias será também descrito o ponto de situação referente às duas restantes áreas de desenvolvimento: layout do Android, e layout/estrutura do Website.

Especificação da fase de testes

Relativamente à fase de testes, foi necessário sub-dividir as áreas que serão desenvolvidas em dois grupos: a aplicação do Android, e o Website. Será fornecido um guião de procedimentos, que incluirão o registo no Website e posterior login na aplicação do Android, bem como a realização de diversas operações (alterar o estado; criar, editar, remover contactos; etc.).

Quanto à aplicação, pretendemos efectuar os seguintes tipos de teste:

- Funcionalidade: para todas as áreas desenvolvidas, uma vez que a funcionalidade é o objectivo principal deste projecto (proof of concept).

- Conteúdos: pretendemos focar a atenção nos menus e caixas de diálogo, em particular na legibilidade (caso seja possível mostrar o emulador em dimensões semelhantes às de um telemóvel) e sintaxe (adequada a cada operação).

- Design: testar essencialmente a integração dos itens que criámos com o layout do sistema operativo (elementos como os menus, ou a barra superior, cujo design não pode ser alterado).

- Usabilidade: testar a aplicação relativamente à eficácia, eficiência e satisfação, segundo as heurísticas de Nielsen, embora não muito detalhadamente (o suporte não é o final, e o próprio sistema operativo ainda está em fase beta). Por outras palavras, esperamos que sejam detectados muitos erros de usabilidade que não tenham necessariamente relação directa com a aplicação em si, mas com a utilização do emulador/sistema operativo.

Não vamos realizar testes de: segurança (novamente, e porque se trata de um proof of concept, a camada de segurança não será sequer alvo de desenvolvimento); compatibilidade (apenas existe uma plataforma disponível, que é o emulador); acessibilidade (de novo, questões de acessibilidade não serão alvo de desenvolvimento, pelo que não faz sentido efectuar testes nesse sentido).

Quanto ao Website, os seguintes testes serão utilizados:

- Funcionalidade: de forma semelhante ao descrito anteriormente, e porque parte do funcionamento da aplicação requer a manutenção de um registo, é importante localizar e corrigir bugs que impeçam a execução das funcionalidades básicas.

- Compatibilidade: o Website será testado em três browsers (Internet Explorer, Firefox e browser do Android), e resoluções de 1024×768 (para a qual o Website estará optimizado, para navegação num PC) e 320×480 para o browser do Android.

- Conteúdos: maior detalhe para a descrição do produto e secção de registo.

- Design: manter alguma coerência com a marca, e consistência ao longo das diversas páginas do Website.

- Usabilidade: novamente serão verificadas as diversas heurísticas de Nielsen, com mais detalhe do que relativamente à aplicação (uma vez que o Website será apresentado num suporte final).

- Acessibilidade: para que o Website esteja preparado para a utilização por um leque o mais alargado possível de utilizadores com múltiplas competências, iremos recorrer aos mecanismos de teste do W3C.

Pela mesma razão acima referida, não serão efectuados testes de segurança.

Tendo em conta as técnicas de teste a utilizar, nos testes de funcionalidade, conteúdos e usabilidade iremos recorrer ao teste integrado (através do guião que cada utilizador irá executar). Adicionalmente, e para os testes de funcionalidade, iremos utilizar também a técnica de unit testing, da qual participarão todos os elementos do grupo; este método será o mesmo para os restantes testes não mencionados.

Em relação às técnicas de recolha de dados, iremos utilizar gravação audio/vídeo, grelhas de registo, thinking-aloud protocol e entrevista no final, para os testes de funcionalidade, conteúdos e usabilidade. Para os restantes tipos de teste apenas serão preenchidas as grelhas de registo.

Os cinco participantes pré-seleccionados são alunos do curso de Novas Tecnologias da Comunicação, que não tiveram ou terão qualquer contacto com a aplicação até à data da primeira sessão de testes. Estes são: Carla Duarte, Paula Carvalho, Renato Costa, Rui Silva, e Sérgio Amaral.

Os testes serão agendados para uma data próxima do final desta fase, para permitir o maior tempo possível para o desenvolvimento, embora apresentando antecedência suficiente para que possam ser documentados. Os dias seleccionados, para as três sessões com os cinco utilizadores-teste, são 31 de Maio e 1 de Junho (com maior concentração horária), podendo extender-se para os dois dias seguintes caso surja algum imprevisto. Os testes realizados pelos elementos do grupo serão realizados nos dias 29 e 30 de Maio, para eventuais correcções de última hora, e alguma previsão de resultados que serão obtidos durante as sessões com utilizadores-teste.

Finalmente, aqui ficam os mapas de navegação demarcados nas zonas que serão testadas:

Mapa de Navegação - Instalação

Mapa de Navegação - Funcionamento

Arrays e o Java

Os arrays, em especial os bidimensionais, dão muito jeito para armazenar informação - especialmente quando existem vários registos que contêm o mesmo tipo de dados. Apesar da limitação que apresentam relativamente à sua dimensão (que é fixa, a partir do momento em que um array é criado), fazemos deles uso regular.

Por curiosidade, investigámos um pouco mais sobre o espaço em memória que é reservado (gasto) assim que é criado um array, mesmo que este se encontre “vazio”, e chegámos a algumas conclusões interessantes.

Em Java, a criação de um array de valores inteiros implica um overhead de 16 bytes (8 deles definem o objecto). Para arrays de alguma dimensão, este overhead representa uma percentagem baixa do espaço total reservado, não sendo por isso um factor relevante. No entanto, e porque o Java não suporta directamente a criação de arrays de múltipla dimensão, um array bidimensional é no fundo um array de um array. Como tal, para um array de dimensões [i][j], cada array [j] representa um objecto separado, que implica (para o caso de valores inteiros) o overhead de 16 bytes.

Um dos exemplos que encontrámos compara um array de apenas uma dimensão int[256] com um array bidimensional int[128][2]. Embora ambos apresentem o mesmo espaço disponível para armazenamento, efectivamente em memória são gastos apenas 1040 bytes para o primeiro, mas 3600 bytes para o segundo (2.46x mais espaço ocupado!).

Muitos dos arrays que utilizamos armazenam valores do tipo string, de dimensão de 40 bytes (comparado com apenas 4 bytes para um inteiro); para além disso, o overhead sobe para 24 bytes. Para um exemplo idêntico - string[256] e string[128][2] - seriam necessários respectivamente 10246 e 18456 bytes, uma proporção inferior (”apenas” 0.8x maior), dado que o overhead é bastante inferior ao espaço necessário para armazenar a string.

Não é difícil imaginar que será fácil atingir arrays do tipo string na ordem dos megabytes (um array vazio de dimensão [1000][50] ocupa cerca de 2MB), o que num telemóvel representa um potencial risco. Por uma questão de perspectiva, o iPhone possui apenas 128MB de RAM, sendo que cerca de 11MB são reservados para a placa gráfica, e uma boa parte da memória restante é utilizada pelo OS e as aplicações comuns que o telemóvel necessita de ter a funcionar.

Embora no nosso caso não seja necessário armazenar grandes volumes de informação, esta é uma questão pertinente e interessante. Como exemplo, estimamos necessitar de cerca de 700KB para armazenar temporariamente os dados de 1000 contactos telefónicos, caso o utilizador deseje restaurar toda a informação em backup do lado Web. Tipicamente os arrays que utilizamos andarão na ordem dos 150~200KB, para 1000 contactos.

Arranque da versão beta e objectivos

Inicia-se agora o terceiro módulo de desenvolvimento (versão beta e testes), que continua precisamente no ponto em que terminou a construção do protótipo apresentado. A nossa estratégia vai continuar a passar pela divisão das diversas componentes a desenvolver em quatro grupos principais; relembramos os quatro grupos desenvolvidos: 1 - Layout; 2 - Aplicação; 3 - Comunicação; 4 - Servidor Web.

Contámos com a ajuda dos orientadores e do Benjamin Junior para decidir que áreas devem ser focadas com mais detalhe nesta fase, tendo sido discutidos diversos aspectos, com especial destaque para as soluções adoptadas no protótipo, avaliando o que deve ser modificado e o que pode ser reutilizado.

A este respeito, foi decidido que a forma utilizada pela nossa aplicação na comunicação com o servidor é uma opção válida, possibilitando perfeitamente uma migração futura para algo baseado em webservices (que assegurariam o suporte para um eventual elevado número de utilizadores, bem como a necessária camada de segurança para a informação transmitida e armazenada). Estaremos atentos a novidades acerca dos métodos de envio via POST (actualmente utilizado o URL para envio de informação), mas continuaremos a fazer uso de ficheiros XML, criados no servidor, para a leitura.

Isto significa que, relativamente ao módulo anterior, é eliminado um dos quatro grupos de desenvolvimento (3º Grupo - Comunicação). Como tal, existem agora recursos humanos para o desenvolvimento de um pequeno e simples website, que inicialmente optámos por remeter à fase de manutenção e suporte (dada a grande incerteza acerca dos avanços que seriam conseguidos). Este website assegurará os meios para que um utilizador efectue o seu registo (sendo esta a única forma de criar uma conta Moods), obtendo um nome de utilizador (ID_Moods) e escolhendo uma palavra passe, que serão utilizados no Android para a validação desse utilizador. Adicionalmente, o website pretende garantir todas as funcionalidades que se encontram presentes no Android (manter uma lista de contactos, alterar o estado, inserir uma descrição para o estado, etc.).

Este website será considerado como um dispositivo Android, fazendo uso das mesmas funções para atingir os mesmos objectivos. Serão ainda desenvolvidas soluções para que todo o processo funcione de forma assíncrona, sendo a informação armazenada na BD Web considerada o ponto central. Estes processos farão parte do 4º Grupo de desenvolvimento (Servidor Web). Serão desenvolvidas ainda funções adicionais para suportar múltiplos utilizadores Moods (o protótipo estava limitado a dois utilizadores).

Relativamente à aplicação presente no Android, serão modificados alguns aspectos funcionais para melhorar a interacção com o utilizador, nomeadamente no que diz respeito a tempos de espera, na comunicação com o servidor. Serão assegurados métodos para garantir que alterações efectuadas no dispositivo (por exemplo, a alteração dos dados de um contacto) sejam reflectidas na BD Web, para que esta possa servir como backup de toda a informação. De forma idêntica ao que acontece do lado Web, será adicionado o suporte para múltiplos utilizadores Moods.

O novo modelo para o registo de um utilizador Moods obriga à criação de um novo item, no menu das preferências da aplicação (para que o utilizador se possa autenticar). Esta alteração encontra-se reflectida na nova versão do Mapa de Navegação, apresentada no final deste post.

Os novos ecrãs a criar exigirão um continuado desenvolvimento da componente de interface, sendo que alguns dos ecrãs existentes necessitarão de ser também modificados, em virtude das novas funcionalidades a acrescentar. Para além disso pretendemos acrescentar animações em alguns dos elementos, e ainda animações na transição entre ecrãs; este segundo item já havia sido investigado durante a fase anterior, ainda sem resultados positivos.

O suporte para múltiplos utilizadores, a área de registo do Website e a autenticação no cliente Android, são objectivos que pretendemos cumprir até ao final da próxima semana. Nessa altura serão definidas novas metas, consoante o trabalho que for possível desenvolver em conjunto com estes objectivos primários.

Este “segundo protótipo” será apresentado durante a cerimónia de inauguração do laboratório do Sapo, no dia 21 de Maio.

Por fim, apresentamos o Mapa de Navegação revisto, actualizado e demarcado cromaticamente nas áreas que serão desenvolvidas durante este módulo (nota: a pré-instalação não se encontra incluída, pois nenhum dos seus componentes será desenvolvido nesta fase):

Mapa de Navegação - Versão 3 - Instalação

Mapa de Navegação - Versão 3 - Funcionamento

E ainda o modelo da BD ligeiramente revisto, com suporte para algumas funcionalidades novas (evita a transferência de informação desnecessária para o Android, e possibilita ordenar a lista de estados pelos que são usados com maior frequência):

Base de Dados - Versão 5

[edit] - segundo indicações dadas pela prof. Margarida Almeida, editamos este post para referir que o desenvolvimento completo das áreas marcadas no mapa de navegação está dependente da implementação do processo de comunicação assíncrona (que é neste momento o problema com maior prioridade a ser resolvido). Poderemos ter de proceder a alguns ajustes, consoante os resultados obtidos durante as próximas duas semanas de desenvolvimento.

Comunicação

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!

Últimas informações acerca do protótipo

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.

Base de Dados (Versão 4)

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 :~)

De novo a BD…

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 =)

Base de Dados (Versão 3)

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.