PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO
Cliente Android para comunicação instantânea e
compartilhamento de contexto usando mapas
André Victor Gomes de Aboim Mac Dowell
PROJETO FINAL DE GRADUAÇÃO
CENTRO TÉCNICO CIENTÍFICO - CTC
DEPARTAMENTO DE INFORMÁTICA Curso de Graduação em Engenharia da Computação
Rio de Janeiro, Novembro de 2012
André Victor Gomes de Aboim Mac Dowell
Cliente Android para comunicação instantânea e compartilhamento de contexto usando mapas
Relatório Final de projeto de conclusão de curso, apresentado ao curso de Engenharia da Computação da PUC-Rio como requisito parcial para a obtenção do titulo de Engenheiro de Computação.
Orientador: Markus Endler Redes de Computadores e Sistemas Distribuídos
Rio de Janeiro
Novembro de 2012.
Agradecimentos
Ao professor Markus Endler, pela paciência e revisão atenciosa.
À equipe do LAC PUC-Rio, pelo conhecimento compartilhado, apoio e feedback
dado.
À equipe do Kimeric Labs, pelo apoio e confiança.
À equipe do CAE do Tecgraf PUC-Rio, em especial ao André Luiz C A Reis e ao
Gabriel Bustamante Monteiro Lopes pelo feedback dado e confiança.
1
Resumo Mac Dowell, André Victor Gomes de Aboim. Endler, Markus. Cliente
Android para comunicação instantânea e compartilhamento de contexto usando mapas. Rio de Janeiro, 2012. 70p. Relatório Final de projeto de conclusão de curso Centro Técnico Científico CTC, Departamento de Informática. Pontifícia Universidade Católica do Rio de Janeiro.
Aplicativo para a plataforma Android para comunicação textual assíncrona instantânea com nós fixos e móveis usando protocolos SDDL e compartilhamento de dados de contexto obtidos por sensores do dispositivo móvel, como localização, além de compartilhamento de pontos de interesse, acompanhamento de localização usando mapas, interpretação de arquivos descritores de formulários e compartilhamento de dados de inspeção com um controlador em tempo real.
Palavras-chave
Portabilidade; comunicação; contexto; rastreamento; monitoramento.
Abstract Mac Dowell, André Victor Gomes de Aboim. Endler, Markus. Android client
application for instant communication and context sharing using maps. Rio de Janeiro, 2012. 70p. Relatório Final de projeto de conclusão de curso Centro Técnico Científico CTC, Departamento de Informática. Pontifícia Universidade Católica do Rio de Janeiro.
Application for the Android platform for asynchronous instant text communication with fixed and mobile nodes using SDDL protocols and sharing context data obtained by the mobile device sensors, such as location, besides sharing points of interest, tracking using maps, interpretation of form file descriptors and sharing inspection data with a controller in real time.
Keywords
Portability; communication; context; tracking; monitoring.
2
1 Introdução 1.1 O projeto ContextNet A motivação do projeto descrito neste trabalho vem de requesitos de um
projeto em desenvolvimento no LAC (Laboratory for Advanced Collaboration) da
PUC-Rio, o ContextNet. O Projeto ContextNet visa a provisão de serviços de contexto para
aplicações colaborativas de grande e larga escala, tais como monitoramento ou
coordenação on-line de atividades de entidades móveis e compartilhamento de
informações através das redes sociais. Estas entidades podem ser usuários de
dispositivos portáteis (como Smartphones e Tablets), veículos ou até mesmo
robôs móveis autônomos. O ContextNet é focado principalmente no
desenvolvimento de tecnologia de Middleware para tratar de três grandes
desafios:
- Permitir distribuição escalável de informações de contexto entre centenas
de milhares de entidades móveis produtoras e consumidoras dessas
informações;
- Elaborar técnicas automatizadas de raciocínio inerentemente distribuídas
e capazes de detectar padrões de movimentação relevantes para aplicações
móveis distribuidas;
- Uso de Web-Semântica para combinar diversos tipos de contexto
(computável, físico, temporal, de usuário) e integrá-los com as redes sociais, de
modo a aumentar as capacidades de comunicação e coordenação entre
entidades móveis.
O principal interesse desse projeto é melhorar a coordenação e
colaboração em aplicativos móveis (entre grupos de usuários e/ou veículos)
através de informações sobre o movimento de grupos e serviços baseados em
localização.
Exemplos de aplicações alvo para o ContextNet são: monitoramento de
frotas de veículos e sistemas de expedição, logística, coordenação de equipes
de emergência, gestão de força de trabalho móvel, emprego de redes móveis
como meio de possibilitar a comunicação, onde aja necessidade de
compartilhamento de dados e coordenação entre um conjunto possivelmente
muito grande de nós móveis.
A maioria dessas aplicações exige a capacidade de lidar com a
disseminação em tempo real de informações de contexto/localização, de
3
comunicação em grupo e gestão de nós móveis, adaptabilidade em cenários
muito dinâmicos, onde os nós móveis estão sujeitos a conectividade
intermitente, ou mudanças em seu endereço IP, bem como agrupamento
dinâmico de nós de acordo com a sua posição ou qualquer outra informação de
contexto móvel.
Uma característica comum de todas estas aplicações alvo é o fato de que
os nós móveis geram dados periodicamente, estes chamados de informações de contexto. Exemplo desses dados são posição geográfica e velocidade (ou
outros dados sobre seu estado, sua condição de operação ou carga). Esses
dados são publicados para outros nós (fixos ou móveis) para serem processados
ou visualizados em tempo real. Assim, presume-se também que cada nó móvel
possua alguma interface de comunicação sem fios, e seja capaz de se
comunicar com outros computadores e servidores através de uma conexão IP.
Para todas estas aplicações, o requisito principal é que, se o nó móvel está
ligado e está produzindo dados de contexto, essas atualizações de contexto
devem ser entregues a todos os outros nós interessados nessas informações
com a minima latência possível (quase instantaneamente).
O projeto implementado e descrito por este trabalho é o ContextNet-Mobile, ou CNet-M, que tem como proposta ser um exemplo de aplicativo móvel (nó móvel ou cliente) de uma aplicação distribuida para rastreamento e
comunicação chamada Aplicação ContextNet. Esta aplicação se comunica com
uma central de monitoramento e controle e com outros nós móveis através dos
serviços de middleware disponibilizados pelo ContextNet.
Neste texto, o nó fixo, ou central de monitoramento e controle que se
comunicará com os nós móveis será chamada de Controlador ARFF, nome da
central desenvolvida pelo LAC para se comunicar com o CNet-M. O middleware
de comunicação e compartilhamento de contexto do ContextNet é a Scalable Data Distribution Layer ou SDDL. O acesso aos serviços do middleware
ContextNet faz-se, por parte do cliente móvel, a partir de uma biblioteca
chamada de CNCLib.
4
Figura 01: Comunicação entre o ContextNet Mobile e o Controlador ARFF através do CNCLib e o
SDDL. O middleware e a biblioteca serão mais bem explicados na Seção 4.2.3.
A CNCLib disponibiliza uma API para a conexão e a troca de dados de
forma assíncrona com outros elementos da Aplicação ContextNet. No entanto,
através de interfaces genéricas definidas pela mesma, é permitido que o
desenvolvedor da aplicação distribuida (Controle ou Cliente Móvel) defina os
tipos de dados específicos de sua aplicação. Assim, ele terá toda a liberdade de
escolha dos tipos de dados que serão compartilhados entre os Nós Móveis e o
Controlador, desde que implemente adequadamente as interfaces genéricas
necessárias.1
O CNet-M foi idealizado como um Cliente Móvel para exemplificar o uso
de serviços de comunicação móvel, usando a CNCLib. Assim, foi decidido que o
CNet-M deveria ser construído em uma plataforma que disponibilizasse serviços
e recursos necessários para acesso à gerentes de localização do dispositivo,
API para uso de mapas em aplicações suporta-se multithreading. A plataforma
escolhida foi o Android, da Google.
1.2 A plataforma Android A plataforma Android é um sistema operacional móvel e um framework de
aplicação, desenvolvido pela Google a partir de 2005 e apoiado pela Open
Handset Alliance (OHA), um cosórcio que engloba algumas das mais
importantes empresas de tecnologia e comunicação móveis atuais como T-
Mobile, Asus, Dell, Acer, LG, Samsung, Sony, entre outras. Atualmente
encontra-se na versão 4.2 (Jelly Bean).
O Android Framework inclui funcionalidades importantes para o
1 Mais informações sobre a CNCLib e suas interfaces na Seção 4.2.3 e no Apêndice B.
5
desenvolvimento de aplicações móveis como tecnologia GSM, navegador de
internet, gráficos otimizados utilizando biblioteca OpenGL, SQLite para
armazenamento local, máquina virtual Dalvik otimizada para dispositivos móveis,
um Media Framework com suporte a uma vasta gama de codecs de dados, APIs
para sensores (câmeras, tela sensível ao toque, GPS, acelerômetros, entre
outros) e suporte à tecnologias de comunicação atuais como Bluetooth, EDGE,
3G, 4G e Wi-Fi.
Além dessas características, o framework possui suporte a emuladores de
dispositivos, ferramentas pra debug, monitoramento de memória, desempenho e
processos, entre outras facilidades.
Foi escolhida a plataforma Android para desenvolvimento do cliente móvel
tanto pela compatibilidade com uma vasta gama de aparelhos de empresas
pertencentes à OHA quanto pelo fato de o sistema Android vir integrado com um
conjunto de gerentes de recursos (managers) integrados a aplicações nativas
como cliente de e-mail, software para SMS, calendário, browser, contato e
visualização de mapas, etc. Através desses managers, outras aplicações (como
o CNet-M) podem acessar dados e serviços referentes a essas aplicações.
Além dessas facilidades, a plataforma Android disponibiliza APIs de fácil
uso para a obtenção dos mais diversos dados de contexto, obtidos dos sensores
do dispositivo móvel (para os aparelhos que têm tais sensores). Em especial, a API integrada de mapas (visualização e sobreposição de camadas de ícones/map overlays) e os serviços de localização (coordenadas geográficas) foram fatores decisivos para a escolha dessa plataforma para este
projeto.
Aplicativos desenvolvidos para a plataforma Android são escritos em Java, usando o kit de desenvolvimento de software (Android SDK) padrão da Google.
Este acabou sendo outro motivo pela escolha da plataforma Android para o
desenvolvimento do CNet-M, já que a CNCLib também é uma biblioteca para
aplicações Java.
Quando desenvolvemos um aplicativo em Android, devemos escolher uma
versão mínima e recomendada da API do Android e, dependendo do Nível de
API (referente à versão do sistema) escolhido, tem-se à disposição um conjunto
diferente de funcionalidades (relacionados à comunicação, apresentação de
assim como uma
abrangência maior ou menor de aparelhos compatíveis com a API. Para o CNet-
M, foi escolhida a API 10 (Gingerbread), por possuir todas as características e
funcionalidades necessárias ao funcionamento adequado do aplicativo, além de
6
ser a mais difundida atualmente no mercado (apesar de existirem APIs
superiores, sendo a mais recente a de nível 16, Jelly Bean, como pode ser visto
na figura abaixo).
Figura 02: Distribuição dos sistemas Android em novembro 2012[1]
Em resumo, foi decidido que a plataforma Android era a mais apropriada
entre as opções atuais por diversos motivos, tais quais a facilidade da utilização
de uma API amigável ao programador (por se tratar de uma linguagem já
amplamente conhecida como Java), as funcionalidades de acesso a dados de
sensores e do gerente de localização (que permite obter a localização atual do
dispositivo através de GPS, redes 3G ou Wi-Fi), de comunicação 3G/Wi-Fi e
sistema de arquivos com acesso simplificado que a plataforma Android
disponibiliza. Além desses fatores, foram considerados também o baixo custo
relativo dos smartphones e tablets capazes de executar a API escolhida, e a
grande disseminação de aparelhos utilizando essa plataforma em comparação a
outras (como iOS, Windows Mobile, BlackBerry e Symbian)[2].
1.3 O Controlador ARFF Com base no ContextNet, foi desenvolvido pelo LAC um Web-Applet com
função de exemplificar funcionalidades de uma central de controle e
monitoramento de frota de nome Controlador ARFF. Esse applet, usando
comunicação SDDL, tem capacidade de compartilhar dados e de se comunicar
textualmente com nós móveis.
7
Figura 03: Visualização de um veículo no Controlador ARFF.
O ARFF tem como objetivo principal o acompanhamento do deslocamento
de nós móveis executando o CNet-M em um mapa. Como o escopo de uso
definido para a aplicação distribuida ContextNet (Controlador ARFF e nós
móveis executando o CNet-M executado em conjunto) foi o de rastreamento e
comunicação com veículos de uma frota, o mesmo foi concebido de forma a ser
utilizado por motoristas de empresas de frotas e fiscais destes veículos. Assim,
a representação dos nós móveis na tela do ARFF tem um ícone específico
dependendo do tipo do nó móvel.
Outras funcionalidades do Controlador incluem filtragem da visão do mapa
a partir do estado atual dos nós (livre, ocupado, em inspeção, entre outros),
delegação de inspeções em determinados veículos para fiscais,
acompanhamento de inspeções em tempo real a partir dos dados enviados pelo
nó móvel, além da já mencionada comunicação textual e do recebimento de
alertas visuais quando determinados nós entram ou saiem de regiões marcadas
no mapa.
A aplicação distribuida foi planejada de modo conjunto com o objetivo de
que as funcionalidades relacionadas a comunicação de uma parte dela tivesse a
resposta adequada na outra (como o preenchimento de formulário no CNet-M
com resposta na tela do ARFF em tempo real, por exemplo).
1.4 O ContextNet-Mobile Tendo o ContextNet e a plataforma Android como base, o objetivo desse
8
trabalho foi o projeto e desenvolvimento de um aplicativo cliente (CNet-M) para
comunicação com o Controlador usando os serviços disponibilizados pela
CNCLib. Esse aplicativo terá funcionalidades de comunicação instantânea com
outros nós móveis e com o Controlador para fins de compartilhamento de sua localização e outras informações de contexto usando a API de mapas
disponibilizada pela Google (Google Maps API[3]), e dados de sensores obtidos
do dispositivo móvel.
O aparelho que executa o CNet-M será visualizado no mapa do
Controlador como um nó móvel e sua posição será atualizada conforme as
coordenadas são enviadas. O uso dos serviços dispostos pela CNCLib para
comunicação entre os nós possibilita o compartilhamento de dados de contexto
tanto com o Controlador quanto com outros nós moveis.
Como o aplicativo foi planejado para uso de fiscais e motoristas, temos que
o mesmo teve que ser projetado para uso por usuários com perfis de manuseio
distintos (esses perfis serão mais bem explicitados na Seção 4.1). Dado esse
fato, a Interface Gráfica de Usuário (GUI) foi planejada de modo que o usuário dispense pouca atenção para o manuseio do aplicativo. Esse aspecto da
GUI foi pensado especificamente para determinados tipos de usuário, no caso,
motoristas e fiscais de trânsito, e foi cuidadosamente planejado de modo a
atender as especificações das guidelines de design de GUI para aplicativos
móveis[4].
Sendo o ContextNet um projeto com o intuito de ser usado para aplicações
de larga escala, projetar o CNet-M foi uma tarefa que englobou conhecimentos
técnicos e acadêmicos de várias áreas distintas do curso de Engenharia de
Computação, tais como princípios de Engenharia de Software, modelagem e
design de projetos e aplicativos móveis, programação em linguagens orientadas
a objetos, redes e comunicação de dados, computação concorrente entre outros
(os estudos realizados serão melhor explicitados na Seção 4).
2 Estado da Arte 2.1 Aplicações similares Existem diversas abordagens diferentes para o problema de
monitoramento de entidades móveis disponíveis hoje em dia, como por exemplo,
aplicativos desenvolvidos para plataformas móveis como iOS, Windows Mobile
ou Android.
Um aplicativo móvel comercial que se encaixa parcialmente no escopo de
9
aplicação apresentado é o Waze[5]. Waze consiste em um aplicativo de
compartilhamento de informações de transito e construção colaborativa e
interativa de mapas pela comunidade que o usa. A interface gráfica de usuário
do Waze é pensada nos moldes da do CNet-M, onde o usuário deve dispensar
somente a atenção necessária para o manuseio do aplicativo.
Figura 04: Waze, aplicativo colaborativo de GPS e sobreposição de mapas.
Outros aplicativos de sucesso de compartilhamento de geolocalização
dos usuários nas lojas de aplicativos do iOS e de Android são: iGO Primo[6],
LocalScope[7], Navigon[8], MotionX GPS Drive[9], MapQuest[10] e
Wabbers[11][12]. Esses aplicativos (juntamente ao Waze) têm as características
de serem os mais baixados em suas categorias (Navegação/Viagens) e de
permitirem visualização e acompanhamento do cliente (veículo) em um mapa
mostrado na tela do celular e tablet. A principal diferença entre eles é a
possibilidade de marcação e compartilhamento de Pontos de Interesse (POIs)
no mapa. Para esse trabalho, POIs são locais dinâmicos ou estáticos no mapa
que possam interessar ao motorista, tais como regiões engarrafadas, acidentes,
blitz policiais, postos de gasolina e outros.
10
Figura 05: Compartilhamento de POIs no Waze
No caso, somente MotionX GPS Drive, Map Quest, iGO, Wabbers e Waze
têm apresentação de POIs na tela, sendo que desses, somente em Wabbers e
Waze é possível de fato, compartilhar POIs com outros usuários, assim,
tornando o mapa visto por todos um mapa colaborativo dos usuários da
aplicação.
Fazendo uma pesquisa no histórico de vendas das aplicações citadas e de
suas respectivas colocações no ranking geral (de todas as categorias) de
vendas de aplicativos das lojas para dispositivos executando iOS e Android,
vemos que as únicas aplicações com bom desempenho na categoria geral (e
com bom desempenho contínuo na categoria de navegação) são as que
incorporaram aspectos de leitura/compartilhamento de POIs, sendo as melhores
Waze e MapQuest, justamente pelo foco na interatividade e troca de
informações entre os usuários. O MapQuest não tem compartilhamento de POIs,
mas foca em outros tipos de interatividade e Wabbers é recente no mercado e
não tem uma boa abrangência ainda2.
Apesar da existência desses aplicativos de compartilhamento de certos
tipos de contexto e geolocalização, ainda falta uma solução para o mercado de
monitoramento de frotas que englobe os conceitos de compartilhamento de
contexto (bem apresentado no Waze em uma GUI muito coerente) com o 2 Ver Apêndice A para gráficos de ranking das aplicações citadas em suas respectivas lojas de aplicativos.
11
monitoramento dos dispositivos móveis a partir de um Controlador, subscrição
de regiões/contexto e comunicação instantânea, tudo na forma de um pacote de
serviço completo e expansivo, e não somente um aplicativo final como os
citados.
Como o escopo do trabalho define a necessidade de comunicação e
compartilhamento de dados de contexto em tempo real entre o Controlador e os
clientes móveis, assim como a comunicação entre clientes móveis, uma solução
que funciona meramente para levantamento de dados também não é suficiente.
Assim, vemos que as soluções atuais mais populares referentes a esse
problema não são satisfatórias para o objetivo que queremos alcançar.
2.2 O diferencial ContextNet Analisando as funcionalidades propostas e as tecnologias usadas pela
aplicação distribuída ContextNet, ou seja, o cliente móvel CNet-M, Controlador
ARFF e a CNCLib, percebe-se uma clara diferença quando comparamos com as
soluções mais populares hoje em dia. Enquanto a Aplicação ContextNet é
proposta como uma solução flexível e extensível para clientes que desejem um
serviço distribuído de comunicação e compartilhamento entre um Controlador e
nós móveis e entre os mesmos, as aplicações vistas assemelham-se a produtos
finais com objetivos bem definidos para uso de usuários finais.
2.3 Ponto de partida do ContextNet-Mobile O CNet-M já havia sido idealizado antes do inicio deste projeto de
conclusão de curso, já que o ContextNet já estava em desenvolvimento nessa
época. Na concepção do CNet-M apresentada nesse trabalho, havia
anteriormente um exemplo de conectividade com integração mínima entre o
cliente e o Controlador, usando apenas uma tela de mapa e funções básicas de
compartilhamento de geolocalização a partir de um simulador de rotas interno e
alguns serviços do middleware de comunicação SDDL disponíveis, porém
internos ao aplicativo, pois o desenvolvimento do CNCLib por parte do LAC
PUC-Rio ainda estava em estado inicial. Essa primeira versão do cliente recebeu
o nome de InfoPAE Móvel (IPM).
12
Figura 06: IPM em execução
O IPM vinha apenas com as funcionalidades mais básicas necessárias
para a demonstração de como um cliente móvel para o ContextNet se
estruturaria. São estas:
- Demonstração do ícone do veículo com a posição atualizada em tempo
real no mapa da aplicação (a partir dos dados de geolocalização gerados por um
simulador interno);
- Conexão a um Gateway pelo middleware SDDL através de um IP
disponibilizado pelo usuário
contexto do aplicativo;
- Envio dessa posição através de mensagens SDDL para o Controlador;
- Identificador único gerado aleatoriamente, a UUID (Universally Unique
Identifier), mostrada na parte superior da tela e com possibilidade de ser editada
manualment A UUID é usada para identificar o cliente
móvel dentre todos conectados ao Controlador, pois é garantidamente única[13];
-
- Visualização de mensagens
e de janelas flutuantes no momento da recepção das mesmas.
As mensagens de geolocalização eram enviadas em períodos de tempo
13
pré-definidos pelo simulador. O controlador identificava as coordenadas como
sendo de um cliente específico a partir da UUID gerado.
Em resumo, o Controlador já podia enviar e receber mensagens de
qualquer veiculo conectado. O veículo tentava se reconectar ao gateway anterior
ou acha outro gateway com uma conexão melhor ao perder a conexão com o
atual. Apesar dessas funcionalidades, ainda faltavam funções básicas de
interação, comunicação e troca de mensagens e dados de contexto e
serializáveis com o Controlador, entre outros, além de uma GUI adequada para
que o IPM se enquadrasse como solução do problema proposto.
A partir desse exemplo inicial, foi construído um novo aplicativo com as
seguintes funcionalidades básicas:
- Simulação e envio pelo SDDL de coordenadas geográficas;
- Compartilhamento de POIs com outros nós;
- Comunicação textual assíncrona com o Controlador e com outros nós
móveis;
- Preenchimento de formulários dinâmicos e envio dos mesmos;
- Envio real de coordenadas geográficas;
- Cadastro de informações referentes aos usuários do aplicativo,
configurações pessoais e de conexão.
Atenção especial foi direcionada à GUI e, também, à própria relação entre
as diversas telas do aplicativo, que foi repensada de modo que a navegação
entre as mesmas fosse fácil, independente do usuário.
Para continuar o desenvolvimento do IPM, então cliente do ContextNet,
foram necessários estudos iniciais além da simples comunicação entre nó móvel
e Controlador. Os tópicos abordados inicialmente foram os relacionados às
funcionalidades inicialmente desenvolvidas (porém incompletas) como estudo da
API de Mapas do Google, mudanças dinâmicas em layouts de telas no Android e
multithreading para Android. Esses estudos serão mais bem detalhados na
Seção 4.2.2.
Sumarizando as seções anteriores, percebe-se que a complexidade da
Aplicação ContextNet, ou seja, Controlador usando SDDL em comunicação
assíncrona constante com o CNet-M usando CNCLib, é sem paralelo com o que
é fornecido pelos aplicativos comerciais citados.
14
3 Objetivos do trabalho O objetivo principal deste trabalho foi de projetar, desenvolver e avaliar um
cliente móvel para o ContextNet. Assim, fez parte dos objetivos a implementação
de comunicação instantânea por texto, compartilhamento de informações de
contexto através de mapas e preenchimento de formulários vindos de um
Controlador, isso tudo em um aplicativo móvel executando na plataforma
Android e utilizando a biblioteca CNCLib, o CNet-M. O aplicativo desenvolvido
representou uma evolução significativa com relação ao cliente IPM original.
Durante o desenvolvimento do CNet-M, uma das principais preocupações
foi com que ele fosse projetado de modo a ser um aplicativo robusto e confiável,
com uma GUI simples e eficiente, ou seja, que consista com o uso do aplicativo
em momentos cujo usuário não possa dispensar mais atenção que o necessário.
Além disso, desejava-se que o aplicativo detivesse as funcionalidades de
interação entre os motoristas e o Controlador, necessárias para seu uso
completo e integrado, tais como o compartilhamento de contexto,
geolocalização, formulários e mensagens em tempo real e subscrição de
eventos de interesse e regiões/contexto.
Visto as funções faltantes ao aplicativo, foi possível (durante Projeto Final I,
a primeira parte desta matéria) a idealização das tarefas principais a serem
feitas durante esse trabalho, tais como:
- Integrar o aplicativo à CNCLib, criando uma lógica de
conexão/envio/recebimento de dados a partir das funcionalidades especificas do
Android para esse tipo de objetivo;
- Reestruturar o aplicativo IPM tornando a tela de Mapas independente
de outras funcionalidades secundarias e de modo a deixa-la livre de elementos
desnecessários de interface;
- Criar lógica de mudança de telas a partir de um menu principal a ser
definido;
- Incluir métodos para tratamento de mensagens dos tipos: formulário, texto
e POIs, e trata-las graficamente de modo adequado;
- Incluir lógica para troca de mensagens com o Controlador e com outros
clientes móveis a partir de uma GUI que faça sentido no escopo dado;
- Incluir opções secundárias de identificação do cliente móvel através de
rótulos editáveis por uma tela de configurações a ser definida;
- Criar lógica de apresentação de formulários dinamicamente na tela e
envio de informações preenchidas pelo usuário (automaticamente ou não) ao
15
controlador.
A partir dessas tarefas, foi possível a modelagem das telas necessárias ao
aplicativo, assim como os casos de uso mais comuns: o uso por um motorista, e
o uso por um fiscal de transito. Detalhes dessa modelagem serão mais bem
descritos na Seção 4.1.
Os objetivos traçados no inicio do projeto foram estes de modo que o
produto a ser alcançado ao término fosse um aplicativo com todas as
funcionalidades desejadas, mas também, que demonstrasse as características e
potencialidade da Aplicação ContextNet de forma clara. A ideia sempre foi criar
um aplicativo que pudesse ser facilmente extensível e customizavel ao desejo da
empresa contratante do serviço, de modo que a Aplicação ContextNet como um
todo pudesse ser moldada dependendo do escopo desejado pela mesma. Isso
implicaria, entre outros, na possibilidade do uso do CNet-M não somente por
empresas de rastreamento de frotas de ônibus, mas também cooperativas de
taxi, transportadoras, correios, governo, exército e até mesmo iniciativas
ambientais.
O CNet-M foi desenvolvido durante esse trabalho concomitantemente à
CNCLib (que fora responsabilidade do LAC). As tarefas de desenvolvimento e os
estudos relacionados à construção desse aplicativo citados nessa seção serão
mais claramente explicados na Seção 4.2.
4 Estudos e Metodologia Antes do inicio dessa matéria, foram estudados conteúdos conceituais e
técnicos de modo a formar uma base para o inicio da conceituação e projeto do
aplicativo CNet-M. A metodologia empregada teve ligação direta com os estudos
necessários durante a idealização e prototipagem do CNet-M, estes podendo ser
divididos em Estudo de Interface Gráfica e Estudos Técnicos e Conceituais.
4.1 Estudo de GUI Interface Gráfica de Usuário
Ao inicio e durante todo Projeto Final I, uma tarefa inicial necessária foi o
estudo e desenvolvimento de uma interface de usuário adequada para a
situação (onde o usuário poderá dispensar pouco tempo e atenção ao manuseio
dos componentes da interface). Sendo o aplicativo desenvolvido em Android, há
certos padrões de desenvolvimento de interface e interação com usuário que
16
foi projetada com base nos estudos feitos dessas guidelines, assim como foi
pensada de modo a apresentar as funcionalidades principais do aplicativo de
modo fácil independente do tipo de usuário que a esteja usando.
O uso do CNet-M por um motorista, após a configuração do mesmo por um
técnico ou gerente responsável, passaria a maior parte do seu tempo de uso do
aplicativo na tela de mapa, pois será lá que ele poderá acompanhar o seu
percurso, receber dados de contexto e geolocalização de outros clientes cujo
grupo ele esteja subscrito e compartilhar POIs e mensagens com outros clientes
ou com o Controlador, além de continuar podendo visualizar mensagens de
outros clientes. Ou seja, todas as principais funções de compartilhamento de
dados que são necessárias do escopo de um motorista podem ser acessadas
diretamente de uma única tela.
Já o uso do aplicativo por um fiscal foi idealizado de modo que ele pudesse
preencher formulários de verificação e manutenção de veículos e compartilha-los
com o Controlador, além de se comunicar textualmente com a mesma e com
outros nós móveis.
Assim, foi pesquisado através de artigos técnicos, blogs, livros e sites
direcionados ao assunto [14][15][16][17], tendências de design de GUI para
aplicativos móveis visando o escopo da aplicação alvo. Com base nos objetivos
da Aplicação ContextNet, foram feitas as seguintes hipóteses:
- O aplicativo CNet-M será usado na maior parte do tempo por dois tipos
principais de usuário: Motorista, Fiscal.
- Um terceiro tipo, um gerente/técnico da aplicação, irá configura-la
inicialmente para uso dos outros tipos de usuário.
- Cada usuário tem um perfil de uso, conhecimento técnico,
disponibilidade de atenção e tempo para uso do aplicativo muito distintos.
- As funções básicas mais acessadas por cada usuário devem estar
disponíveis da forma mais direta possível.
A partir dessas afirmações, foi possível traçar certas diretrizes
envolvendo o design de cada uma das funções disponíveis no CNet-M, assim
como relações entre as mesmas, métodos de acesso e de input/output de
informação. Essas são as regras:
- O usuário motorista tem como objetivo principal no CNet-M,
acompanhar a movimentação de si mesmo assim como de outros nós móveis
cujo mesmo esteja subscrito nas respectivas regiões, se comunicar textualmente
e compartilhar POIs com esses nós, assim como com o Controlador.
17
Eventualmente o motorista poderá responder mensagens de formulários
também, mas isso se enquadra mais como função secundária perto das outras.
O aparelho será usado essencialmente em repouso no painel do carro, como um
GPS. Nível técnico: baixo. Tempo de uso: interações curtas, consulta visual
regular.
- O usuário fiscal tem como objetivo principal usar o CNet-M para enviar e
receber mensagens de formulário para fins de inspeção de veículos, assim como
se comunicar textualmente com outros fiscais e com o Controlador. O usuário
pode ainda configurar o aplicativo e acessar o mapa para verificar a própria
localização e de outros colegas. O aparelho deverá ser segurado na mão pelo
usuário durante o seu uso. Nível técnico: médio. Tempo de uso: interações mais
longas, de até 20 minutos, consulta visual eventual.
- O usuário técnico tem como objetivo configurar o CNet-M para uso
inicial dos outros tipos de usuário, incluindo um ou mais IPs de conexão
estáticos, arquivos de configuração na memória interna do aparelho, criar a
UUID do aparelho, entre outros. O aparelho deverá ser segurado na mão pelo
usuário durante o seu uso. Nível técnico: avançado. Tempo de uso: uma só vez
por aparelho, por até 5 minutos.
- Durante toda a interação no aplicativo e enquanto o mesmo não está
em uso, ocorre o compartilhamento de contexto e geolocalização do aparelho
com o Controlador, desde que o aplicativo esteja conectado a um Gateway.
Havendo conexão, a comunicação bi-direcional não cessa.
Assim, tendo as regras bem definidas, foi possível a construção de uma
relação entre as funções de cada tela e uma GUI apropriada a elas, usando,
claro, as guidelines de design para aplicações móveis pesquisadas. Algumas
guidelines importantes que foram seguidas no desenvolvimento:
- Botões devem ser suficientemente grandes para que a interação com o
aplicativo seja boa. Quanto maior o botão, mais fácil de aperta-lo. Um dedo
humano tem uma área de contado de aproximadamente 10 mm² na tela, logo,
um botão não deve ser menor que isso;
- A tela de um aparelho deve ser mapeada com zonas de conforto dos
dedos para cada tipo de aparelho/uso;
18
Figura 07: Região de conforto para navegação e controle em aparelhos em repouso[16]
- Durante o uso de uma tela de mapa para acompanhamento e
localização, a atenção com itens que não sejam o mapa deve ser a mínima
possível;
- O usuário, independente de quem seja, deve ser capaz de realizar suas
tarefas com menor quantidade de cliques possíveis;
- O menu de navegação deve ser pensado de maneira a englobar todas
as funcionalidades principais do aplicativo, mas de modo que o acesso seja
simples e não polua visualmente o mesmo;
- O usuário deve ter uma resposta adequada para suas ações, assim
como ações captadas pelo aplicativo, como recebimento de novas mensagens
ou eventos, como por exemplo, mudança no estado da conexão.
Figura 08 , muito usado para menu de
navegação[18]
19
A metodologia usada para a idealização das telas teve seguimento direto
desses estudos. Assim, a partir dos mesmos, foi possível a construção de
Mockups descrevendo as relações básicas entre as telas para, em seguida, vir
o desenvolvimento programático das mesmas. Primeiro foi feito o mockup das
telas iniciais (Mapa e Menu Principal), e com ele, foi pensado os métodos
prováveis de coleta de inputs e interações do usuário com a tela.
Figura 09: Estudos iniciais de GUI consistiam, por exemplo, na criação de Mockups e
experimentos programáveis além das pesquisas de guidelines
Com o formato geral das telas iniciais melhor estruturado, seguiu-se a
construção do mockup das telas de leitura de formulários. A ideia para esse
conjunto de telas era elaborar um exemplo de como era possível a construção
dinâmica de seções de um formulário, este definido e enviado em uma
linguagem própria pelo Controlador.
20
Figura 10: Mockup do módulo de manipulação de formulários com opções diversas de
GUI
Em seguida, com os mockups de GUI construídos, foram desenvolvidas
as telas da aplicação com todas as suas relações e interações de input/output
inclusas. Depois de finalizada essa etapa, essa primeira versão foi usada como
protótipo para uma pesquisa de feedback com usuários para (Seção 4.4 e 6.2),
então, ser revisada a partir dos resultados dando origem, enfim, à aplicação
final.
4.2 Estudos conceituais e de tecnologia Como já citado, foram estudados, ao longo deste trabalho, conceitos
técnicos e conceituais necessários para o desenvolvimento das funcionalidades
do CNet-M. Dada as funcionalidades desenvolvidas para o aplicativo, foi
possível identificar os tópicos principais que requisitaram estudo prioritário.
Assim, seguindo a metodologia empregada, após a construção de toda a
GUI, foram realizadas as tarefas restantes com base nos estudos descritos nas
próximas sub-seções.
4.2.1 Gerais
- Programação: Para os estudos mais gerais de programação para as
plataformas escolhidas, foram feitos aplicações exemplo de cada uma das
funcionalidades chave, como teste de interação com mapas e layouts dinâmicos
com base em arquivos descritores, teste da própria CNCLib, usando envio de
21
mensagens simples e testes de recebimento de mensagens no aplicativo móvel.
- Conceitos de MVC: A chamada arquitetura Model-View-Control é usada
para organizar a representação de informação que usuário interage com. Foram
estudados seus conceitos para a organização dos pacotes do aplicativo, de
modo a separar os seus módulos em funções claras como representação dos
dados e modelos, comunicação, visualização das telas e controle das regras e
relações entre os dados.
- Alternativas de design: Apesar do estudo extenso de GUI para o CNet-
M, houveram iterações baseadas em conceitos diferentes de design para o
menu principal e para a tela de mapa. Diferentes opções de menu foram não
somente projetadas, mas programadas a ponto de serem funcionais e, assim,
possibilitar testes antecipados.
4.2.2 Framework Android - API de Mapas do Google: O conteúdo referente à API de Mapas da
Google para Android foi coberto no estudo preliminar, durante a matéria de
programação para Android, como dito anteriormente. Porém, para o
desenvolvimento do CNet-M, funcionalidades de sobreposição de mapas e
adição de elementos dinâmicos atualizáveis no mesmo requisitaram estudo
adicional.
- Design de Layout para resoluções variadas: O CNet-M foi idealizado
para uso em Smartphones e Tablets. Para isto, foi necessário um estudo de
coerência de layouts para aparelhos de resolução diferentes[19].
- Componentes de interface Android: Assim como a API de Mapas do
Google, há outros componentes de interface que requisitaram estudo para a
construção do CNet-M da maneira que ele foi idealizado, como a construção do
menu Dashboard e as telas dinamicamente carregadas para as seções de
formulário (mais detalhes nas Seções 5.2.3 e 5.2.4).
- Gerentes de recursos e APIs de serviços do Android: Como já citado na
Seção 1.2, a API do Android disponibiliza acesso a diversos recursos do
aparelho e de aplicações nativas através de serviços. Os serviços de
localização, para nomear um, foram extensamente estudados ao longo do
desenvolvimento. Outros serviços, como acesso ao acelerômetro e à dados
internos do aparelho, possibilitariam o compartilhamento de outros dados
interessante de contexto. - Arquitetura do Sistema Android (avançado): Para programar um
aplicativo Android, mesmo que básico, é necessário o entendimento de certas
22
características da plataforma, como sistema de arquivos e o básico do ciclo de
vida das Activities3 executando no mesmo. Tratando-se de um aplicativo mais
complexo como o CNet-M, foi necessário um estudo de como a plataforma trata
multithreading, peculiaridades do ciclo de vida das Activities (efeitos da
manipulação de orientação, persistência de configurações ao reiniciar uma
Activity, etc)., persistência de dados de configuração e de usuário do aplicativo,
tarefas assíncronas e escrita/leitura de arquivos da memória interna do aparelho.
4.2.3 Middleware de Comunicação SDDL e a CNCLib - Comunicação SDDL: Camada que trata da comunicação entre os nós
de uma Aplicação ContextNet. Para atender aos requisitos referentes às
funcionalidades de comunicação tanto do CNet-M quanto do Controlador ARFF,
foi desenvolvido pelo LAC a Camada de SSDL[20]. O SDDL usa um domínio
DDS[21] para comunicação entre os nós fixos em seu núcleo (Controlador e
Gateways), e emprega uma abordagem de Gateways escaláveis para fazer a
ponte entre a comunicação de alto desempenho do DDS e a comunicação
potencialmente pouco confiável e propensa a desconexão dos nós móveis.
Os protocolos de comunicação são baseados no conceito de
Publicadores/Assintantes, isto é, mensagens de publicadores são recebidas por
todos os assinantes destes, mas somente por eles. Assim, pode haver nós no
domínio que recebem/enviam dados somente para outros grupos específicos de
nós.
3 Em Android, Activities são representações de telas/janelas únicas para o usuário. Mais informações na Seção 5.1.
23
Figura 11: Visão Geral da comunicação SDDL
O modelo de comunicação em si é independente de plataforma ou
linguagem de programação e garante interoperabilidade entre diferentes
produtos que o utilizem.
- CNCLib: É a biblioteca escrita em Java que abstrai o protocolo de
comunicação SDDL entre os clientes móveis e os Gateways. Considerando seus
serviços de comunicação assíncrona, gerenciamento de handovers,
interfaces/métodos simples e controle pleno sob o SDDL, a CNCLib impõe-se
como uma solução muito adequada para o acesso de clientes móveis ao
domínio do Controlador.
Para uma aplicação que utilize a CNCLib abrir uma conexão com um
Controlador, basta sua UUID (único para cada aparelho) e o endereço de IP do
servidor executando o Controlador. Dessa forma, através de uma
implementação da Interface NodeConnection4 da CNCLib, criamos uma conexão
entre o nó móvel e o Controlador. O nó móvel é capaz de receber informações
através de uma implementação da Interface NodeConnectionListener, esta
contendo métodos de callback para captar eventos de conexão, sejam
mensagens ou trocas no estado da conexão. Finalmente, temos a Interface
Message, através dela, podemos implementar quaisquer tipos de objetos
serializáveis que serão enviados e recebidos pelos nós conectados ao domínio.
Como a CNCLib ainda é um projeto em andamento, as funcionalidades
4 Verifique o Apêndice B para informações a respeito das interfaces de conexão e troca de mensagens da CNCLib.
24
de subscrição de grupos (API de grupos)[22] da mesma não estão finalizadas no
momento. Assim, o CNet-M também não terá, por enquanto, uma solução
completa para a funcionalidade de subscrição de grupos de nós móveis (as
módulos e funções do CNet-M serão melhor definidas na Seção 5.2).
4.3 Cronogramas e Diagrama de Gaant No relatório escrito ao término da matéria Projeto Final I, foi proposto um
cronograma de atividades de desenvolvimento do software proposto, o CNet-M.
Segue abaixo o cronograma idêntico ao que consta neste relatório:
Cronograma proposto durante o Projeto Final I para o Projeto Final II Descrição da tarefa Andamento Conclusão
prevista
Pesquisa dos protocolos de redes Em andamento 07/2012
Comunicação Assíncrona Incompleta 09/2012
Compartilhamento de POIs Incompleta 09/2012
Melhorias no serviço de comunicação Incompleta 12/2012
Atualização de estados e subscrições Incompleta 12/2012
Envio/recebimento de formulários Incompleta 12/2012
Preenchimento automático de forms. Incompleta 12/2012
Dado que tarefas antes previstas simples foram se tornando mais
complexas e se dividindo em subtarefas, e que a interface corrente, antes
acreditada adequada, teve de ser inteiramente revisada e refeita (como já dito),
o cronograma real de atividades realizadas constou como abaixo (em negrito,
novas tarefas antes não previstas):
25
Cronograma das atividades realizadas durante o Projeto Final II Descrição da tarefa Andamento Conclusão
Pesquisa dos protocolos de redes Concluída 09/2012
Lógica e relações interface e telas Concluída 10/2012
Comunicação Assíncrona Concluída 11/2012
Compartilhamento de POIs Concluída 12/2012
Melhorias no serviço de comunicação Concluída 09/2012
Atualização de estados e subscrições Concluída 12/2012
Envio e recebimento de formulários Concluída 11/2012
Preenchimento automático de
formulários
Concluída 10/2012
Compartilhamento de contexto (simulado)
Concluída 11/2012
Compartilhamento de geolocalização (real)
Concluída 12/2012
Percebe-se, comparando os cronogramas, que a maioria das atividades
foram concluídas antes ou depois do previsto. No caso as atividades
relacionadas à comunicação e compartilhamento acabaram sendo concluídas
mais tardiamente pelo caráter independente dessas funcionalidades em relação
às funcionalidades de coleta de informações do usuário e do sistema. O mesmo
pode ser dito das atividades referentes a manipulação de dados de formulários,
finalizadas antes, por exemplo, que a própria comunicação assíncrona.
Finalmente, como já foi dito, o compartilhamento de geolocalização real foi
realizado no fim, assim como a atualização de estados e subscrição, que ficou
incompleta já que a API de Grupos da CNCLib ainda está em desenvolvimento,
e a necessidade de uma tarefa de interfaces e telas surgiu devido ao retrabalho
realizado para concepção e implementação da GUI do CNet-M em relação a GUI
anterior existente (desenvolvida em parte no Projeto Final I). Segue, abaixo, um
Diagrama de Gaant das tarefas realizadas e suas respectivas durações.
26
Figura 12: Diagrama de Gaant das tarefas realizadas
4.4 Protótipos para demonstração Quando próximo do final do desenvolvimento, foram definidos dois tipos
de versões demonstração do CNet-M, uma sem conectividade, focando na
demonstração da GUI e da relação entre as telas, caixas de dialogo e inputs do
usuário para pesquisa de feedback realizada5, e outra completa, focando nas
funcionalidades de comunicação com o Controlador e outros nós, visualização
por mapas e compartilhamento de POIs.
Enquanto o protótipo de GUI foi planejado para ser usado em um
aparelho só durante a entrevista de qualidade e feeback de usuário, o protótipo
completo foi feito com o intuito a ser rodado em mais de um aparelho e/ou
emulador em conjunto com o Controlador ARFF de modo pleno.
5 Projeto e desenvolvimento do CNet-M Como já mencionado, o CNet- M é um aplicativo desenvolvido para a
plataforma Android. Assim, apesar de sua complexidade, o mesmo tem suas
funcionalidades construídas usando elementos, na maior parte, elementares do
framework do Android. Nesta seção, discutiremos como esse conjunto de
elementos é formado para a construção de um aplicativo móvel, assim como
uma descrição mais aprofundada das funcionalidades, abordagens de
desenvolvimento e sistema geral do CNet-M.
5 Mais detalhes dos resultados da pesquisa na Seção 6.2. Cópia da entrevista feita com os usuários no Apêndice D.
27
5.1 Estrutura geral de um aplicativo Android Ao iniciarmos a construção de uma aplicação Android, temos alguns
elementos principais que compõem a estrutura do projeto que devemos dar
atenção primária. Segue, abaixo, a imagem da estrutura comum de um projeto
Android.
Figura 13: Elementos principais de um projeto Android
,
onde o código fonte das classes desenvolvidas se encontra; , onde o
arquivo R.java gerado automaticamente se encontra; uma pasta com o nome da
API usada no projeto com a biblioteca referente a mesma dentro; onde
encontram-se os objetos e classes gerados na compilação, incluindo o arquivo
, que é o formato de aplicativos instaláveis no Android , onde
encontram- , onde
encontram-se todos os recursos usados para a construção do aplicativo como
imagens, sons, arquivo descritores de elementos de layout e de outros
AndroidManifest.xmldefinidos todas as características inerentes do aplicativo como API
recomendada, Activities da aplicação e suas configurações, estilos de layout e
de abertura da aplicação, permissões de uso de gerentes do aparelho, entre
outros. Conhecer esses elementos e o que compõe cada um é o primeiro passo
para a construção de um aplicativo Android.
5.1.1 Lógica de telas e Layout Android Activities Chamamos de Activity no Android, telas únicas com funcionalidades
especificas. Uma Activity deve ter uma View referenciada a mesma, isto é, um
elemento de Layout definido externamente (por um arquivo XML de recurso) ou
internamente (na própria classe).
28
Figura 14: Exemplo de View principal de uma Activity definida internamente e externamente.
A estrutura de um aplicativo Android, em geral, é definida por suas telas e
a relação entre elas. Assim, para criarmos uma tela, basta estendermos a classe
Activity do framework Android e implementarmos seu método onCreate(), ou
seja, o método que é chamado na criação da mesma. A Activity também deve ter
um layout definido e registrado pelo método setContentView() que recebe uma
View.
Toda Activity tem um ciclo de vida e métodos relacionados, ou seja, a cada
ação de troca de Activity, orientação, foco ou estado do aparelho (tela
bloqueada, por exemplo), há uma série de métodos que são chamados em uma
ordem especifica. Todos esses métodos podem ser re-implementados,
substituindo o original completamente ou chamando o mesmo após uma certa
rotina. O método onCreate() é normalmente usado para a implementação da
lógica principal da Tela justamente por sempre ser chamado na criação da
Activity.
29
Figura 15: Ciclo de vida de uma Activity no Android[27]
Vale lembrar que, sempre que criada uma nova Activity, a mesma deve ser
registrada no arquivo de manifesto Android, senão nos deparamos com uma
exceção em tempo de execução.
Também é importante saber que, quando criamos uma nova Activity, a
mesma é posta no topo na Pilha de Activities do sistema, ou seja, quando a
mesma for finalizada, a Activity anterior passará a ser a corrente.
Sumarizando, para a criação de uma tela simples definida por uma Activity,
precisamos de:
- Classe que estenda Activity com método onCreate() re-implementado
com referencia ao layout usado no método setContentView(), este chamado
- Layout definido ou internamente (no método onCreate() por exemplo) ou
- Registro da Activity no arquivo de manifesto Android.
Podemos mudar de telas a partir de interações do usuário com elementos
da tela atual lançando uma nova Activity e referenciando a classe da mesma.
Activities podem trocar recursos internos às mesmas passando dados através
dos 6, ou recuperando dados a partir de preferências salvas
6 Abstração de uma operação a ser executada, usada para lançar a Activity, também
30
anteriormente ou pela classe de aplicação (essas abordagens serão mais bem
explicadas na Seção 5.2.4).
5.1.2 Arquivo de Manifesto Android O arquivo androidmanifest.xml é criado automaticamente quando criamos
um projeto Android base, porém, o mesmo deve ser editado se quisermos
adicionar permissões de uso de gerentes e serviços do aparelho, adicionarmos
Activities ou mudar quaisquer configurações ou estilos da aplicação. Suas tags
principais são:
- <manifest> - Onde definimos o pacote base do aplicativo e
versionamento. Todas as outras tags são internas a esta;
- <uses-sdk> - Onde definimos a API mínima e recomendada do aplicativo;
- <uses-permission> - Onde definimos uma permissão de serviço
especifica. Cada tag deste define somente uma permissão;
- <application> - Onde definimos várias configurações da aplicação como
ícone, nome de exibição, estilos, extensão da classe de aplicação, modo debug,
assim como as tags de bibliotecas e Activities.
- <uses-library> - Interna a <application>, onde referenciamos bibliotecas
nativas da API usada para a aplicação (como a biblioteca de mapas do Google,
por exemplo).
- <activity> - Interna a <application>, onde referenciamos uma Activity
pertencente ao aplicativo e suas configurações (se é a activity principal que será
lançada, se a mesma define alguma funcionalidade a ser usada por outras
aplicações, seu nome próprio, etc).
5.1.3 Recursos estáticos do aplicativo
Como já mencionado, podemos definir recursos como elementos de layout
externamente à classe e apenas referencia- resdrawables para imagens (essas podendo ser
sub- layoutraw values
elementos de estilo e interface que serão usados repetidamente como textos,
cores, dimensões entre outros. Assim, cada um dos arquivos de recurso
definidos podem ser acessados das Activities a partir da classe de recurso
gen
serve como container para objetos a serem transferidos entre Activities.
31
layout como
R.layout.nomedoarquivo drawablesR.drawable.nomedoarquivo
Outros recursos podem ser definidos internamente a um arquivo de
id , em somente
um arquivo de recurso, podemos criar uma tela inteira da maneira que
desejarmos para, então, construirmos a lógica por trás dos elementos de
interface na classe que referenciará esse arquivo de recurso.
Figura 16: Exemplo de uso comum de recursos externos da Classe
5.2 Descrição do Sistema CNet-M Visto os elementos principais de um projeto Android, podemos entender
melhor a estrutura do sistema do CNet-M através do estudo do Fluxo de Telas,
módulos principais, descrição das telas, funções do aplicativo e interações com o
usuário, abordagens e decisões de projeto referente a programação de
determinadas funcionalidades.
32
Figura 17: Hierarquia de módulos e código fonte do CNet-M
5.2.1 Fluxo de Controle das Telas do CNet-M O diagrama de fluxo das telas decorreu de forma direta da conclusão do
estudo de GUI e das prováveis relações entre as telas com base em suas
funções. Assim, o seguinte resultado foi obtido:
33
Figura 18: Fluxo geral de telas do CNet-M
Ao analisarmos o fluxo de telas e as classes de Activities criadas no projeto
(são aquelas nos pacotes com nome terminando em .activities) mostradas nas
imagens anteriores, vemos que cada tela é relacionada diretamente a uma
Activity diferente com funções distintas. A navegação entre as telas foi pensada
aparelho para retornar a tela anterior (algo que nem sempre é natural ao usuário
[23]
incluso na interface de maneira a facilitar o uso desta função.
5.2.2 Módulos No CNet-M, os módulos criados caracterizam-se por tratarem de
funcionalidades muito distintas, serem altamente desacoplados e extensíveis.
Observando a divisão de pacotes da Figura 17, vemos que há um pacote
lac.infopae.contextnet.mobile -se a implementação da
classe de Aplicação (a ser explicado mais a frente) e outras classes de uso
comum às demais, dois pacotes de Activities referente as telas e três outros
34
pacotes com funções diversas. Cada um destes últimos pacotes representa um
módulo separado da aplicação.
5.2.2.1 Comunicação
lac.infopae.contextnet.mobile.sddlcaracteriza-se por tratar das funcionalidades de Conexão com um Gateway,
implementação de um Listener de Mensagens do Controlador (estas podendo
ser de outros nós móveis, repassadas do Controlador para o aplicativo), Tarefas Assíncronas referentes a mudanças de conexão e envio de mensagens para o
Controlador (como mensagens de Chat e de Inspeção) e Tarefas Síncronas
referente a envios constantes de informação (como dados de contexto). As
classes referentes às tarefas assíncronas e seu modo de implementação serão
explicadas mais adiante.
Os tipos de mensagens assíncronas enviáveis para o Controlador são
Mensagens de Chat (seu envio é implementado pela ChatMessageTask) e
Mensagens de Inspeção (FormMessageTask). As Mensagens de Contexto,
sendo síncronas (são enviadas a cada três segundos), têm seu envio
implementado pelas classes MyTruckContextTask (dados de geolocalização
reais) e pela MyTruckSimulatorTask (dados simulados).
5.2.2.2 Modelos e informações
O módulo de modelo de dados e informações de POIs
lac.infopae.contextnet.mobile.info assemelha-se mais a uma biblioteca de
modelo de dados que um módulo por si só, já que o mesmo não implementa
uma funcionalidade especifica. A partir dele, outras classes podem acessar
modelos comuns de Serializaveis (classes enviáveis como Message pela
CNCLib) como os tipos de mensagem de contexto a serem enviadas (podendo
haver implementações diferentes com dados distintos) e os tipos de eventos de
POIs que o aplicativo interpreta (tornando essa funcionalidade muito extensível,
já que para criar um POI novo basta criar uma classe nesse pacote estendendo
EventInformation).
Outras classes definindo modelos de dados usadas pelo CNet-M
encontram-se em um projeto separado, o ARFF_Library, que faz parte da
Aplicação ContextNet e que define modelos comuns à todos as partes da
aplicação. A ideia é que, futuramente, todos os modelos de dados
compartilhados pelas aplicações do ContextNet sejam movidos para o
ARFF_Library (mais detalhes na Seção 7.2).
35
5.2.2.3 Manipulação de XML
lac.infopae.contextnet.mobile.form s
de leitura e interpretação de arquivos XML. Enquanto a classe XMLHandler trata
da leitura do arquivo XML e da criação do objeto Document para interpretação, a
classe FormReader tem métodos específicos de interpretação e armazenamento
dos dados do Document para a criação dinâmica das telas de formulário com
base nos dados obtidos.
Este módulo também tem possibilidade de extensão relativamente simples,
já que podemos criar outros Readers além do FormReader caso fosse
necessário interpretar outros tipos de arquivos XML, desde que seguido o
modelo do mesmo.
5.2.3 Telas e Funcionalidades Interação e I/O com o aplicativo Como já mencionado, as funções principais do CNet-M foram divididas
pelas Telas com base na usabilidade, I/O, interação e frequência de uso. Essa
divisão de telas com funções e layouts distintos caracterizou, também, a divisão
das Activities para cada tela, divisão essa que ocorreu da seguinte maneira:
5.2.3.1 Splash Screen
Ao abrirmos o aplicativo CNet-M, a primeira tela a ser mostrada é a Splash
Screen , que consiste em uma tela de apresentação do aplicativo com o logo
criado para o mesmo assim como o logo do LAC.
36
Figura 19: Tela inicial com logo da aplicação e do LAC
Apesar de ser uma tela de apresentação, é nela que funções importantes
de inicialização do aplicativo ocorrem como o carregamento dos dados de
configuração salvos e a criação de elementos a serem usados pelas próximas
telas. Essa rotina inicial ocorre em tempo de execução e, quando finalizada, é
carregada a próxima tela, a de Mapa.
a mesma caso a Activity de mapas seja finalizada, o que não é necessário.
método onRestart() fosse chamado.
5.2.3.2 Map Screen
nela que um usuário poderá acompanhar sua localização no mapa, compartilhar
ju
já que ela sempre decorre após a inicialização do mesmo.
37
Figura 20: Tela de mapa com perspectiva de botões aberta
Sendo ela a primeira tela passível de interação do CNet-M, é nela que
ocorre a tentativa de conexão com um Gateway. A Activity checa se existe um IP
já cadastrado para essa aplicação, caso não exista, significa que é a primeira
vez que o CNet-M está sendo executado no aparelho alvo e que o aplicativo
provavelmente esta sendo manuseado por um gerente técnico. Assim, a
seguinte caixa de dialogo é apresentada:
Figura 21: Caixa de dialogo de Identificação e Conexão para o protótipo do CNet-M
Desta forma, o gerente pode incluir uma Tag (rótulo) de Identificação para
este cliente (que pode ser modificada na tela de Configurações como veremos
mais adiante), o IP para conexão a um Gateway e um UUID específico para
38
identificação única do cliente móvel para o Controlador. Este último campo é
direcionado mais para o protótipo apresentado, de modo a facilitar a
demonstração de funcionalidades de comunicação entre os nós móveis. No caso
do aplicativo final, o UUID será gerado aleatoriamente quando o mesmo for
acessado pela primeira vez e, a partir da primeira conexão com o Gateway, o
UUID gerado é registrado ao Controlador como sendo pertencente a esse
aparelho específico.
Após o preenchimento desses dados, a Activity chama o método de
conexão definido na classe de aplicação (mais detalhes nas seções seguintes).
Este mesmo método de conexão sempre é chamado mesmo que nenhum IP
seja pedido, caso quando a caixa de dialogo de conexão não é mostrada (a
conexão é feita com um IP registrado anteriormente em outro acesso).
Para a conexão, é também registrado uma variável de Controlador de Mapa durante o onCreate() desta Activity, assim como a inicialização do
Gerente de Mensagens, ambos tendo suas referencias guardadas junto à
classe de aplicação. O gerente de mensagens, depois de inicializado, passa a
tratar todos os eventos de conexão e recebimento de dados para o CNet-M.
Quanto ao controlador de mapas, ele é implementado internamente ao CNet-M
através da classe MapController e tem diversos métodos de interação com o
Mapa mostrado na tela desta Activity como movimentação do ícone do cliente,
inclusão de ícones de POIs e gerenciamento das coordenadas de localização
sendo lidas. Ele é necessário à conexão, pois o mesmo é registrado junto ao
Listener da conexão para possibilitar acesso simplificado do gerente de
mensagens ao mapa, assim, facilitando a inclusão dos ícones de POIs e outros
eventos importantes identificados pelo Gerente.
Quanto à interação do usuário, há três botões flutuantes de acesso do
mesmo diretamente do mapa. Dado que esta tela tem como função principal o
acompanhamento da posição pelo mapa, foi decidido que os dois botões
referentes às funções de comunicação e compartilhamento ficariam escondidos
e apareceriam ao apertar de um botão extra, localizado ao lado dos dois. O
ocalizado na parte de baixo.
A funcionalidade de Chat para o protótipo é acessada a partir do botão
referente à mesma. Ao pressiona-lo, o usuário pode selecionar outros nós
móveis registrados em seu grupo ou o próprio Controlador a partir de uma lista
e, a a opção selecionada. Vale lembrar que
esta função é passível de melhorias futuras quando a API de Grupos da CNCLib
estiver pronta, podendo assim o nó móvel, de fato, escolher outros nós de
39
grupos que o mesmo esteja registrado, e não de uma lista de nós fixos.
A funcionalidade de Compartilhamento de POIs para o protótipo é
acessada através do botão referente e através de cliques longos na tela do
mapa. Pressionando-o, o usuário poderá selecionar um tipo de POI a ser
compartilhado (acidente, trafego, polícia, etc.) para, então, selecionar com quem
será compartilhado (no caso, com todos os nós do seu grupo ou com nós
específicos). O POI será referente à posição atual do cliente caso o
compartilhamento seja acessado pelo botão, ou será referente à posição
selecionada caso seja acessado por clique longo em um local do mapa.
-implementa o método chamado ao
pressionarmos o botão de voltar de modo a perguntar para o usuário se ele
deseja mesmo sair do CNet-M e finaliza a conexão e as tarefas sendo
executadas de maneira adequada.
5.2.3.3 Menu Screen
funcionalidades secundárias para um usuário Motorista porém necessárias para
um usuário Fiscal e, ao mesmo tempo, dar resposta ao usuário quanto ao estado
da conexão e das mensagens recebidas a partir da barra de status de conexão.
Figura 22: Tela de menu inicial do com botão para chat com o controlador na barra de status.
40
A partir do menu de dashboard
usuário pode facilmente acessar a tela de Mapas, dados sobre a Conexão,
Configurações do aparelho e o módulo de Formulários.
Dado que o usuário que deseje começar uma Inspeção de veículo a partir
do módulo de Formulários deseja ter o aplicativo conectado ao Controlador, o
direto com o Controlador,
outra funcionalidade desejada para esta tela. Mais detalhes sobre a Barra de
Status nas seções seguintes.
5.2.3.4 Connection e Configuration Screen
As telas de estado de conexão e configurações são acessadas diretamente
pela tela de menu.
Figura 23: Tela de Conexão durante tentativa de conexão
A tela de conexão tem funcionalidades simples. O usuário que acessa-la
poderá visualizar e mudar o estado da conexão (desconectar ou conectar a outro
IP, este será guardado no lugar do anterior) assim como visualizar o IP
conectado no momento. O layout que contém os elementos é atualizado sempre
que ocorre alguma mudança na conexão. Essa tela foi criada também com o
41
intuito de ser extensível, de modo que a adição de outros elementos que
descrevam a conexão seja simples.
Figura 24: Tela de Configurações do aplicativo com acesso ao log de mensagens e outras
preferências
A tela de configurações foi idealizada de modo que disponibilizasse
edição de informações importante da aplicação como, para o protótipo criado,
uma opção de uso ou não do simulador de coordenadas e Tag usado para
identificação do cliente móvel na tela do Controlador. Há também opção de
acesso ao Log de mensagens, que apesar de ser uma funcionalidade mais
técnica, é muitas vezes útil para verificar as coordenadas que estão sendo
mandadas e quantas reconexões houve ao Gateway, por exemplo.
É notável, também, a presença da Barra de Status na tela de
configurações, já que o estado da conexão e a possibilidade de conversa com o
Controlador continuam sendo relevantes mesmo nessa tela. Isso não ocorre no
caso da tela de Conexão, já que a mesma já disponibiliza o estado da conexão
por si própria e, no caso de novas mensagens do Controlador, uma caixa de
diálogo é aberta.
Mais detalhes sobre o modo que as preferências são salvas serão vistos
nas seções seguintes.
42
5.2.3.5 Chat Screen
A tela de Chat foi criada de maneira a ser genérica para comunicação
textual com o Controlador ou outros nós móveis.
Figura 25: Tela de Chat com o Controlador
A estrutura da tela é bem simples, sendo composta de um layout para as
mensagens trocadas com o destinatário, este que atualiza em tempo real com as
mensagens novas, uma caixa de texto editavel para escrever mensagens e
botões de envio e retorno. As mensagens trocadas com o destinatário são
persistentes durante a execução da aplicação, ou seja, só até o aparelho
desligar ou o aplicativo for fechado.
A função de chat pode ser acessada a partir da tela de mapa, através do
botão flutuante e da seleção do destinatário ou através do botão de chat com o
Controlador na barra de status em todas as telas que contém a mesma. Ao
recebermos uma mensagem nova, enquanto a mesma não for visualizada, o
ícone de mensagem da barra de status ficará com uma cor diferente.
Figura 26: Barra de Status com ícone de mensagem nova circulado em vermelho
Da mesma forma, se recebermos uma mensagem em uma tela que não
43
tenha barra de status, uma caixa de dialogo surge avisando sobre mensagem
nova, dando opção de abrir a tela de chat com o remetente ou ignorar.
Independente da opção, a mensagem é armazenada e pode ser vista mais tarde
ao abrir a tela de chat referente ao usuário em questão.
5.2.3.6 Inspection Screens
Durante a concepção das telas de inspeção e formulários, foi decido que o
formulário seria mostrado na tela uma seção de cada vez, e não como um todo,
pois a segunda opção poderia implicar em dificuldades de visualização e
manipulação do aplicativo se o mesmo estivesse executando em um aparelho de
tela média ou pequena. Além disso, de modo que a resposta para o Controlador
fosse em tempo real, ou seja, a medida que o formulário fosse sendo preenchido
e suas seções enviadas, o Controlador teria sua visualização do mesmo
formulário sendo modificado, faz mais sentido o envio de pequenas mensagens
com seções do formulário do que uma grande mensagem com o mesmo já
completo.
Figura 27: Diagrama de telas de uma Inspeção comum
44
Deve ser reinterado que a implementação atual da funcionalidade de
construção dinâmica e envio de dados de formulário é meramente um modelo do
que o a implementação possibilita. Assim, o cliente móvel ainda não pode
receber um formulário de inspeção ou de qualquer outro tipo diretamente do
Controlador7, mas pode interpretar e exibir formulários definidos por Arquivos Descritores de Formulário na memória interna do aparelho. Assim, até certo
ponto, a aplicação de fato está recebendo dados diversos de formulário e
interpretando-os, mesmo que não seja automaticamente ou em tempo real.
Desta forma, o modelo desenvolvido também possibilita o preenchimento
automático de campos do formulário, já que estes têm identificadores próprios
que podem ser interpretados e relacionados a dados que o aplicativo já tem,
afinal, é possível que aja identificadores comuns a todos os formulários que não
necessitem de input do usuário.
Na primeira tela da inspeção que abre assim que selecionamos a opção
Formulários do Menu Principal, a MainFormActivity, o usuário deverá selecionar
o local que a inspeção será realizada antes de avançar para a próxima tela. Ao
entrar nessa tela, um Número de Registro de Inspeção de cinco dígitos é
gerado aleatoriamente, este sendo o identificador para esta inspeção. A
inspeção é finalizada quando o usuário sai desta Activity, de volta para o Menu
Principal, ou seja, no onDestroy() da mesma, independente da inspeção ter sido
completada de fato, através do envio de uma mensagem de inspeção do tipo
InspectionInformation (a ser explicada nesta seção mais adiante) com um
identificador específico. Ao selecionar avançar para a próxima tela, o diretório
onde os arquivos descritores de formulário encontram-se é pesquisado na
memória interna do aparelho e, caso não encontrado, um mensagem de erro
surge indicando a impossibilidade de continuar a inspeção.
Foi escolhido que arquivo descritor de formulário seria um arquivo de XML
pela facilidade de representação de dados com atributos diversos, no caso,
inspeção de um tipo de veículo, através de simples Tags organizadas
hierarquicamente (Figura 28). O arquivo tem basicamente dois tipos de tags, as
tags de Seções do formulário (<label>) e as tags de campos do formulário
(<item>), estes pertencentes à labels. Esse arquivo é inserido manualmente na
memória interna do aparelho executando o CNet-M e é lido pelo módulo de
leitura de XMLs de maneira que suas Tags sejam guardadas em memória, de
modo a facilitar seu acesso posterior pelas Activities que compõem a inspeção. 7 Mais informações em melhorias futuras, Seção 7.2.
45
Na segunda tela, a VehicleTypeActivity, o inspetor selecionará o tipo de
veículo que deverá ser inspecionado. Ao selecionar o tipo de veículo, a Activity
procura se o arquivo descritor de formulário referente a este veículo encontra-se
na memória interna do aparelho e, caso não se encontre, avisa o usuário através
de uma mensagem sobre a impossibilidade de abrir o formulário para o veículo
selecionado. Encontrando o arquivo, a Activity então aciona a classe do módulo
de leitura de XMLs específica para a leitura de arquivos de formulário, a
FormReader, esta que interpreta e mantém em memória os dados do arquivo.
É correto comentar que todas estas opções selecionadas durante o avanço
das Activities pré-visualização do formulário são guardadas e repassadas de
uma Activity para a outra juntamente com seu identificador pois, chegando na
última tela, a que representa uma seção específica de um formulário, esses
dados podem ser relacionados a campos do formulário com os mesmos
identificadores. Essa lógica é direcionada a funcionalidade de preenchimento
automático de seções dos formulários.
Figura 28: Exemplo de XML descritor para um Ônibus8. Seção marcada visualizável na Figura 29.
Após isto, a terceira tela é acionada, a FormActivity. Esta tela, já em sua
criação, recupera a referencia dos dados do arquivo de descrição de formulário e
identifica as Tag
independentes do formulário que serão enviadas em sequencia de completude
para o Controlador. Assim, a terceira tela mostra a lista de seções do formulário,
dando ao usuário a opção de escolher que seção preencherá primeiro. Ao
selecionar a seção, a quarta tela é acionada, a Activity chamada Dynamic.
8 Regras de geração do XML de formulário descritas no Apêndice C.
46
A última tela trata os campos de uma seção de um formulário. A tela cria,
em um layout definido internamente à Activity, vários elementos de layout do
Android referentes aos campos de uma seção do formulário. Além do tipo, esses
campos tem certas características de layout definidas no arquivo descrito. Dessa
forma, obtemos um resultado interessante nessa construção dinâmica (daí o
nome da classe) da seção do formulário.
Figura 29: Tela do formulário-exemplo de Ônibus, seção realçada na Imagem 28.
Ao clicarmos em enviar, uma mensagem de InspectionInformation com as
informações referentes a esta seção do formulário, identificador da seção, os
dados do Inspetor, horário de envio e número de registro de inspeção é enviada
usando a tarefa assíncrona FormMessageTask (a ser explicada mais adiante). O
visto no exemplo
prático na Figura 30.
Figura 30: Mensagem enviada referente à seção descrita
47
Sendo a mensagem enviada com sucesso, o inspetor volta à tela de
seleção de seções para continuar a inspeção, e isso prossegue até que o
mesmo saia da inspeção, voltando ao menu principal (a mensagem enviada para
identificar o fim da inspeção é uma mensagem normal de formulário com
identificador de seç -1 ). Se a mensagem não puder ser enviada por
quaisquer motivos, a mesma é guardada em uma fila de mensagens não
enviadas pela classe de aplicação do CNet-M, sendo enviada quando retomada
a conexão.
Finalizando, este conjunto de Activities engloba todas as funcionalidades
referentes à interpretação e envio de dados de inspeção/formulários propostas.
Um adendo a ser feito é que, infelizmente, devido à complexidade de se tratar
construção de layouts dinâmicos e com tantas possibilidades de distinção, o
layout dessas Activities foi planejado somente para um tipo de resolução de tela
(média) e orientação (portrait). Assim, as telas referentes à inspeção não ficarão
com layout ideal em tablets com alta resolução ou com orientação landscape,
por exemplo. Vale lembrar que esta conversão de telas para várias resoluções e
orientações não é impossível, só consideravelmente trabalhosa e, assim, acabou
ficando em segundo plano perto das outras demandas do CNet-M.
5.2.4 Decisões de Projeto e Desenvolvimento A lógica por trás de muitas funções fundamentais do CNet-M deriva de
conceitos técnicos e estratégias na maioria das vezes simples. Algumas dessas
abordagens serão discutidas adiante.
5.2.4.1 Extensão da Classe de Aplicação do CNet-M
A classe Application em Android é uma classe base para mantermos
estados e instâncias globais ao aplicativo, ou seja, para dar acesso a métodos e
conjuntos de dados interessantes a todas as Activities do aplicativo.
Assim, é na extensão de Application do CNet-M (App) onde elementos
como o Gerente de Mensagens e o Controlador de Mapa são registrados
quando criados, podendo assim ser acessados por outras Activities. É lá
também que é guardada a fila de mensagens não enviadas, o pilha de
mensagens recebidas, o mapeamento de log de mensagens de um usuário com
o seu identificador, referencia ao leitor de Formulário FormReader além dos
métodos de atualização de preferências, criação de tarefas assíncronas para
envio de mensagens, gerenciamento da conexão a partir da tarefa específica,
construção das caixas de dialogo comuns a varias Activities e referencia ao
48
contexto de uso atual para atualização externa de interface, entre outras
funções.
Sumarizando, a classe App caracteriza-se por ser uma classe de controle
de fluxo de dados dentro do aplicativo, sendo de suma importância para o
funcionamento do mesmo.
5.2.4.2 Tarefas Síncronas e Assíncronas
A necessidade de tarefas assíncronas para o controle de eventos não
automáticos relacionados à conexão veio de uma sugestão de boa prática de
programação por parte dos próprios desenvolvedores do Android que acabou se
tornando obrigatória, o gerenciamento de serviços de conexão vindo da Thread
principal.
Dado que a conexão com um Gateway é feita a partir de uma
implementação da interface NodeConnection, para mantermos referencia dessa
conexão de modo a mudar o estado da mesma, registrar Listeners ou enviarmos
dados por ela, precisamos cria-la a partir de um escopo global, no caso, a classe
App. Porém, como pode ser observado, rotinas no App continuam sendo na
Thread principal, então esta solução não funciona.
Assim, a partir da classe AsyncTask (um Runnable) do Android, é
estendida uma classe que executa em uma Thread secundária um determinado
método de manipulação de conexão. O envio de mensagens, de diversos tipos
(a partir de ApplicationMessage, implementação da interface Message da
CNCLib), por exemplo, é uma aplicação comum de tarefa assíncrona. As classes
de referentes a estas tarefas são:
- ChatMessageTask: Criada sempre que desejamos enviar uma mensagem
de Chat para algum destino no domínio. O objeto registrado na
ApplicationMessage é uma String composta pelo UUID do remetente e o
conteúdo da mensagem. Trata o sucesso ou não do envio mostrando a
mensagem ou não na caixa de mensagens atual.
- FormMessageTask: Criada sempre que enviamos uma mensagem de
Inspeção, como já explicitado anteriormente. O objeto enviado internamente ao
ApplicationMessage é um InspectionInformation com todas as informações de
inspeção necessárias para a identificação da mesma. Trata o sucesso ou não do
envio mostrando incluindo a mensagem ou não na fila de mensagens não
enviadas.
- FinalizeConnectionTask: Como o tratamento de desconexão envolve
modificação de um item de GUI (barra de status) assim como a modificação do
49
estado da conexão em si, o mesmo deve também ser tratado em uma Thread
secundária através de uma tarefa assíncrona. A tarefa simplesmente finaliza a
conexão atual se houver, assim como o envio de dados de contexto (simulado
ou não).
- ConnectionTask: Criada sempre que há uma tentativa de conexão a um
IP dado. Não gerencia reconexões, apenas conexões diretas através da criação
do NodeConnection e do registro dos listeners necessários. Não trata o sucesso
ou não da conexão, pois o mesmo já é tratado pelo gerenciador de mensagens,
pois este também gerencia troca do estado das conexões, mas verifica em
tempo de execução se a mesma foi bem sucedida apenas para fins de registro
da Tarefa Síncrona de Envio de dados de Contexto.
Quanto a tarefas síncronas ou planejadas, temos dois tipos no CNet-M, o
envio de dados de contexto simulados e de dados de contexto reais. As tarefas
também executam em uma Thread secundária, com a diferença de serem
síncronas, ou seja, executam repetidas vezes a partir de sua criação, sempre em
intervalos de tempo contínuos (três segundos no caso). Ambas enviam dados do
tipo Inspector, este contendo dados de localização (latitude/longitude),
velocidade atual, entre outras informações de identificação. Apesar do nome
referente ao uso do inspetor, a classe é usada como modelo para envio dos
dados independente de ser o Motorista ou o Inspetor o usuário atual.
Essas tarefas também têm uma referencia a classe MapController de modo
que possa atualizar o ícone de localização no mapa, por exemplo, além de
enviar os dados de contexto em si para o Controlador. Ambas tem a mesma
estrutura, com a diferença de onde as mesmas captam os dados de contexto, de
métodos aleatórios ou a partir do gerente de localização do Android.
5.2.4.3 Simulação de Dados de Context e de Localização
Os dados enviados pelas tarefas de envio de dados de contexto, como já
dito anteriormente, podem ser simulados ou reais, baseado na preferência do
usuário selecionada na tela de configurações.
A construção do gerente de localização para envio de dados reais foi feita
em conjunto com os últimos testes, já que a mesma era bem independente do
restante do aplicativo. Este gerente tem sua referência salva no App, assim,
tendo seu acesso simplificado pela classe de envio de dados de contexto, que
apenas captura os dados lat/long através de métodos simples. A velocidade
enviada ainda é gerada aleatoriamente.
50
Já no caso da simulação dos dados, a tarefa de envio de dados de
contexto simplesmente gera dados aleatórios de lat/long baseado em um padrão
de movimentação simples, assim como a velocidade. Esses dados aleatórios
são gerados por uma classe TruckContext, que gerencia esses elementos.
5.2.4.4 Elementos de layout persistentes Barra de Status
Dado a necessidade de acesso de certos elementos do aplicativo de
quaisquer telas do mesmo, foi idealizada uma maneira discreta de manter essas
funções ao usuário, informando-o de maneira não intrusiva. Isso foi feito através
da inclusão de uma Barra de Status recorrente.
A barra de status (Figura 26) trata de dois elementos principais, o status
atual da conexão e um ícone clicavel para comunicação com o Controlador,
sendo este também um agente de status, pois ele troca de cor se houver
mensagens novas.
A expressão do estado desses elementos é de grande importância em
praticamente todas as telas do aplicativo, por isso sua persistência. Além disso,
vale lembrar que tanto o estado da conexão quanto o recebimento de
mensagens ocorrem a partir do Gerente de Mensagens, paralelamente à
interação do usuário e independentemente à tela corrente do usuário.
5.2.4.5 I/O - Caixas de Dialogo, de Texto
Em Android, há incontáveis formas de representarmos ouput de dados na
tela ou pedirmos algum tipo de input. Algumas usadas no CNet-M foram:
- Caixas de Texto: Um tipo de Widget (elemento singular de interface)
comum em Android (EditText) onde o usuário pode digitar algum tipo de texto.
Podemos ainda limitar a quantidade de caracteres e/ou definir o tipo de input
(texto, números, etc). Essa possibilidade de customização do tipo de input foi
especialmente usada em Dynamic, durante a criação do layout de uma seção de
formulário.
- Caixas de Dialogo: As mais comuns, apresentando uma View para um
usuário, esta normalmente com textos e caixas de texto. Através dela, podemos
pedir e representar dados para um usuário sem mudar de Activity e nem interferir
muito na visualização da tela atual do usuário.
51
Figura 31: Caixa de dialogo para reconexão
- Toasts: São elementos textuais flutuantes do Android, bem úteis para um
feedback visual informativo para o usuário de eventuais eventos do aparelho
como quando a conexão for bem sucedida, quando uma mensagem não pode
ser enviada, entre outros.
5.2.4.6 Persistência Dados de Configuração e de Usuário
No Android, há várias maneiras diferentes de persistirmos dados de
aplicativos, mesmo que o mesmo seja fechado ou o aparelho desligado. Por
tratarmos de alguns pouco dados textuais simples, foi optado por usar o conceito
de SharedPreferences do Android. Nessa abordagem, guardamos em arquivos
de configuração padrões do Android, duplas de dados com identificador definido
e o dado, podendo ser textual ou booleano. Os dados guardados nas
preferências do CNet-M de acordo com seus identificadores são:
- Dado booleano indicando se os dados de contexto serão
coletados do simulador (true) ou do gerente de localização (false) (editavel na
tela de configurações);
- Dado textual indicando o tag escolhido para identificar o
cliente junto ao Controlador (editavel na tela de configurações);
- Dado textual indicando número de registro corrente da
inspeção (editavel a cada nova inspeção, na tela de formulários);
- Dado textual indicando o IP de conexão já formatado para
uso da implementação do NodeConnection (editavel quando ocorre uma
mudança no estado da conexão, na tela de conexões ou de mapa);
- Dado textual indicando o UUID já formatado para este cliente.
Após selecionado, vira permanente deste cliente (editavel somente no primeiro
acesso a aplicação, na tela de mapa).
Com a instancia desse registro de preferências guardada no App, é fácil
para qualquer Activity recuperar ou editar os dados dessas preferências caso
deseje.
52
6 Testes e Avaliação de Usabilidade do Aplicativo 6.1 Planejamento e execução de testes funcionais O planejamento dos testes funcionais da Aplicação Distribuida ContextNet
basearam-se em um ideal bem simples. Dado que todos os objetivos da mesma
já estavam bem traçados, bastou que houvesse testes contínuos em conjunto
durante o desenvolvimento das aplicações Controlador ARFF e CNet-M, já que o
uso de um depende muito do outro. Dessa forma, a medida que as
funcionalidades principais eram desenvolvidas, havia nivelamento dos modelos
de dados usados, além de troca de informações relacionadas ao I/O com o
usuário e formatos de mensagem.
Essa forma de realização de testes conjuntos foi extremamente importante
para o desenvolvimento do CNet-M pois, caso o desenvolvimento do mesmo
fosse isolado, problemas de compatibilidade e detalhes de envio de mensagens
que não podem ser simulados sem um Controlador não seriam identificados,
tornando os testes de uso do CNet-M pouco úteis.
Tanto o Controlador ARFF quanto o próprio middleware de comunicação
também tiveram suas funcionalidades bem testadas através de, por exemplo,
testes de múltiplas conexões com aparelhos e emuladores conectados a
Gateways distintos, estes repassando as informações para o Controlador. Os
testes de comunicação, escalabilidade e estabilidade do SDDL estão bem
explicitados nos artigos relacionados ao tema referenciados ao fim deste
trabalho [20][24].
6.2 Planejamento e execução de testes com usuários Foi escrito, juntamente com a finalização da primeira versão da GUI, uma
entrevista direcionada a um usuário do CNet-M com perguntas referentes a GUI,
além da disponibilização de espaços para sugestões. No texto introdutório da
entrevista, há uma pequena descrição do objetivo do aplicativo e como, por
quem e em que situação ele será usado. É pedido para o usuário se botar no
lugar do usuário referente a cada pergunta. A entrevista em si pode ser
encontrada no Apendice D deste trabalho.
O objetivo desejado para esta entrevista qualitativa era obter um feedback
de usuários leigos sobre a utilização do aplicativo, assim, verificando se o
mesmo pode ser usado com facilidade ou não após explicado uma única vez,
assim como descobrir se as decisões em relação a I/O e interação com os
elementos do aplicativo são bem recebidas e, se não, que outras abordagens
53
poderiam substituir as atuais.
Para a realização da entrevista, bastou um aparelho executando CNet-M
disponível para o entrevistado, juntamente com uma cópia do questionário de
feedback e a presença do entrevistador para sanar possíveis dúvidas de uso do
aplicativo. A ordem de ações para a realização da entrevista era o usuário ler o
texto introdutório e sanar quaisquer duvidas com o entrevistador, em seguida
começar a usar o CNet-M a partir da tela inicial de mapa para responder as
perguntas referentes a cada funcionalidade/tela. O próprio usuário manejava
tanto a entrevista quanto o CNet-M, tendo o entrevistador por perto somente
para sanar possíveis dúvidas. As perguntas encontravam-se em uma ordem
especifica para facilitar a navegação entre as telas ao mesmo tempo da
realização da entrevista. Sempre após uma pergunta respondida, o usuário era
questionado sobre sugestões que o mesmo poderia dar para melhorias
referentes à questão. Ao término das perguntas, era pedido alguns dados
básicos como idade, nível técnico, se dirige ou se comunica textualmente com
aparelhos portáteis.
Os resultados alcançados foram interessantes. De fato, houve um bom
feedback e muitas sugestões, especialmente a respeito de funcionalidades
anteriormente pensadas e que serão comentadas em melhorias futuras (Seção
7.2). Exemplos de comentários importantes foram:
- O fato de a caixa de dialogo de identificação e conexão aparecer
inicialmente quando entramos no aplicativo pela primeira vez, pois não estava
claro que a mesma seria, na verdade, preenchida por um técnico, e não um
motorista, que provavelmente não teria conhecimento técnico para executar
essa função;
- Que os ícones da menu principal poderiam cobrir a maior parte da tela,
estão pequenos;
- Falta de resposta sonora de seleção de opções;
- Falta de dinâmica na barra de status quando o aplicativo está conectando
(resposta visual);
- Falta da necessidade do botão que esconde/mostra os botões de
comunicação e compartilhamento de POIs no mapa;
- Aproveitamento de gestos para funções na tela de mapas.
Algumas dessas sugestões se encaixam bem como melhorias futuras,
outras podem ser consideradas falhas de design, pois poderiam ter sido
pensadas durante a idealização da GUI. No geral, os resultados da pesquisa
54
foram positivos, com a maioria dos entrevistados considerando a GUI bem
construída. Assim, podemos concluir que o objetivo da entrevista de feedback foi
alcançado, pois foi comprovado que o uso do CNet-M por usuários leigos é
viável, apesar de haverem certos detalhes a serem acertados e melhorias
futuras a serem desenvolvidas para o CNet-M se tornar, de fato, ideal.
6.3 Comentários sobre o desenvolvimento A aplicação distribuída ContextNet é um projeto que esteve em
desenvolvimento conjunto com o CNet-M, e ainda está. Assim, devido ao
desenvolvimento conjunto do CNet-M com o Controlador, foi possível definir
demandas de funções e outras necessidades rapidamente durante o
desenvolvimento. Porém, apesar do CNet-M ter suas funções definidas desde o
inicio deste trabalho, o Controlador ARFF estava em constante processo de
mudanças durante o desenvolvimento. Desta forma, muitas das suas funções
foram definidas tardiamente, o que refletia diretamente no desenvolvimento
concomitante e planejamento do CNet-M. O mesmo ocorreu com a CNCLib, o
que refletiu até mais diretamente nas funções do CNet-M, havendo a
necessidade de corte de uma delas, a subscrição de eventos de grupos,
comentada como um dos objetivos deste trabalho, porém não realizado devido a
não finalização da API de grupos prevista no middleware ContextNet para a
CNCLib.
Também, o fato do CNet-M ser um software desenvolvido em cima de um
protótipo fez necessário um certo refactoring do código. Isto junto à necessidade
de lidar com bibliotecas distintas gerou alguns problemas em relação ao
ambiente de desenvolvimento, mas nada que não fosse resolvido após alguma
pesquisa.
Outro problema foi a dificuldade do tratamento de mudanças de orientação
e layouts variáveis com a resolução do aparelho. Uma das propostas do CNet-M
era que ele fosse facilmente adaptável a telas de diversos aparelhos e
orientações, e de fato ele é, porém não para todas as telas e nem sempre da
maneira correta. Esta mudança não seria particularmente difícil de ser realizada,
é somente bem trabalhosa, pois requer a recodificação das telas para cada
resolução/orientação desejada. Assim, durante o desenvolvimento, houve
tarefas prioritárias que acabaram por fazer esta não ser realizável.
Além destes empecilhos, o desenvolvimento em geral ocorreu sem muitos
transtornos e pode-se dizer que o resultado alcançado foi bastante adequado.
55
7 Considerações finais 7.1 Fechamento Concluindo este trabalho, o aplicativo ContextNet-Mobile desenvolvido
em conjunto com o Controlador ARFF, formando a aplicação distribuída
ContextNet, caracteriza-se por ser um exemplo de aplicação para o middleware
ContextNet e, de fato, alcançou os objetivos desejados com sucesso. O CNet-M
atual, mesmo sendo um protótipo, está pronto para ser usado em campo por
fiscais ou motoristas com todas as funcionalidades propostas funcionando
corretamente e, inclusive, já foi demonstrado para uma empresa de
rastreamento de frotas junto ao Controlador_ARFF em Novembro 2012.
Assim, apesar do CNet-M ter seu uso direcionado à tipos específicos de
usuários e uma proposta clara, o mesmo também adequou-se como exemplo de
aplicação móvel compondo uma aplicação distribuída baseada no ContextNet.
Com isso, este trabalho pode ser usado como guideline para o desenvolvimento
de outras aplicações móveis distribuídas para o ContextNet.
7.2 Melhorias Futuras Foram identificadas como melhorias futuras e funcionalidades não
desenvolvidas ou passiveis de melhoramentos os seguintes tópicos:
- Possibilidade de transformação do CNet-M em um framework para
desenvolvimento de aplicações móveis distribuídas para o ContextNet devido
sua alta adaptabilidade e potencial de extensão;
- Desenvolvimento do recebimento de mensagens de formulário pela
rede, ao invés da necessidade de incluirmos manualmente um arquivo descritor
de formulário na memória interna do aparelho. Com isso, as funcionalidades de
formulário serão também melhor aproveitadas para o usuário motorista, ao invés
de somente do usuário fiscal;
- Melhorias nas respostas às interações do usuário aos elementos de
interface e comando com o CNet-M. Dado o potencial que um aplicativo para
Android possui, o CNet-M poderia ter respostas visuais e sonoras mais
descritivas das ações que estão sendo feitas para o usuário;
- Inclusão de suporte a comandos de voz e gestos, dado que muitas
vezes, especialmente na tela de mapas, o usuário não poderá usar as mãos,
pois as mesmas estariam ocupadas, dirigindo por exemplo. Nesse caso, a
inclusão de comandos de voz melhoraria a acessibilidade dessas funções, e
suporte a gestos específicos poderia tornar a execução dessas funções mais
56
simples, não descartando a interação direta com a tela;
- A inclusão de subscrição de regiões e grupos a partir do suporte à API
de grupos do middleware;
- Expansão dos tipos, registro e interpretação real de dados de contexto
mais relevantes, incluindo velocidade, que ainda é simulada.
- Separação do módulo de modelo de dados do CNet-M para a biblioteca
de modelo de dados do ContextNet, a ARFF_Library.
8 Referências bibliográficas [1] Google Inc., Android Developers Guide Platform Versions
[http://developer.android.com/about/dashboards/index.html] (ultimo acesso em
Novembro 2012)
[2] IDC Corporate USA, Press Release - Android Marks Fourth Anniversary
Since Launch with 75.0% Market Share in Third Quarter, According to IDC
[http://www.idc.com/getdoc.jsp?containerId=prUS23771812] (ultimo acesso em
Novembro 2012)
[3] Google Inc., Google Developers Google Maps API
[http://developers.google.com/maps/mobile-apps] (ultimo acesso em Novembro
2012)
[4] CBS Interactive, Zd-Net - Smartphone for GPS Navigation is better than a
dedicated device [http://www.zdnet.com/blog/mobile-news/smartphone-for-gps-
navigation-is-better-than-a-dedicated-device/3055] (ultimo acesso em Novembro
2012) [5] Waze Ltd., Waze (3.0) [mobile application]. Waze Ltd. [http://www.waze.com/] (ultimo acesso em Novembro 2012) [6] NNG Global Services Kft., iGO Primo [mobile application]. NNG Kft. [http://www.igonavigation.com/] (ultimo acesso em Novembro 2012)
[7] Cynapse India Pvt. Ltd., Localscope [mobile application]. Cynapse Ltd. [http://www.cynapse.com/localscope] (ultimo acesso em Novembro 2012) [8] Garmin Wuerzburg GmbH, Navigon [mobile application]. Garmin Wuerzburg [http://www.navigon.com/portal/sites.html] (ultimo acesso em Novembro 2012) [9] MotionX Ltd., MotionX GPS Drive [mobile application]. MotionX Ltd.
[http://news.motionx.com/category/motionx-gps-drive/] (ultimo acesso em
Novembro 2012) [10] AOL Inc., MapQuest [mobile application]. MapQuest Inc. & AOL Inc. [www.mapquest.com] (ultimo acesso em Novembro 2012)
57
[11] MobWise Ltda., Wabbers [mobile application]. MobWise Ltda. [http://www.wabbers.com/] (ultimo acesso em Novembro 2012) [12] App Annie Ltd., The math behind the app stores [http://www.appannie.com/]
(ultimo acesso em Novembro 2012) [13] ColdFusioning
[http://www.coldfusioning.com/index.cfm/2010/11/10/How-Unique-is-a-UUID-
Should-we-use-them-instead-of-autoincrementing] (ultimo acesso em Novembro
2012)
[14] Gong, J., Tarasewich, P., 2004. Guidelines for handheld mobile device interface design. College of Computer and Information Science, Northeastern
University.
[15] Lee, Wei-Meng, 2011. BFULL COLOR. Indianapolis: Wiley
[16] Hinman [http://uxmag.com/articles/excerpt-from-the-new-book-the-mobile-
frontier] (ultimo acesso em Novembro 2012)
[17] Smashing Media, Smashing Magazine Finger-Friendly Design: Ideal
Mobile Touchscreen Target Sizes
[http://uxdesign.smashingmagazine.com/2012/02/21/finger-friendly-design-ideal-
mobile-touchscreen-target-sizes/] (ultimo acesso em Novembro 2012)
[18] How to Build a Dashboard Interface in android
[http://blahti.wordpress.com/2011/03/14/build-dashboard-ui-for-android/] (ultimo
acesso em Novembro 2012)
[19] Google Inc., Android Developers Guide Designing for Multiple Screens
[http://developer.android.com/training/multiscreen/index.html] (ultimo acesso em
Novembro 2012)
[20] L. David, R, Vasconcelos, L. Alves, R. Andre, G. Baptista, M. Endler, A
Communication Middleware Supporting Large scale Real-time Mobile
Collaboration, IEEE 21st International WETICE, Track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures (AROSA), pp. 54-59, Toulouse, June 2012 [21] -
[22] M. Endler, G. Baptista, L.D. Silva, R. Vasconcelos, M. Malcher, V. Pantoja,
and V. Pinheiro, ContextNet: Context Reasoning and Sharing Middleware for
Large-scale Pervasive Collaboration and Social Networking, Poster Session, ACM/USENIX Middleware Conference, Lisbon, December 2011. [23] Juhani, Android UI Patterns Blob Back Button
58
Hell? [http://www.androiduipatterns.com/2011/12/back-button-androids-achilles-
heel.html] (ultimo acesso em Novembro 2012)
[24] David, L., Vasconcelos, R., Alves, L., André, R., Baptista, G., Endler, M.,
2012. A Large-scale Communication Middleware for Fleet Tracking and
Management. Paper presented at the Simposio Brasileiro de Redes de Computadores e Sistemas Distribuidos (SBRC 2012), Salao de Ferramentas, May 2012, Ouro Preto, Minas Gerais, Brazil. [25] LAC PUC-Rio, 2011. Laboratory for Advanced Collaboration: ContextNet. [http://lac-rio.com/projects/contextnet] (ultimo acesso em Novembro 2012) [26] Sears, N., Horowitz, S., Morril, D., Wu, P., Tseng, E., Malchev, I., Cleron, M.,
Gustafsson, P., Swetland, B., Andersson, T. and Bauer, G., 2007. Android Overview. [http://www.openhandsetalliance.com/android_overview.html and
http://developer.android.com/guide/basics/what-is-android.html] (ultimo acesso
em Novembro 2012)
[27] Google Inc., Android Developers Guide Activity
[http://developer.android.com/reference/android/app/Activity.html#ActivityLifecycl
e] (ultimo acesso em Novembro 2012)
59
Apêncide A Gráficos de popularidade de aplicações de
navegação
60
61
62
Apêncide B Interfaces de conexão e troca de mensagens da CNCLib /* Any transmited data implements interface Message */
public interface Message extends Serializable {
/* gets the object sent */
public Serializable getContent();
/* returns all the tags of a message (strings) */
public List<String> getTagList();
/* returns the SenderID */
public UUID getSenderID();
}
/* Message Class example */
public class MessageObject implements Message {
/* the object */
private Serializable content;
/* A list of tags characterizing the object */
private LinkedList<String> tagList;
}
/* Interface to be implemented for the SDDL Connection */
public interface NodeConnection {
public void connect (SocketAddress endpoint) throws...;
public void disconnect
public int getNumberOfReconnections ();
public void sendMessage
public void addNodeConnectionListener (NodeConnectionListener lis);
public void removeNodeConnectionListener (NodeConnectionListener lis);
public void addSddlListener (SddlNetworkListener lis);
63
public void removeSddlListener (SddlNetworkListener lis);
public long getCreationTimestamp ();
}
/* Listener interface to be implemented */
/* Several callback methods for events occuring at a connection */
public interface NodeConnectionListener {
/* when connection is estabilished */
public void connected (NodeConnection remoteCon);
/** when the connection was broken and restored again:
* - wasHandover: if a handover occurred, i.e. if the current end point is
* different than the previous
* - wasMandatory: if it was a mandatory handover **/
public void reconnected (NodeConnection remoteCon, SockerAddress
endPoint, Boolean wasHandover, boolean wasMandatory);
/* when the connection is lost */
public void disconnected (NodeConnection remoteCon);
public void newMessageReceiver (NodeConnection remoteCon, Message
message);
/* when connection drops and there are sent messages without acks,
returned in unsentMessages */
public void unsentMessages (NodeConnection remoteCon,
List<Message> unsentMessages);
/* when an internal exception occurs in the RemoteConnection */
public void internalException (NodeConnection remoteCon, Exception e);
}
64
Apêncide C Regras de formação dos XMLs descritores de formulários Atributos dos itens:
'id': Identificador único do item;
'type': Tipo de input do item (tipos explicitados na próxima seção);
'name': Nome que aparecerá na tela;
'orientation': Orientação relativa do item referente ao item anterior;
'extra': Informação extra do item.
Tipos de input:
'varchar': Caixa para texto, linha única. Atributo 'extra' contém número de dígitos
máximo (0 é ilimitado);
'numeric': Caixa para números, linha única. Atributo 'extra' contém número de
dígitos máximo (0 é ilimitado);
'longvarchar': Caixa para Texto, multi linha. Atributo 'extra' não é utilizado;
'roller': Opções apresentadas em uma caixa de diálogo. Atributo 'extra' define as
opções.
65
Apêncide D Entrevista Qualitativa de feedback de usuários
Roteiro de entrevista para avaliação da usabilidade do aplicativo ContextNet Mobile
Esse aplicativo móvel foi desenvolvido para uso por duas classes de usuários: motoristas de veículos de uma frota, durante as suas viagens para transporte de mercadorias entre fornecedores e clientes, e fiscais de transito durante viagens e inspeções em veículos diversos. Através dele, o usuário deve manter contato com a central de operação/ monitoramento da frota - através do preenchimento de formulários (customizados pela transportadora) para acompanhamento, durante as paradas - bem como se comunicar com motoristas da empresa próximos, e também compartilhar com os demais colegas os eventos (ocorrências na estrada) na sua vizinhança. A aplicação será usada por esses dois usuários de maneiras ligeiramente distintas: o motorista ficará quase a totalidade do seu tempo na tela de acompanhamento de mapa, onde poderá se comunicar por mensagens ou compartilhar pontos de interesse com outros motoristas/central. Já o fiscal usará a aplicação como um todo, modificando configurações e acessando formulários de fiscalização, assim como se comunicando com a central. Um terceiro tipo de usuário, o Técnico, é o usuário que vai configurar a aplicação para ser usada pelo Motorista. Sendo assim, pedimos que você se coloque no papel de destes usuários dependendo da pergunta, e nesse contexto hipotético, avalie a usabilidade da Interface do Usuário desse software da forma mais objetiva possível e, possivelmente fornecendo sugestões para a sua melhoria. Muito obrigado pela sua valiosa ajuda! 1) [Fiscal/Técnico] Você acha que a tela de identificação:
é de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] é de fácil manuseio? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para elementos interface gráfica de controle melhores?
2) [Fiscal/Motorista] Você acha que a tela de menu (estilo dashboard) com os ícones para cada uma das funções do aplicativo:
é de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] é de fácil manuseio? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para elementos interface gráfica de controle melhores?
66
3) [Motorista] Você acha que a tela de mapa para visualizar/acompanhar a posição de outros ônibus/motoristas, bem como ver pontos de interesse na vizinhança:
é de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] é de fácil manuseio? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para outro tipo de interface para tal acompanhamento?
4) [Motorista] Você acha que a que os botões flutuantes com os tipos de pontos de interesse para sua marcação no seu recorte de mapa:
são de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] são de fácil seleção? [SIM/ NÃO / MAIS-MENOS] estão bem posicionados? [SIM/ NÃO / MAIS-MENOS] dão feedback de seleção adequado? [SIM/ NÃO / MAIS-MENOS] requerem pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para outro tipo de interface para tal seleção?
5) [Motorista] Você acha que a seleção e posicionamento de um ponto de interesse no mapa, com dois toques:
é de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] é de fácil execução? [SIM/ NÃO / MAIS-MENOS] fornece feedback adequado? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para uma forma de seleção e posicionamento melhor para esse contexto de uso?
6) [Fiscal] Você acha que a forma de apresentação das questões do formulário
(por seção) e de uma pergunta por tela:
são de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] são de fácil execução(a)? [SIM/ NÃO / MAIS-MENOS] fornecem feedback adequado? [SIM/ NÃO / MAIS-MENOS] são rapidamente executáveis? [SIM/ NÃO / MAIS-
MENOS] têm suas formas de entrada de dados e [SIM/ NÃO / MAIS-MENOS]
navegação como sendo simples e direta?
Teria alguma sugestão para tornar a forma de preenchimento de um formulário mais apropriada?
7) [Fiscal/Motorista] Você acha que a barra de status de conexão (na base da
tela):
é suficientemente descritiva? [SIM/ NÃO / MAIS-MENOS] fornece feedback adequado? [SIM/ NÃO / MAIS-MENOS] está bem posicionada? [SIM/ NÃO / MAIS-MENOS]
67
Teria alguma sugestão para melhorar a indicação do status da conexão?
8) [Motorista] Você acha que a forma de seleção do outro motorista para iniciar um chat:
é de fácil entendimento? [SIM/ NÃO / MAIS-MENOS] é de fácil execução? [SIM/ NÃO / MAIS-MENOS] fornece feedback adequado? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para melhorar a seleção do interlocutor do chat?
9) [Fiscal/Motorista] Você acha que a janela de chat:
é de fácil uso? [SIM/ NÃO / MAIS-MENOS] fornece feedback adequado? [SIM/ NÃO / MAIS-MENOS] requer pouca atenção? [SIM/ NÃO / MAIS-MENOS] está bem posicionada? [SIM/ NÃO / MAIS-MENOS]
Teria alguma sugestão para melhorar a interface para o chat? Algumas perguntas sobre você: - Idade: - Dirige com frequência? [MUITO/ POUCO / MAIS-MENOS] - Usa muitos aplicativos em [SIM/ RARO / MAIS-MENOS] smartphones/tablets? - Costuma se comunicar por texto [MUITO/ POUCO / MAIS-MENOS] (messengers/ redes sociais) através de seu smartphone?
Top Related