Preparação e configuração do protocolo de recolha
O primeiro passo na configuração de uma recolha corresponde à definição e configuração do estudo/projeto. Nesta fase, o investigador ou responsável terá de definir o nome do seu estudo e o tipo. Opcionalmente poderá definir o IP do MessageCollector e também do broker de ligação com o novo sistema de visualização do projeto VR2Market. Uma configuração possível encontra-se atribuída na Figura 6-17.
Figura 6-17 - Definição de um projeto.
No final desta fase, como foi abordado na subsecção anterior, o token do projeto é criado, podendo então o responsável partir para a definição dos grupos de aquisição onde poderá adicionar os elementos, correspondentes aos participantes.
Os nós correspondentes a dispositivos, ou participantes, com a aplicação VR-Unit podem-se associar ao
MessageCollector, onde ficam inseridos num grupo pertencente ao estudo configurado. Existem duas formas
de uma aplicação VR-Unit ficar associada a um VR-Remote, a primeira forma é por Bluetooth e a segunda por leitura de um código QR, ficando o método à escolha do investigador. Quando o responsável decide emparelhar por Bluetooth, será aberto um socket de Bluetooth entre as duas aplicações, de modo a trocarem informações necessárias. Toda esta comunicação é efetuada numa thread à parte de modo a não bloquear a
Main thread da aplicação e após este processo, o cliente liga-se ao MessageCollector com os parâmetros de
autenticação definidos e o token de projeto. A lista de dispositivos possíveis de serem emparelhados por
Bluetooth é filtrada de modo a aparecer ao utilizador apenas telemóveis, e não outro tipo de dispositivos de Bluetooth, como é visível na Figura 6-18.
Figura 6-18 - Emparelhamento por Bluetooth.
Caso o responsável decida associar os dispositivos dos participantes por código QR, o código gerado pela aplicação irá conter o endereço IP juntamente com o token gerado na criação do projeto. É possível ver o ecrã que exibe o código QR na figura seguinte.
Figura 6-19 - Exemplo do código QR gerado.
Após o investigador ter formado o grupo que irá participar na sessão de recolha, poderá atribuir uma configuração a esse grupo. A configuração permite ao investigador definir o nome do grupo de sessão, o tipo de sensores sobre os quais irá realizar recolha, bem como o número e o nome dos eventos que será possível marcar. O investigador também terá de colocar o seu nome, de modo a poder futuramente aceder aos dados recolhidos na plataforma web. Uma configuração possível encontra-se na Figura 6-20. Estas configurações serão enviadas por um tópico no MessageCollector, que todos os dispositivos que o investigador adicionou ao grupo irão receber ficando assim completamente associados e configurados de modo a iniciar a recolha.
Figura 6-20 - Exemplo de configuração atribuída a um grupo.
A comunicação com a RESTful API desenvolvida é realizada nesta fase, visto que é na altura em que todos os parâmetros que definem um estudo e um grupo estão definidos. Para o fazer é utilizado o Retrofit, que irá comunicar com essa API de forma assíncrona, devolvendo o resultado da comunicação através de
callbacks.
Por último, opcionalmente, o investigador poderá definir valores limite sobre o qual poderá ser alertado caso os dispositivos ultrapassem esses valores. Esses valores são configuráveis, podendo ser alterados a meio da recolha, ou entre recolhas, o ecrã de configuração é visível na Figura 6-21. Os valores configurados, são enviados para todos dispositivos através do MessageCollector, sendo que esses valores são colocados na configuração dos serviços de ligação ao sensor, produzindo os alertas que serão encaminhados de volta para o VR-Remote.
Figura 6-21 - Definição de alarmes.
Monitorização e controlo da recolha
O investigador, na fase de recolha, terá ao seu dispor várias ferramentas e mecanismos de feedback de modo a monitorizar e controlar o processo. Do lado esquerdo da interface terá disponíveis os eventos, momentos no protocolo de experiência, que definiu na configuração de sessão, que poderá marcar com o long
que simbolizam os participantes da sessão, e na parte inferior, os dois botões de controlos, que ao ser pressionados marcam o início ou o fim do período de recolha. A interface principal pode ser vista na figura seguinte.
Figura 6-22 - Interface principal de controlo disponível ao investigador.
A grelha de dispositivos permite ao investigador ter acesso ao estado de ligação de cada dispositivo ao sensor que está a recolher dados, mas também, o estado de ligação do VR-Unit ao MessageCollector. Os códigos de cor serão abordados na tabela seguinte:
Cor Ligação ao sensor Ligação ao MessageCollector
Verde Ligado e a recolher Ligado
Amarelo A tentar ligar ---
Vermelho Desligado Ligação perdida
Cinzento Sensor não utilizado ---
Tabela 6-2 - Códigos de cor do estado de ligação.
O feedback visual da cor de cada componente, transita de acordo com a informação recebida no
MessageCollector. As aplicações VR-Unit enviam a informação do estado de ligação dos sensores, e o EventBus propaga essa informação até ao ViewModel deste fragmento, que terá o trabalho de alterar a
informação associada aos dispositivos, alterando a cor dinamicamente. O estado de ligação do VR-Unit ao
MessageCollector, altera o feedback do estado de conexão caso o dispositivo não envie a mensagens de ping
no intervalo de tempo definido, que neste caso é de 5 segundos.
O investigador, poderá ver com mais detalhe a informação de cada dispositivo, se carregar na célula correspondente ao mesmo. Na Figura 6-23 podemos ver um exemplo de uma dashboard individual de um participante, esta dashboard apenas mostra os sensores que o participante está a utilizar na recolha, onde também é possível ver o feedback visual do estado da conexão. Esta dashboard é composta por uma
RecyclerView, cuja as células se forem clicadas permitem ao investigador navegar para o fragmento de
Figura 6-23 - Dashboard individual de um participante.
Durante o período de aquisição, na receção de um alarme sobre os valores definidos como limite, será gerado um feedback visual na célula do dispositivo que gerou o alarme juntamente com o aparecimento a vermelho do número de alarmes que já aconteceram. Estes alarmes, são enviados pela aplicação VR-Unit que o despoletou, através do MessageCollector, internamente, essa mensagem é propagada até ás dashboards e fragmento de visualização do sensor em questão. Um exemplo do feedback visual da célula a alterar de cor, bem como o número de alarmes que já ocorreram, é visível na figura seguinte.
Figura 6-24 - Feedback visual de alarmes.
No final da aquisição, o investigador poderá comandar o upload dos dados de aquisição para a cloud. Na dashboard de controlo, após parar a aquisição, o botão de upload irá aparecer possibilitando o envio do comando de upload a todos os VR-Unit. Na receção as aplicações VR-Unit e também o VR-Remote comprimem os ficheiros da aquisição e colocam-nos na pasta respetiva do estudo, na cloud. Será também disponibilizado ao investigador um ecrã de sumário de aquisição, como é possível ver na figura seguinte,
onde é possível ver o número de eventos marcados, número de alarmes ocorridos, tempo de sessão e número de desconexões.
Figura 6-25 - Sumário de sessão de aquisição.
Visualização de dados
Nesta aplicação é possível visualizar os dados recebidos por cada aplicação VR-Unit enquanto decorre a recolha. No fragmento de visualização de cada tipo de sensor, é efetuado um pedido de envio de dados, que terá de ser renovado periodicamente, ao dispositivo a que pertence esse sensor. Os dados são recebidos por subscrição ao tópico de receção de dados por parte do VR-Remote, sendo o EventBus o responsável por os propagar até ao ViewModel de cada fragmento visualizador. Na Figura 6-26 temos um exemplo desse fluxo, a variável observableGpsData, no método de subscrição do EventBus é preenchida, aparecendo os dados automaticamente nos campos do fragmento.
Figura 6-27 - Fragmento de visualização de sinais vitais.
No fecho deste fragmento, irá ser enviada uma mensagem de controlo de modo à aplicação cliente não enviar mais tranches de dados. O mecanismo de renovar o pedido de dados periodicamente permite manter o fluxo de dados ativo, mas também permite impedir o envio de dados caso ocorra algum problema na conexão entre os dispositivos, ou em caso de ocorrer algum problema com a aplicação controladora.
Consulta do histórico
Na aplicação VR-Remote, como suporte ao investigador, é fornecido uma maneira de consultar o histórico de eventos já marcados, organizado por estudo e aquisição, alarmes despoletados organizado por participante, e ainda, configuração e log de aquisição, organizado por estudo e aquisição.
Cada um desses elementos de histórico é composto por RecyclerViews que podem assumir uma disposição em lista, ou em grelha. Na Figura 6-28 é possível ver dois exemplos de consulta de histórico. Os dados apresentados nestes componentes de visualização de histórico, são provenientes da base de dados local da aplicação, e devido à utilização de queries do tipo LiveData em cada um destes elementos, é possível visualizar alterações em tempo real nas listas. Por exemplo, quando um alarme é despoletado, é possível verificar o aparecimento dele, sem ser necessário nenhum refresh implícito por parte do utilizador.
a)
b)
Figura 6-28 - Histórico de estudos, e informação associada a um grupo de recolha.