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?