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.

Apresentação

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.

Moodar o estado!

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.

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

idbotao = (i-1) * 8 + 1;

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.

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.

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!

Bases de dados

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

Bases de dados (Sapo Moods)

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.

Bases de dados, versão 2 (Sapo Moods)