Website: Desenvolvimentos

Na senda dos posts anteriores, é também importante referir como vão as coisas com o website.

Há cerca de 10 dias, noutro post tornámos pública a nossa decisão de avançar com o website. Por essa altura, uma versão do layout ( 1024×768 ) já se encontrava aplicada, totalmente em tabelas.

Desde esse post até ao dia de hoje, muitas alterações ocorreram tanto no que refere ao website, como à aplicação e ao design, e mesmo aos nossos locais de trabalho.

No relativo ao website, da versão em tabelas a 1024 progrediu-se para uma versão a 800×600 totalmente baseada em CSS, utilizando php.

A versão antiga pode ser vista neste link , e a nova versão está colocada neste link.

Existiram também mudanças no layout: o menu com ícones deixou de existir, passando a ser apenas textual; o terceiro separador à direita foi alterado para não induzir os utilizadores no erro de pensar que seria um botão, tal comos os outros 2 em cima; todas as páginas além da home deixam de ter este separador e passam a contar com uma versão mais expandida para texto.

Escolhemos também a tecnologia a aplicar para retirar a informação dos XMLs a ser criados pelas funções: o SimpleXML, que vem integrado com o PHP, tornou-se uma solução válida, e está já aplicado em várias secções do nosso website (a interacção não é visível para o utilizador comum).

No entanto, foi-nos sugerido pelos nossos orientadores a utilização do Spry (uma framework para AJAX que vem incluída nas últimas versões do Adobe Dreamweaver) como sendo uma opção viável para as secções com maior interacção com os XMLs (as secções de contactos e grupos contém muita informação a retirar destes).

No último post acerca do website, indicámos a nossa intenção de produzir todo o website até à entrega da versão beta, tendo como prioridade as seccções de registo e download, e criando toda a secção de gestão (similar à aplicação Android) em seguimento.

Ainda é nossa intenção completar o website, mas tendo em conta alguns atrasos a que foi sendo sujeito, tanto a nível de layout como a nível de programação, ao escrever este post o website dispõe de uma homepage, registo, download e sistema de login/logout completamente funcionais, com todas as verificações e preparações associadas finalizadas, sendo sujeitas apenas a ligeiros melhoramentos caso necessário.

Visto que o planeamento dos nossos testes está agendado de forma a começar amanhã, estas secções serão as únicas a ser testadas. Isto não invalida que, no entanto, tanto o website como as funções continuem a ser desenvolvidos tendo em conta a entrega da versão beta. Simplesmente retira mais algum tempo de desenvolvimento a ambos.

Apesar disto, comprometemo-nos a desenvolver o máximo possível em todas as frentes até dia 6, de forma a chegar à apresentação da versão beta com a aplicação e o website o mais próximo possível das suas versões finais.

Aqui está o fluxograma do website, que certamente ainda será sujeito a modificações conforme necessário durante o restante desenvolvimento:

Próximo passo: Testes.

Fica aqui novamente o link do website, para uma mais fácil visualização:

Sapo Moods Web

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: Website

Com a continuação do trabalho no desenvolvimento do nosso projecto, torna-se importante esclarecer a questão do website.

No início deste projecto, o website foi encarado como uma apoio importante à aplicação Android, e foi planeado para ter as mesmas funcionalidades que a aplicação. Inclusivé, foram desenvolvidos diversos exemplos de layout para esse mesmo site web, com algumas das funcionalidades (primitivas) planeadas.

No entanto, com o decorrer do tempo, e com a passagem do primeiro módulo e consequente aumento de carga laboral a que nos sujeitámos, foi decisão do grupo dar ao website um menor destaque, ficando este apenas com um link para o download da aplicação, de forma a focar o nosso trabalho no desenvolvimento da aplicação. O restante projecto ficou adiado para Manutenção e Suporte, que poderia ser desenvolvido por nós ou qualquer outra equipa após a conclusão da aplicação em si.

Chegados ao terceiro módulo, e com diversas revoluções importantes quanto ao funcionamento da aplicação, uma decisão tornou-se especialmente importante: o facto de termos um login identificativo na aplicação exigia um registo web prévio e respectiva validação. O website tornou-se assim relevante novamente.

Claro que a nossa decisão poderia passar por adicionar apenas por adicionar um formulário de registo (ficando o website com download e registo). Após reuniões entre nós e os orientadores, decidimos apostar no construção de um website completamente adequado à aplicação Android.

As prioridades, claro, continuam a ser ter um sistema de registo e uma seccção para download, mas julgámos ser capazes de desenvolver o website completo dentro de uma linha temporal adequada à da disciplina, e portanto decidimos apostar na sua criação.

A nível de recursos humanos, já havia sido esclarecido num outro post que a nossa equipa de desenvolvimento se tinha dividido em quatro áreas (cada elemento trabalhando numa delas) para melhor aproveitamento dos recursos disponíveis. Visto que em conversa com os orientadores se considerou que a parte da comunicação estaria quase completa, pelo menos até à descoberta de novidades quanto ao HTTP POST no Android e aos webservices, um membro da equipa fica disponível para trabalhar no website.

É evidente que, visto que a tecnologia que adoptámos para a parte web é PHP, existirá uma importante ligação entre o desenvolvimento do website e o desenvolvimento das funções do lado do servidor, tal como é também importante que as funções sejam similares às do android, e que o layout seja adequado. Portanto, o trabalho da equipa continua a ser uno, apesar das deslocações de recursos terem tido alterações.

Passando para as novidades relativas ao website, ao longo desta última semana foram tomadas diversas decisões: foi criado um mapa de navegação e um fluxograma (ainda em construção) para guiar o desenvolvimento deste, o aspecto sofreu também alterações (foi abandonado todo o layout desenvolvido nos módulos anteriores em prol de um novo, desenvolvido também durante esta semana.

A primeira versão do layout foi criada para a resolução de 1024×768. Após uma visualização em diferentes monitores, considerámos que estaria demasiado grande, e portanto reduzimos o layout para 800×600.

A ter em conta que, visto que o foco primário deste website é, para além de publicitar o nosso serviço, permitir o registo e download da aplicação, existe uma certa relevância dada aos 3 botões à direita (como se nota pela cor mais forte). O símbolo da UA também está agora presente (havia sido negligenciado nas verões anteriores).

Foi também falada a criação de uma página ajustada às dimensões de um telemóvel, contendo apenas as funções de download e registo, por forma a optimizar o acesso ao website por parte destes dispositivos móveis, que nem sempre é o melhor.

Para visualizar o decorrer do desenvolvimento do website, basta aceder a este link. Sujeito a alterações sem aviso prévio.

Mapa de Navegação

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.