Quick Start - SDDL Rio de Janeiro Dezembro de 2012

Transcrição

1 Quick Start - SDDL Rio de Janeiro Dezembro de 2012

2 Sumário 1. Introdução Configuração Java CoreDx Aplicação para demonstração Contexto da aplicação Módulos Controller Servidor Web Servlet API AJAX API de Mapas Android

3 1. Introdução Este documento é um tutorial para os desenvolvedores de aplicações baseadas no SDDL (Scalable Data Distribution Layer). O SDDL é um middleware de comunicação baseado no DDS que permite monitorar um conjunto de nós móveis (p.ex.smart-phones ou outros equipamentos móveis) em tempo real, bem como enviar mensagens de/para estes nós móveis. Os nós móveis poderão ter qualquer conexão wireless (WiFi, 2G/3G, etc), apenas assume-se que essa tecnologia wireless suporte o protocolo IP da Internet. Assume-se ainda que os nós móveis obtenham periodicamente sua posição geográfica e difundam esse dado e outros dados de contexto para uma estação controle (controller), no qual um operador pode visualizar a posição de cada nó, ver o seu status, e iniciar uma comunicação textual (chat) com cada um deles, bem como enviar notificações para todos ou um subconjunto de nós. Assim, o SDDL permite as seguintes formas de comunicação: unicast, groupcast e broadcast. Mais detalhes sobre o SDDL, podem ser encontrados os relatórios tecnicos [MCC 04/12, MCC 05/12, MCC 06/12] Será mostrado uma aplicação simples, com o intuito de facilitar o entendimento do middleware, mas que mostra funcionalidades interessantes para aplicações reais. É interessante que se tenha um conhecimento prévio do padrão DDS (Data Distribution Service), Ajax e Android. O objetivo da aplicação ARFF é exemplificar o uso da camada de comunicação SDDL do ContextNet. A aplicação possibilita o rastreamento e gerenciamento de uma frota de veículos e fiscais em tempo real. Estes atores são simulados, gerando atualizações periódicas de sua posição e possuem trajetórias pré-definidas. Na aplicação também é possível visualizar a movimentação dos veículos e fiscais em um mapa, bem como enviar mensagens em broadcast, groupcast ou unicast. A aplicação ARFF foi desenvolvida para demonstrar que o middleware SDDL é capaz de monitorar e prover comunicação confiável e eficiente para milhares de nós simultaneamente. 2. Configuração das Ferramentas 2.1. Java A escolha da linguagem Java foi feita pelo fato que, programas feitos nesta linguagem podem rodar em diferentes arquiteturas de computadores e em vários sistemas operacionais. É uma das linguagens de programação mais populares do mundo, bem aceita tanto no meio acadêmico como na indústria e existe uma enorme comunidade de desenvolvedores. Apesar do Java atualmente encontrar-se na versão 7, não foram usados comandos específicos desta versão, então o código é totalmente compatível com a versão 6. 3

4 2.2. CoreDX O CoreDX pode ser obtido através do link: Escolha a versão do Sistema Operacional (Linux, Windows ou Android) e descompacte em uma pasta. Uma licença de testes pode ser obtida, de acordo com seu SO, no link A configuração é simples, basta configurar as variáveis de ambiente: 1. COREDX_HOST = Sistema Operacional usado na máquina de desenvolvimento (Ex: Windows_x86_vs2008/Linux_2.6_x86_gcc43); 2. COREDX_TARGET = SO que rodará a aplicação (Ex: Android_2.2_armv5_gcc44); 3. COREDX_TOP = Pasta onde está o CoreDX (Ex: C:\coredx); 4. COREDX_IP_ADDR = Ip padrão usado pelo CoreDX (Ex: ); 5. TWINOAKS_LICENSE_FILE = Licença do CoreDX (Ex: C:\coredx\arquivo.lic) 6. PATH = Adicionar a pasta COREDX_TOP\target\COREDX_TARGET\lib (Ex: C:\coredx\target\Windows_x86_vs2008\lib) OBS: Isto evita que dentro do projeto Java tenha que ser configurado o local do código nativo do CoreDX. Para criar uma aplicação Java Desktop basta importar o arquivo coredx_dds.jar (coredx\target\java\). Importe também as classes geradas pela IDL. 3. Aplicação para demonstração 3.1. Contexto da aplicação Os atores principais da aplicação são: fiscais e ônibus. A posição geográfica, bem como as informações de cada nó, ou seja, todos os dados de contexto de cada nó, (e.g. velocidade, latitude, longitude), e sua rota são emulados, e portanto são previamente definidos. Os fiscais podem estar em comandos, ou seja, em lugares pré-definidos ao longo de estradas/rodovias, onde deverão fiscalizar veículos (ônibus) em uma blitz, ou podem estar em centrais de controle/monitoramento para gerenciar eventos e auxiliar aqueles colegas que estão realizando as fiscalizações em campo Módulos Antes de começar a explicação dos módulos da aplicação ARFF, é necessário fazer alguns esclarecimentos. O desenvolvedor precisa ter em mente que no SDDL os eventos de comunicação 4

5 (Verificação do recebimento de mensagens) são totalmente assíncronos. Ou seja, o servidor web (Controller na visão geral do SDDL) não ficará repetidamente verificando se há algum novo dado (fazendo um polling). Em vez disso, o servidor Web irá se subscrever aos dados que lhe interessam, e a cada vez que um novo dado correspondente for gerado ( e publicado no domínio DDS), o servidor Web receberá uma notificação e o dado lhe será entregue automaticamente. Esse é o princípio da comunicação assíncrona, por eventos, ou Publish/Subscribe. A funcionalidade básica no sistema é o envio de mensagens para os nós móveis, que podem ser um texto, uma imagem, um arquivo com vídeo etc., desde que seja um objeto Java serializável. Para enviar (ou melhor, publicar) mensagens, primeiramente precisa-se criar os seguintes objetos DDS: Participante, Publisher, Subscriber, DataWriter e DataReader como pode ser visto na Figura 1. Para tal, é necessário importar os seguintes pacotes: lac.cnet.sddl.udi.core.ddslayer; lac.cnet.sddl.udi.core.universalddslayerfactory; lac.cnet.sddl.udi.core.universalddslayerfactory.supportedddsvendors; Figura 1 - Criação de Tópicos Para o envio das mensagens é necessário fazer as seguintes importações: lac.cnet.sddl.topics.privatemessagetopic; lac.cnclib.sddl.message.applicationmessage; lac.cnclib.sddl.serialization.serialization; Uma vez que os passos da Figura 1 foram executados, e as importações foram realizadas, uma mensagem em broadcast (mensagem enviada para todos os nós móveis sejam eles fiscais ou ônibus) pode ser enviada como mostra a Figura 2. 5

6 Figura 2 - Mensagem em Broadcast A mensagem em groupcast (mensagem enviada para todos os nós móveis de um determinado grupo. O contexto da aplicação possui dois grupos, fiscais ou ônibus. E sendo assim pode-se enviar mensagens para todos os nós de um determinado grupo) é enviada como mostrado na Figura 3. Onde <groupid> é o identificador do grupo passado como parâmetro. Figura 3 - Mensagem em Groupcast As mensagens unicast (mensagem enviada diretamente para um nó móvel) precisam de um pouco mais de informações. 6

7 Figura 4 - Mensagem Unicast Note que nas Figuras 1,2,3 e 4 possui muito código repetido, então foi criado uma classe responsável pelo envio/recebimento de mensagens, HelperSerializableMessage. Essa classe por padrão, cria os DataWriter e DataReader para publicar/receber informações do tópico PrivateMessageTopic e cria DataReader para receber informações dos tópicos ProhibitedGroupAdvertisementTopic e ChangedSpecialRegion, caso existam. A Figura 5 mostra a inicialização dos objetos. Figura 5 - Inicialização da Classe de Mensagens 7

8 Figura 6 - Classe HelperSerializableMessage A Figura 6 mostra as assinaturas dos métodos da classe HelperSerializableMessage. Os métodos foram criados com o objetivo de reaproveitar código e facilitar o desenvolvimento das camadas da aplicação. A variável createdatareader é usada para criar um DataReader para saber se um ônibus entrou ou saiu de um uma zona proibida. Para utilizar essa classe basta instanciar uma variável do tipo HelperSerializableMessage passando como parâmetro uma variável cujo tipo implemente a interface UDIDataReaderListener. Opcionalmente pode-se fazer com que sua própria classe implemente essa interface Controller A figura 7 mostra o controller, que é a interface do usuário com a aplicação, funcionando como uma central de monitoramento. Trata-se de uma aplicação web que recebe e envia informações para um servidor web via AJAX, que por sua vez é também um nó (estacionário) no domínio DDS, isso é, que instanciou um Publisher e um Subscriber DDS. A partir da interface do controller é possível monitorar as informações de contexto de diferentes nós móveis e se comunicar com os mesmos. 8

9 As funcionalidades presentes no controller são fortemente dependentes da aplicação sendo desenvolvida, o que leva a implementações altamente específicas do módulo. Apesar disso, durante o desenvolvimento do ARFF foram identificados certos elementos de interface úteis para uma vasta gama de aplicações. A seguir vamos exemplificar a implementação de alguns desses componentes em JavaScript e HTML5. Em seguida, demonstraremos como estabelecer a comunicação via AJAX com um servidor web. Figura 7 - Controller Servidor Web O servidor web utilizado foi o Apache Tomcat 7 que pode ser encontrado em: Para obter o máximo de performance, foi utilizado um novo recurso do Tomcat, que é a possibilidade de não usar uma thread por requisição (feita pelo browser), como é feito normalmente e que acaba limitando a quantidade de requisições aceitas por servidor devido a quantidade máxima de threads que o mesmo consegue criar. Para isso é necessário procurar o arquivo server.xml na pasta do Tomcat e fazer uma simples alteração, como é ilustrado na 9

10 Figura 8. Figura 8 - server.xml Com a seguinte alteração, sempre que o Tomcat precisar esperar por uma operação de I/O, ele não precisa deixar uma thread parada só para isto. Ao invés disto, ele pode liberá-la para que a mesma esteja apta a receber uma nova requisição e assim que houver alguma atualização na operação de I/O, o Tomcat procura uma outra thread para terminar o serviço Servlet Para a comunicação entre o browser e o servidor web, foi utilizado a tecnologia Servlet que atualmente esta na versão 3.0. Para uma maior modularização do projeto, foram criadas várias packages de acordo com a sua funcionalidade, como pode ser observado na figura 9 abaixo. 10

11 Figura 9 - Estrutura de pacotes da aplicação API AJAX Foi desenvolvida uma biblioteca Javascript que encapsula a complexidade de utilização do AJAX. Vários métodos simples como por exemplo: send(...), seturl(...) e outros foram disponibilizados para os desenvolvedores no intuito de fazer com que os mesmos não se preocupassem com o que estava acontecendo e pudessem focar apenas no desenvolvimento do aplicação. A figura 10 ilustra o cabeçalho da biblioteca que foi desenvolvida. Figura 10 - Biblioteca Ajax criada pelo LAC 11

12 Desde o momento inicial do desenvolvimento foi planejado dar suporte aos browsers mais populares, sendo eles: Chrome, Safari, Firefox e Internet Explorer, e como foram usados apenas sintaxes recomendadas pelo W3C, então espera-se que outros browser que respeitem os padrões, também funcionem sem maiores problemas. Essa preocupação pode ser vista na Figura 11. Figura 11 - Código para o Ajax funcionar nos principais browsers API de Mapas Mapa Essencial para aplicações que possuem a posição como informação de contexto, o mapa e todos os elementos presentes em sua superfície foram implementados utilizando a Google Maps JavaScript API v3 em A Google disponibiliza um Developer s Guide detalhado sobre a API, que inclui um passo a passo de iniciação e diversos exemplos de códigos para a implementação de funcionalidades mais avançadas Representação de nós Uma classe JavaScript foi criada com a finalidade de encapsular todas as informações e métodos necessários para representar um certo tipo de nó móvel a ser monitorado e gerenciado pela aplicação. A seguir, uma versão simplificada da classe Bus (vide Figura 12) do projeto ARFF, que pode ser utilizada como exemplo para a implementação de qualquer outro tipo de nó móvel. 12

13 Figura 12 - Código JavaScript que cuida do objeto Bus da aplicação Além de atributos clássicos da interface como uuid e plate temos outros atributos que são instâncias de classes nativas a API do Google Maps: Marker é o ícone que representa o nó no mapa, indicando sua posição por meio de coordenadas latitude e longitude. Nesse exemplo é adicionado um listener para o evento de um click no ícone, abrindo uma balão de informações sobre o marker cada vez que o evento ocorrer. Polyline identifica o percurso realizado até o momento por um nó móvel, uma espécie de rastro. O método moveto atualiza a posição do nó e adiciona um novo ponto a polyline. InfoBalloon balão contendo a placa do veículo que é aberto ao clicarmos sobre o ícone de um nó móvel. 13

14 Figura 13 - Mapa usado pela aplicação A Figura 13 mostra a utilização da API do Google Maps. Para mais informações sobre as classes nativas a API do Google Maps consultar Google Maps JavaScript API v3 em Abas As abas, como visto na figura 14, são componentes úteis para organizar a informação no controller. No projeto ARFF existem cinco abas dinâmicas, que dividem os dados disponíveis para o usuário em categorias distintas. Para implementá-las foi utilizado o código desenvolvido por Patrick Fitzgerald, disponível, com documentação e tutorial de utilização, ( 14

15 Figura 14 - Abas Comunicação via AJAX A comunicação entre o browser e o servidor web foi feita a partir da chamada de alguns métodos da biblioteca desenvolvida para uso do AJAX, como visto no tópico API AJAX. O browser executa três tipos distintos de ação: o envio de informações, a requisição de informações e a espera por novas informações. A seguir temos exemplos de como implementar essas ações utilizando a biblioteca Envio de informações Figura 15 - Código que envia dados do browser ao servidor web 15

16 Para enviar um dado ou mensagem ao servidor web é preciso instanciar uma nova variável LAC.Ajax e setá-la como POST. Em seguida, adicionamos um a um as variáveis a serem trafegadas, que são parâmetros esperados pelo método post_data. Note que cada variável deve ter uma string associada a ela, para que o servidor web possa identificar corretamente os argumentos. Após isso, definimos a url referente ao método post_data e enviamos os dados com o método send Requisição de informações Figura 16 - Código que requisita informações do veiculo ao servidor web Como no exemplo anterior, é preciso instanciar uma nova variável LAC.Ajax e adicionar os parâmetros exigidos pelo método que será chamado, no caso, get_vehicle_information. Como estamos apenas requisitando dados não devemos setar a variável Ajax como POST. Importante também, é a presença de uma função callback, que irá processar a informação requerida uma vez que ela fique disponível Espera por novas informações Figura 17 - Código que verifica se existe alguma nova informação para ser exibida Esse método é chamado assim que o browser é iniciado. Ele faz com que o navegador fique de prontidão para processar a chegada de qualquer informação sem a necessidade de uma requisição. Novos nós se conectando ao domínio ou nós antigos atualizando suas posições são exemplos de informações que chegam ao browser de maneira espontânea, e devem ser processadas e atualizadas na interface com o usuário. Após o devido processamento ser realizado, a função callbackgetdata chama novamente a getdata, fazendo o browser retornar ao estado inicial de prontidão. 16

17 3.4. Group Definer O módulo de seleção de grupos é bastante simples. Nele precisamos definir que um objeto do tipo ônibus pertence ao grupo de ônibus e que um objeto do tipo fiscal pertence ao grupo de fiscais. Há um terceiro grupo, um grupo especial, composto por ônibus que estão em uma área proibida, ou seja, uma região que o ônibus não pode entrar. Para implementar essas funcionalidade é necessário importar os seguintes pacotes: lac.cnclib.sddl.serialization.serialization; lac.cnet.groupdefiner.components.groupselector.groupselectorsupportingprohibitedgroups; lac.cnet.sddl.topics.message; O processamento dos grupos foi feito de maneira bem simples, mas sua aplicação pode ter um processamento diferente, seja ele complexo ou simples. A Figura 18 mostra como o processamento foi implementado. Figura 18 - Definição dos Grupos O processamento dos grupos proibidos possui um pouco mais de detalhes, mas também é relativamente simples. Inicialmente é carregada a lista de regiões proibidas a partir de um arquivo texto, nesse momento não nos preocuparemos em explicar como isso é feito, e em seguida testa se o objeto é um veículo e se ele está dentro de uma região proibida, para essa ultima verificação usa-se uma biblioteca chamada JTS, que já foi encapsulada de forma a facilitar a implementação de suas funcionalidades básicas e aumentar a escalabilidade, no entanto, essa implementação não é o foco deste documento. Em caso positivo, é criado um grupo com o identificador da região e adiciona-se esse identificador na lista de grupos proibidos. Essa codificação pode ser vista na Figura

18 Figura 19 - Definição dos Grupos Proibidos A interface GroupSelectorSupportingProhibitedGroups possui o método isprohibitedgroup que precisa ser implementado para que o GroupDefiner saiba que um grupo realmente é um grupo proibido e possa enviar mensagens de aviso apenas na entrada/saída desse grupo. Como exemplo, o método apenas checa se o identificador do grupo está na lista de grupos proibidos. A Figura 20 mostra o código Macro Region Figura 20 - Testando se um Grupo é Proibido A criação das regiões no mapa foi explicada na seção 3.2.1, e aqui será mostrado como enviar mensagens apenas quando o nó móvel (ônibus) entrar ou sair de uma região determinada como proibida. Antes de começar a implementar essa classe é preciso importar o pacote: lac.cnet.sddl.udi.core.listener.udidatareaderlistener; 18

19 Em seguida faça com que sua classe implemente a interface UDIDataReaderListener. No construtor será preciso criar DataWriter para que seja possível publicar informações a respeito da entrada/saída dos ônibus nas regiões proibidas. A Figura 21 mostra o trecho de código responsável por criar o DataWriter e por opção atribui-se ChangedSpecialRegion ao nome do Tópico. Figura 21 - Criação do Data Writer O próximo passo é implementar o método que testará se o ônibus entrou ou saiu de uma região. Isso é feito no método onnewdata (Método da interface). Note que esse método será invocado assincronamente no momento do processamento de grupos (vide Figura 18) for identificado que um ônibus entrou em uma região ou quando a própria API do SDDL identificar que o ônibus não está mais nessa região. Nesse momento não discutiremos como o SDDL identifica essa saída. O método é mostrado na Figura 22. Figura 22 - Enviando Mensagem ao Entrar/Sair de uma Região Por questões de implementação, o identificador do grupo no SDDL é maior que zero quando um determinado nó faz parte do grupo e quando o nó sai do grupo apenas é trocado o sinal. Logo, quando temos um identificador de grupo positivo e maior que zero sabemos que houve uma entrada e quando for negativo sabemos que houve uma saída de um grupo. No entanto, estamos aqui enviando notificações apenas de grupos proibidos. O objeto ChangedSpecialRegion é um objeto enviado para o Controller e seus 19

20 atributos podem ser vistos na Figura 22. O atributo showalert informa ao mapa se é para destacar o ônibus que entrou/saiu de uma região. O método SendMessage, Figura 23, na verdade escreve um tópico com o nome ChangedSpecialRegion passando as informações dos objetos changedspecialregion e message. E dessa forma o Controller saberá como tratar essa informação. Note que no objeto message foi instanciado as propriedades stamps e groupcollection mas não foram usadas. Isso foi necessário devido a implementações internas do SDDL que precisam que essas propriedades não sejam nulas. Figura 23 - Envio de Mudança de Região Simulator O módulo responsável pela simulação gera sete fiscais e dez ônibus, ambos com informações previamente determinadas. A implementação consiste basicamente em instanciar ônibus associando-o a uma ThreadPool. A cada 1 segundo essa instância é invocada e envia dados de contexto para a aplicação. A Erro! Fonte de referência não encontrada. mostra a parte principal do código. Para mais detalhes, ver código da aplicação (No final deste documento contém as informações para acessar o repositório). Lembrando que os nós móveis conectam-se ao Gateway para poder enviar/receber informações. A forma de enviar é mostrada na Figura 24. No módulo Android deste documento mostrará como receber as informações. 20

21 Figura 24 - Trecho de Código para Envio de Dados de Contexto Figura 25 - Trecho de Código Iniciando a Simulação Na figura Figura 25, a variável paths determina pontos específicos no mapa em que o ônibus passará, ou seja, é nessa variável que traçamos a rota que um determinado ônibus percorrerá. O arquivo vehiclepaths.txt contém um conjunto de latitudes de longitudes apenas 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. Figura 26 mostra a estrutura comum de um projeto Android. 21

22 Figura 26 - Elementos principais de um projeto Android Todo o projeto Android tem em sua estrutura as seguintes pastas: src, onde o código fonte das classes desenvolvidas se encontra; gen, 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; bin onde encontram-se os objetos e classes gerados na compilação, incluindo o arquivo.apk, que é o formato de aplicativos instaláveis no Android; libs, onde encontram-se as bibliotecas referenciadas externamente ao projeto; res, onde encontram-se todos os recursos usados para a construção do aplicativo como imagens, sons, arquivos xml descritores de elementos de layout e de outros recursos, etc. e, finalmente, o arquivo AndroidManifest.xml, onde estão definidos 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. 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) como mostra a Figura

23 Figura 27 - 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, Figura 28, 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. 23

24 Figura 28 - Ciclo de vida de uma Activity no Android[1] 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. Fluxo de Controle das Telas do ContextNet - Mobile 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: 24

25 Figura 29 - Fluxo geral de telas do ContextNet - Mobile 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 de modo que o usuário não fosse obrigado a pressionar o botão Voltar do aparelho para retornar a tela anterior (algo que nem sempre é natural ao usuário [2]). Por este motivo, em todas as telas sequenciais, há um botão Voltar incluso na interface de maneira a facilitar o uso desta função. Comunicação O módulo de comunicação (pacote lac.infopae.contextnet.mobile.sddl ) caracteriza-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. 25

26 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). 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 ContextNet - Mobile 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 Melhorias Futuras). Manipulação de XML O último módulo ( lac.infopae.contextnet.mobile.form ) tem funcionalidades 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. Telas e Funcionalidades Interação e I/O com o aplicativo Como já mencionado, as funções principais do ContextNet - Mobile 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: 26

27 Map Screen A A Map Screen é a tela principal de interação do usuário Motorista. É nela que um usuário poderá acompanhar sua localização no mapa, compartilhar POIs e se comunicar textualmente com outros nós. A Map Screen também é, juntamente com a Splash Screen, uma tela de acesso obrigatório do aplicativo, já que ela sempre decorre após a inicialização do mesmo. Figura 30 - Tela de mapa com perspectiva de botões aberta Sendo ela a primeira tela passível de interação do ContextNet - Mobile, é 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 ContextNet - Mobile 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: 27

28 Figura 31 - Caixa de dialogo de Identificação e Conexão para o protótipo do ContextNet - Mobile 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 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 ContextNet - Mobile. Quanto ao controlador de mapas, ele é implementado internamente ao ContextNet - Mobile 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 28

29 apertar de um botão extra, localizado ao lado dos dois. O terceiro botão, de acesso ao Menu Screen, fica localizado 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, assim, abrir uma Chat Screen com 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 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. Por fim, a Map Screen re-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 ContextNet - Mobile e finaliza a conexão e as tarefas sendo executadas de maneira adequada. Menu Screen A tela de Menu Screen foi desenvolvida de modo a agrupar 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. 29

30 Figura 32 - Tela de menu inicial do com botão para chat com o controlador na barra de status. A partir do menu de dashboard desenvolvido para a Menu Screen o 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 mesmo deve ter resposta do estado da conexão na Menu Screen, ou seja, sem precisar mudar de tela. Isto justifica a inclusão da Barra de Status na Menu Screen já que a mesma também dá acesso ao Chat direto com o Controlador, outra funcionalidade desejada para esta tela. Mais detalhes sobre a Barra de Status nas seções seguintes. Connection e Configuration Screen As telas de estado de conexão e configurações são acessadas diretamente pela tela de menu. 30

31 Figura 33 - 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 intuito de ser extensível, de modo que a adição de outros elementos que descrevam a conexão seja simples. 31

32 Figura 34 - 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. 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. 32

33 Figura 35 - 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 36 - Barra de Status com ícone de mensagem nova circulado em vermelho Da mesma forma, se recebermos uma mensagem em uma tela que não 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. 33

34 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 37 - Diagrama de telas de uma Inspeção comum 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 Controlador 1, mas pode interpretar e exibir formulários definidos por Arquivos Descritores de Formulário na memória 1 Mais informações na seção Melhorias Futuras. 34

35 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 17). 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 ContextNet - Mobile 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. 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. 35

36 Figura 38 - Exemplo de XML descritor para um Ônibus. Seção marcada visualizável na Figura 18. 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 Tags do tipo label. Essas Tags referenciam as seções 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. 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. 36

37 Figura 39 - Tela do formulário-exemplo de Ônibus, seção realçada na Imagem 17. 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 formato da mensagem é timestamp em ms UUID registro de inspeção identificador da seção item1 item2... e pode ser visto no exemplo prático na Figura 19. Figura 40 - Mensagem enviada referente à seção descrita 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ção igual a -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 ContextNet - Mobile, sendo enviada quando retomada a conexão. 37

38 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 ContextNet - Mobile. Decisões de Projeto e Desenvolvimento A lógica por trás de muitas funções fundamentais do ContextNet - Mobile deriva de conceitos técnicos e estratégias na maioria das vezes simples. Algumas dessas abordagens serão discutidas adiante. Extensão da Classe de Aplicação do ContextNet - Mobile 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 ContextNet - Mobile (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 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. 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. 38

39 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 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 ContextNet - Mobile, 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. 39

40 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. 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. 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. 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 15) 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. I/O - Caixas de Dialogo, de Texto e Toasts Em Android, há incontáveis formas de representarmos ouput de dados na tela ou pedirmos algum tipo de input. Algumas usadas no ContextNet - Mobile 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 40