TRABALHO FINAL DE CURSO - INESC-ID

MobileREVS 15-10-2006
Figura 16 - Configuração hierárquica de ecrãs
Para que cada ecrã respeite as características acima indicadas e se insira num
grafo hierárquico de ecrãs conforme acabou de ser descrito, adoptou-se uma política de
transições baseada em criações e invocações (ver Figura 17) [IMG]. Segundo esta
política, cada ecrã é responsável pela criação dos seus subsequentes e, simultaneamente,
tem a capacidade de invocar o seu antecessor (e.g. para regressar ao ecrã anterior).
Figura 17 - Política de transições dos ecrãs
Na criação de um filho, o ecrã pai passa-lhe a sua referência que é depois
mantida pelo filho para realizar as invocações conforme necessário.
Seguindo esta metodologia de implementação de ecrãs o desenvolvimento da
interface mostra-se bastante adaptável a:
• Adição de novos ecrãs: caso se pretender adicionar um novo ecrã apenas é
necessário: (1) criar uma classe que herde as características do ecrã abstracto
MenuScreen e implemente a interface IMenuScreen; (2) definir os
métodos make() e commandAction() para, respectivamente, definir o
conteúdo e o comportamento desse ecrã; (3) criar um pequeno método no
ecrã pai que faça a criação e transição para o ecrã filho;
• Alteração de ecrãs existentes: as alterações na interface são localizadas, e
realizadas apenas na classe que representa o ecrã, mantendo-se o restante
código inalterável.
5.1.2. Comunicação
Outro dos aspectos importantes da comunicação é o recurso a threads no
contacto com os servidores nas fases de assinatura e submissão do voto. Esta decisão
prende-se essencialmente com questões de desempenho. Como o estabelecimento de
uma ligação é uma operação algo demorada, a utilização de threads permite que a
aplicação contacte diversos servidores em simultâneo, sem ter de esperar pela resposta
de um para passar ao próximo. Esta abordagem torna-se crítica em situações de falhas
na comunicação, já que o timeout da ligação induz um atraso significativo no processo
de votação.
Luis Costa, Nuno Santos 51