Coleta Móvel de Dados em dispositivos Android: um estudo...

Coleta Móvel de Dados emdispositivos Android: um estudosobre a arquitetura do projeto

Maritaca

Leonardo Betto Sueoka

Coleta Móvel de Dados em dispositivos Android: umestudo sobre a arquitetura do projeto Maritaca


Trabalho de conclusão de curso apresentado aoInstituto de Ciência e Tecnologia – UNIFESP,como parte das atividades para obtenção dotítulo de Bacharel em Ciência da Computação.

Orientador: Prof. Dr. Arlindo Flavio da Conceição

São José dos Campos – SPMarço, 2013

Coleta Móvel de Dados em dispositivos Android: umestudo sobre a arquitetura do projeto Maritaca


Trabalho de conclusão de curso apresentado aoInstituto de Ciência e Tecnologia – UNIFESP,como parte das atividades para obtenção dotítulo de Bacharel em Ciência da Computação.

Orientador: Prof. Dr. Arlindo Flavio da Conceição

Banca Examinadora:

——————————————Prof. Dr. Arlindo Flavio da Conceição

——————————————Prof. Dr. Ezequiel Roberto Zorzal

——————————————Prof. Dr. Luiz Eduardo Galvão Martins

Aprovado em:

Aos meus pais, pelo amor, dedicação e pelo eterno incentivo.

Agradecimentos

Agradeço à minha família e meus amigos Mathias, Scott, Vivian, Konishi e Marcio, pois comvocês minha vida universitária foi mais divertida.A minha namorada Cássia Vieira de Oliveira pelas palavras de incentivo e por estar semprepresente.Ao membros da equipe Maritaca, sempre prestativos para ajudar.Agradeço também ao meu orientador Arlindo Flavio da Conceição e a todos meus professores,pois eles ajudaram a formar o que sou hoje.

Resumo

AColeta de dados é um campo com muito espaço para o uso dedispositivos móveis, como os smartphones Android. O projetoMaritaca tem como objetivo o desenvolvimento de uma infra-

estrutura para um sistema distribuído de coleta móvel de dados (CMD),com base em formulários digitais, na qual três componentes se destacam:a aplicação do dispositivo Android, os serviços web para gerenciamentodos formulários e os repositórios de dados. Este trabalho está focado noestudo da arquitetura do Maritaca e no desenvolvimento colaborativo dacomponente Android. Este trabalho gerou como resultados a criação denovas funcionalidades para a componente móvel Android, assim como aavaliação e um caso de uso do sistema.

Palavras-chave: TCC, Android, Coleta Móvel de Dados, Sistemas Dis-tribuídos.

i

Abstract

THe data collection is a field with a large space for mobile devices,such as the Android smartphones. The Maritaca project aimsthe development of an infrastructure for a mobile data collec-

tion (MDC) distributed application, based in digital forms, in wich threecomponents are highlighted: Android application, form management webservices and the databases. This work is focused on study the Maritaca’sarchitecture and collaborative development of Android component. Thiswork has produced results as the creation of new features for the Androidmobile component, as well as evaluation and a case of use of the system.

Keywords: TCC, Android, Mobile Data Collection, Distributed Sys-tems.

ii

Sumário

Resumo i

Abstract ii

Lista de Figuras vi

Lista de Tabelas vii

Lista de Acrônimos viii

1 Introdução 11.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Android e a Máquina Virtual Dalvik 42.1 Histórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Histórico das Versões . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Fragmentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 A Máquina Virtual Dalvik . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1 Arquivos .dex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Trabalhos Relacionados à Coleta Móvel de Dados 123.1 MIT App Inventor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Nokia Data Gathering (NDG) . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3 Open Data Kit (ODK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.4 doForms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Ferramentas e Ambiente de Desenvolvimento Distribuído 154.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii

4.3 Android SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3.1 Plugin ADT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.4 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.5 SourceForge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5 Arquitetura do Maritaca 195.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

5.1.1 Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.1.2 Repositórios de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Sistema Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.1 MVC no Sistema Móvel . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.2 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Funcionalidades do Sistema 276.1 Utilização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276.2 Recursos do Formulário Digital . . . . . . . . . . . . . . . . . . . . . . . . . . 306.3 Compartilhamento de Informações . . . . . . . . . . . . . . . . . . . . . . . . 316.4 Relatórios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7 Implantação do Maritaca 337.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . 337.2 Implantação no Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.3 Aplicação Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8 Contribuições no Código 388.1 Question Slider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8.1.1 Passos da Implementação . . . . . . . . . . . . . . . . . . . . . . . . 398.2 Serviço de Notificações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

8.2.1 Passos da Implementação . . . . . . . . . . . . . . . . . . . . . . . . 408.3 Menu Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8.3.1 Passos da Implementação . . . . . . . . . . . . . . . . . . . . . . . . 428.4 Problemas Reportados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

9 Estudo de Caso 449.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 449.2 Formulário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

10 Conclusões 4810.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4810.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4910.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Referências Bibliográficas 50

A Especificação de Formulário no Arquivo XML 54

iv

B Classe Question 56

v

Lista de Figuras

2.1 Arquitetura do Sistema (Google Inc., 2012b). . . . . . . . . . . . . . . . . . . 72.2 Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b). . . . . . 82.3 Comparativo entre arquivos .dex e .class (Ehringer, 2010). . . . . . . . . . . . 11

4.1 Página inicial do Maritaca no SourceForge. . . . . . . . . . . . . . . . . . . . 18

5.1 Componentes do Maritaca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205.2 Componentes do Maritaca. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Relacionamento entre as componentes do MVC na Engine. . . . . . . . . . . . 245.4 Estrutura de Classes de Question. . . . . . . . . . . . . . . . . . . . . . . . . . 255.5 Estrutura de classes do Comparison. . . . . . . . . . . . . . . . . . . . . . . . 26

6.1 Tela de login. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.2 Tela principal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286.3 Criação de formulários. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296.4 Autenticação e tela principal do aplicativo móvel. . . . . . . . . . . . . . . . . 306.5 Exemplos de questões no aplicativo móvel. . . . . . . . . . . . . . . . . . . . 306.6 Interface para elaboração de relatórios. . . . . . . . . . . . . . . . . . . . . . . 326.7 Menu de acesso aos relatórios. . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1 Modos de importar projetos no Eclipse. . . . . . . . . . . . . . . . . . . . . . 37

8.1 Customização da componente Seek Bar . . . . . . . . . . . . . . . . . . . . . 398.2 Notificação de novos dados coletados. . . . . . . . . . . . . . . . . . . . . . . 408.3 Fluxograma do sistema de notificações. . . . . . . . . . . . . . . . . . . . . . 418.4 Tela Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

9.1 Questões do formulário Bandejão. . . . . . . . . . . . . . . . . . . . . . . . . 459.2 Relatório gerado a partir dos dados coletados no formulário Bandejão. . . . . . 479.3 Respostas do formulário Bandejão incluindo arquivos de imagens. . . . . . . . 47

vi

Lista de Tabelas

2.1 Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). . 10

6.1 Políticas de compartilhamento de dados no Maritaca. . . . . . . . . . . . . . . 31

7.1 Arquivo de configuração configuration.properties. . . . . . . . . . . . . . . . . 35

vii

Lista de Acrônimos

AAC Advanced Audio CodingANR Application Not RespondingAPI Application Programming InterfaceBCC Bacharelado em Ciência da ComputaçãoBCT Bacharelado em Ciência e TecnologiaBMC Bacharelado em Matemática ComputacionalCDMA Code Division Multiple AccessCMD Coleta Móvel de DadosCRUD Create, Read, Update, DeleteCVS Concurrent Version SystemDVCS Distributed Version Control SystemDVM Dalvik Virtual MachineGFS Google File SystemHDP Health Device ProfileHTML Hypertext Markup LanguageHTTP Hypertext Transfer ProtocolIDE Integrated Development EnvironmentJavaME Java Mobile EditionJavaSE Java Standart EditionJDK Java Development KitJPEG Joint Photographic Experts GroupJSF Java Server FacesJSR Java Specification RequestJVM Java Virtual MachineMaritaca MARitaca Is a Tool to creAte Cellular phone ApplicationsMIT Massachusetts Institute of TechnologyMPEG Moving Picture Experts GroupMVC Model, View, ControllerNDG Nokia Data GatheringNFC Near Field CommunicationODK Open Data KitOHA Open Handset Alliance

viii

PNG Portable Network GraphicsREST Representional State TransferSaaS Software as a ServiceSDK Software Development KitSMS Short Message ServiceSQL Structured Query LanguageVCS Version Control SystemXML eXtensible Markup LanguageWAR Web application ARchive

ix

CAPÍTULO

1Introdução

Obter informações de diferentes localidades, armazená-las e analisá-las, na maioria das vezesainda são processos manuais. As informações coletadas são muitas vezes transcritas para for-mulários impressos e depois arquivadas, consumindo espaço e recursos. A coleta de dadospraticada com formulários impressos é suscetível a erros humanos, assim como qualquer pro-cedimento manual, dessa forma, é natural que a coleta de dados a partir de dispositivos móveisse sobressaia como uma solução viável para automatizar esse processo.

Dispositivos móveis como celulares, tablets e smartphones são aparelhos cada vez mais pre-sentes na vida das pessoas. De acordo com a Anatel, no ano de 2010 o Brasil havia ultrapassadoa marca de um celular por habitante, o que significa mais de 190 milhões de dispositivos móveisem território nacional (Anatel, 2010). Com um aumento expressivo, o Brasil fechou o ano de2012 com 261 milhões de linhas móveis (Anatel, 2013). Desse montante aproximadamente 27milhões são os chamados smartphones (Google e MediaCT, 2012).

Um smartphone, ou celular inteligente, é um pequeno computador com diversos instrumen-tos como sensores, câmeras, conectividade sem fio, GPS (Global Positioning System) e umatela sensível ao toque. Apesar de muitos recursos, os smartphones possuem limitações comoalimentação por bateria, memória principal e armazenamento em disco reduzidos. O Android éuma plataforma baseada no Linux desenvolvida especificamente para smartphones. O Androidé um projeto open source, ou seja, possui o código aberto, mantido pela Open Handset Alliance

(OHA) que é formada por um grupo de grandes empresas, lideradas pela Google, interessadas

1

Capítulo 1. Introdução 2

na evolução dessa plataforma. De acordo com dados do final de 2012, 69,7% da parcela domercado pertence ao Android (Gartner Inc., 2013).

A adoção de dispositivos móveis inteligentes e o abandono do uso de formulários impressosna Coleta Móvel de Dados (CMD) pode gerar uma grande economia de material (pranchetas,folhas de papéis e tintas para impressão etc.), além de importantes benefícios ambientais. Porexemplo, o custo ambiental de uma folha de escritório, considerando todo o processo desdecultivo e retirada da árvore, produção de papel e eliminação de resíduos, é de 20,9 gramasde emissão de dióxido de carbono na atmosfera. E a cada 80 mil e 500 folhas de papéis nãofabricadas uma árvore é salva (Jadkowski, 2012).

Apenas a praticidade de utilizar smartphones para CMD aliada as suas vantagens econômi-cas e ambientais já justificariam sua implementação. Mas além desses benefícios, eles possibi-litam o uso de recursos multimídia como fotos, áudio e vídeo. Tais recursos tornam muito maisricas tanto a interação dos usuários quanto a qualidade das informações presentes nos formulá-rios digitais, pois a apresentação da informação ocorre de maneira multissensorial, estimulandomais os sentidos humanos do que um texto comum.

O projeto Maritaca (MARitaca Is a Tool to creAte Cellular phone Applications) buscasuprir as necessidades de automatizar o processo de CMD provendo uma infraestrutura baseadana nuvem para criação de aplicativos móveis para smartphones Android. Esses aplicativosrepresentam os formulários digitais. O Maritaca proporciona uma interface web interativa paraa concepção do formulário e o gerenciamento das informações coletadas. O projeto possui trêsvertentes principais: a aplicação móvel Android, os serviços web e os repositórios de dados.O foco deste trabalho é estudar a arquitetura do Maritaca com ênfase na componente móvelAndroid e colaborar com seu desenvolvimento.

1.1 Objetivos

O objetivo deste trabalho é estudar a arquitetura da componente móvel Android do projetoMaritaca, como ela interage com as outras componentes e colaborar com seu desenvolvimentoem um ambiente distribuído e open source. Também faz parte do escopo integrar a equipede desenvolvedores do projeto, assim como explorar as funcionalidades do sistema em umasituação real. Pode-se listar os seguintes objetivos específicos:

• Estudar, avaliar e testar, por meio de um estudo de caso, a arquitetura do projeto Maritaca;

• Implementar os seguintes itens na componente Android:

– Um tipo de questão do formulário digital: o slider;

Capítulo 1. Introdução 3

– Um sistema de notificações que informa ao usuário a quantidade de novas coletasrealizadas por outros usuários que compartilham o mesmo formulário;

– Uma interface na qual o usuário pode definir configurações sobre o intervalo desincronização com o servidor.

Para mais informações sobre o projeto Maritaca acesse http://maritaca.unifesp.br.

1.2 Organização do Texto

Este trabalho está organizado em nove capítulos. O Capítulo 2 disserta sobre o histórico doAndroid e esclarece os principais conceitos e características dessa plataforma e de sua máquinavirtual chamada Dalvik. O Capítulo 3 compara o Maritaca com outros trabalhos com objeti-vos e funcionalidades similares. As ferramentas colaborativas utilizadas no desenvolvimento doMaritaca são listadas e descritas no Capítulo 4. O Capítulo 5 apresenta a arquitetura aplicada nodesenvolvimento do sistema com foco no sistema móvel. O Capítulo 6 expõe as característicasfuncionais do sistema e pode ser usado como tutorial para sua utilização. A implantação domódulo servidor e móvel é descrita no Capítulo 7. O Capítulo 8 apresenta as principais contri-buições para a componente móvel. O Capítulo 9 apresenta um caso de uso do sistema e comentasobre o potencial da ferramenta e, por fim, o Capítulo 10 discorre sobre as lições aprendidas,considerações finais e trabalhos futuros.

CAPÍTULO

2Android e a Máquina Virtual Dalvik

A plataforma Android (Google Inc., 2013) é um sistema operacional para dispositivos celularescom alto poder computacional, conhecidos como smartphones. A capacidade de processamentoé melhorada a medida que a demanda por tal capacidade aumenta e esse crescimento tende aaumentar ao longo dos anos. Usuários cada vez mais exigentes e aplicações cada vez maiscomplexas e sofisticadas surgirão. O objetivo dessa plataforma é prover um sistema aberto, noqual os desenvolvedores de aplicações possam usar quaisquer recursos disponíveis para cadaaparelho, inclusive os utilizados pelas aplicações internas, aproveitando ao máximo o que elestêm a oferecer.

Este capítulo discorre sobre o histórico, arquitetura, desafios e a máquina virtual da plata-forma Android.

2.1 Histórico

A Google adquiriu uma startup chamada Android Inc., em 2005, com o objetivo de entrarno mercado de dispositivos móveis. Os principais nomes da Android Inc. eram Andy Rubin(considerado o criador do Android), Rich Miner, Nick Sears, e Chris White (Hashimi et al.,2009). Andy Rubin é hoje é vice-presidente de plataformas móveis da Google.

Em 2007, um grupo de empresas, liderado pela Google, chamado de Open Handset Alliance

foi criado para gerenciar e criar novas diretrizes para a plataforma Android. A OHA é uma

4

Capítulo 2. Android e a Máquina Virtual Dalvik 5

aliança comercial composta por muitas das maiores e bem sucedidas empresas do mundo. Seusmembros representam toda a cadeia comercial de dispositivos móveis, incluindo fabricantes dechips, fabricantes de celulares, desenvolvedores de software e provedores de serviço (Condere Darcey, 2012). Além disso, é objetivo da OHA garantir que o projeto tenha código aberto eassim reagir mais rapidamente e de forma inovadora as exigências do mercado (Open HandsetAlliance, 2012).

Em novembro de 2007, foi divulgada uma versão pré-lançamento do Android SDK (Soft-

ware Development Kit) e já em 2008 foi lançado o primeiro aparelho baseado na plataformaAndroid, o T-Mobile G1. Poucos dias depois a versão 1.0 do Android SDK foi lançada e emoutubro de 2008 a Google tornou o código fonte da plataforma Android aberto sob a licençaApache (Hashimi et al., 2009). A partir desse momento, muitas fabricantes começaram a produ-zir dispositivos Android em 2009 e início de 2010. A plataforma ganhou mercado rapidamentee no final de 2010 o Android tornou-se líder de mercado, ganhando espaço de plataformas com-petitivas como o BlackBerry da RIM, o iOS da Apple e o Windows Mobile (Conder e Darcey,2012).

2.1.1 Histórico das Versões

Várias versões do Android foram lançadas desde seu início, agregando novos recursos e funci-onalidades. Atualmente o Android encontra-se na versão 4.2 Jelly Bean. O histórico da evo-lução das versões, assim como as principais mudanças e suas datas de lançamento são listadasabaixo (Google Inc., 2012b):

1.1 - Fevereiro de 2009: Versão inicial;

1.5 (Cupcake) - Abril de 2009Nova API, refinamentos da interface de usuário, melhorias de desempenho, atualizaçãodo Kernel do Linux para a versão 2.6.27.

1.6 (Donut) - Setembro de 2009Nova API, aperfeiçoamento da interface de usuário, atualização do Kernel do Linux paraa versão 2.6.29, suporte para resoluções e densidades de telas, suporte para CDMA, APIpara reconhecimento de gestos e uma engine de texto-para-fala.

2.0, 2.1 (Éclair) - Outubro de 2009Nova API, aperfeiçoamento da interface de usuário, melhoria na renderização de gráficos,bluetooth 2.1,


2.2 (Froyo) - Maio de 2010Nova API, aperfeiçoamento da interface de usuário, novo framework de mídia, novasfuncionalidades para o bluetooth, atualização do Kernel do Linux para a versão 2.6.32.

2.3 (Gingerbread) - Dezembro de 2010Nova API, aperfeiçoamento da interface de usuário, suporte para NFC (Near Field Com-

munications), mudanças na Dalvik e atualização do Kernel do Linux para a versão 2.6.35.

3.0, 3.1, 3.2 (Honeycomb) - Fevereiro de 2011As melhorias das versões do Android Honeycomb são focadas em adaptações para ostablets. Nova API, aperfeiçoamento da interface de usuário.

4.0, 4.0.1, 4.0.3, 4.0.4 (Ice Cream Sandwich) - Outubro de 2011Nova API, aperfeiçoamento da interface de usuário, novos recursos multimídia, novostipos de conectividade como o Wi-Fi Direct e Bluetooth Health Device Profile (HDP).

4.1, 4.2 (Jelly Bean) - Julho de 2012Melhorias de segurança, otimizações na Dalvik, evolução do software da câmera e blu-

etooth, melhora no suporte ao NFC (Android Beam) e reprodução de áudio com baixalatência.

2.2 Arquitetura

O Android é composto por uma pilha de software que inclui um Sistema Operacional, Mid-

dleware e aplicações chave (Google Inc., 2012b). A arquitetura do Android é composta pelascomponentes mostradas na Figura 2.1.

Essa pilha é composta por cinco camadas: Aplicações, Framework para Aplicações, Bibli-otecas juntamente com a Android Runtime e Kernel do Linux. A camada de Aplicações é oconjunto de todos os aplicativos instalados no dispositivo e que são escritos com uma sintaxesimilar ao do Java. Estes são todos os aplicativos nativos indispensáveis (tais como navegadorde internet, cliente de correio eletrônico, aplicativo para gerenciar SMS, calendário, contatosetc.) e os aplicativos que o usuário pode instalar pela Google Play (Google Inc., 2012b).

Na camada Application Framework, estão todas as API’s disponibilizadas no SDK do An-droid para desenvolver aplicações ricas utilizando os diversos recursos presentes nesse sistemaoperacional, como:

• Views: são usadas para construir a interface com o usuário (telas da aplicação);


Figura 2.1: Arquitetura do Sistema (Google Inc., 2012b).

• Content Providers: possibilitam que aplicações troquem informações entre si;

• Resource Manager: permite acesso a arquivos externos como gráficos, arquivos de layout

e de internacionalização;

• Notification Manager: provê a capacidade de gerar notificações personalizadas na barrade status;

• Activity Manager: gerencia o ciclo de vida das aplicações e o fluxo de navegação.

A camada de bibliotecas representa um conjunto de bibliotecas escritas em C e C++ que pos-suem funcionalidades específicas e muito usadas pela camada acima. Nessa camada encontram-sebibliotecas para execução de mídia altamente otimizadas para dispositivos com recursos limita-dos (Brahler, 2010), como codificadores e decodificadores para execução e gravação de vídeo(H264, MPEG4), áudio (MP3, AAC, AMR) e imagens (JPEG, PNG). Inclui-se nessas bibliote-cas o SQLite (SQLite Community, 2013), pacotes para renderização 2D e 3D, entre outros (Go-ogle Inc., 2012b).

Já a Runtime Android possui bibliotecas chaves do Java, além da DVM (Dalvik Virtual

Machine) que será mais detalhada na Seção 2.4 (Google Inc., 2012b).

Na camada de mais baixo nível, há o Kernel Linux na versão 2.6 modificado para atuarem aspectos fundamentais do sistema como gerenciamento do consumo de energia, memória,


processos, rede e segurança. Além de operar também como intermediária entre o hardware e asoutras camadas da pilha (Google Inc., 2012b).

2.3 Fragmentação

Um tema que gera muita discussão entre usuários e fabricantes do Android é o problema defragmentação. O Android continua evoluindo rapidamente desde seu início e, com isso, muitasversões foram lançadas. Existem diversas versões deste sistema operacional instalados em di-versos modelos de smartphones de diversas marcas, desde a antiga versão 1.5 lançada em abrilde 2009, também chamada de Cupcake, até recém-lançada versão 4.2, chamada de Jelly Bean.

A discussão se dá pela incompatibilidade das versões que estão sendo efetivamente utiliza-das pelos usuários, ou seja, existem dispositivos Android ativos em todas as suas versões. Deacordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as versões doAndroid Gingerbread, 28,6% possuem as versões do Ice Cream Sanduich, 15,5% possuem asversões mais recente do Jelly Bean e também 7,5% possuem versão 2.2 Froyo. De fato, há umafragmentação de versões no Android.

O grande problema da fragmentação é que as versões antigas não desfrutam de todas asnovas funcionalidades das versões mais atuais, além disso, os desenvolvedores de aplicativospriorizam o suporte de seus produtos para as versões mais recentes. Ou seja, os usuários quepossuem smartphones com Android desatualizado não possuem acesso aos aplicativos que exi-gem as versões mais recentes instaladas. Por um lado existe o aspecto negativo, que é a frag-mentação, mas pelo outro há o aspecto positivo que é a evolução rápida e constante do sistema.

Figura 2.2: Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b).


Fabricantes vendem seus smartphones e tablets com determinadas versões do Android e ficasob seu juízo a atualização desses aparelhos quando são lançadas novas versões. Porém, desen-volver pacotes de atualização gera despesas e geralmente apenas os aparelhos mais popularesos recebem. Note que o aparelho precisa ter poder de processamento suficiente para executar asversões mais novas, ou seja, os aparelhos mais antigos dificilmente receberão atualizações doAndroid.

2.4 A Máquina Virtual Dalvik

Grande parte do sucesso de uma plataforma para smartphones se dá pela sua capacidade decativar desenvolvedores de aplicativos dessa plataforma. A Google escolheu o Java para sera linguagem primária do Android pela grande comunidade de desenvolvedores e pela relativafacilidade de utilização. Apesar disso, a Dalvik não é uma verdadeira plataforma Java. O An-droid usa uma implementação alternativa e mais limitada da biblioteca padrão do Java, na qualgrande parte das bibliotecas principais do JavaSE estão presentes. Alguns dos motivos da Goo-gle decidir criar sua própria máquina virtual não padronizada foram os problemas apresentadospelo JavaMe, problemas burocráticos no licenciamento de novas funcionalidades do Java peloJSR (Java Specification Request), desempenho, segurança, entre outros (Maker, 2011).

O objetivo da plataforma Android é abranger a maior quantidade possível de dispositivos,desde os mais antigos de baixa capacidade até os mais atuais de alta capacidade. Essa intençãofaz com que os dispositivos obsoletos imponham que a plataforma seja eficiente o suficientepara que tais dispositivos sejam capazes de executá-la. A execução do Android precisa suportarcondições como baixa capacidade de processamento, baixa capacidade da memória RAM, ne-nhum espaço para swap, funcionamento à bateria, diversos modelos de dispositivos e execuçãosegura de aplicativos (Ehringer, 2010). Dados todos esses requisitos a DVM foi projetada parausar o mínimo dos recursos do sistema.

Múltiplas instâncias da Dalvik são executadas simultaneamente. Este fato ocorre porquecada aplicação Android representa um processo sendo executado, o qual possui uma instânciada DVM. Dessa maneira, os processos ficam bem isolados, criando uma forte barreira entre asaplicações (Maker, 2011).

2.4.1 Arquivos .dex

Na plataforma Java padrão, um arquivo .java é compilado pela JVM (Java Virtual Machine) eo resultado disso é o bytecode Java no arquivo .class correspondente. Por exemplo, um arquivo


.java possui uma classe pública, uma classe estática interna e três classes anônimas o resultadoda compilação serão 5 arquivos .class que serão lidos em tempo de execução pela JVM (Ehrin-ger, 2010). Apesar da linguagem de desenvolvimento do Android ser o Java, isso não aconteceda mesma forma nos dispositivos móveis.

Na plataforma Android os arquivos .class continuam sendo gerados, porém a ferramentachamada dx os converte para a extensão .dex (Dalvik Executable) e são esses arquivos que sãoexecutados pela DVM. A função da dx além de converter é otimizar o uso de memória e oespaço em disco, alocando vários .class em apenas um .dx (Ehringer, 2010).

Os arquivos .dex otimizam espaço de armazenamento contendo dados únicos, ou seja, nãohá repetição de informações. Por exemplo, se várias classes fazem referência a uma stringconstante de caracteres, esse objeto existe apenas uma vez nos arquivos .dex e suas múltiplasocorrências são apenas ponteiros para esse objeto (Brahler, 2010). As constantes como strings,campos, variáveis, classes, interfaces, e nomes de métodos são armazenadas em pools de cons-tantes. Um pool é um conjunto de recursos inicializados e prontos para serem usados. NaFigura 2.3 são exibidos os pools de constantes em azul. Temos que cada arquivo .class possuiseu próprio pool heterogêneo de constantes que agrupa todas as constantes em um só lugar.Em contrapartida, o arquivo .dex, que contém várias classes, possui vários pools de constantesorganizados e compartilhados (Ehringer, 2010).

Na Tabela 2.1 os arquivos .dex apenas com as otimizações citadas no parágrafo anteriorpossuem menor tamanho em bytes que os arquivos .jar comprimidos.

Tabela 2.1: Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008).

Bibliotecas do Sistema App Navegador App AlarmeSem compressão 21445320 (100%) 470312 (100%) 119200 (100%)Compressão Jar 10662048 (50%) 232065 (49%) 61658 (52%)Arquivo Dex sem compressão 10311972 (48%) 209248 (44%) 53020 (44%)


Figura 2.3: Comparativo entre arquivos .dex e .class (Ehringer, 2010).

CAPÍTULO

3Trabalhos Relacionados à Coleta

Móvel de Dados

Existem projetos com objetivos e funcionalidades semelhantes ao do Maritaca e que tiveremseu desenvolvimento iniciado em paralelo. Este capítulo analisa esses projetos e os compara aoMaritaca.

3.1 MIT App Inventor

O MIT App Inventor (MIT, 2013) era um projeto da Google que foi descontinuado em agostode 2011 e teve seu código disponibilizado. O MIT (Massachusetts Institute of Technology)com o apoio da Google criou um centro para estudo sobre tecnologias móveis, cujo objetivoprincipal é dar continuidade ao desenvolvimento do App Inventor para Android.

O App Inventor constrói uma aplicação sem a necessidade do usuário ter conhecimento deprogramação. O projeto consiste principalmente de duas aplicações: o App Inventor Designe o App Inventor Blocks Editor. Semelhante a tela de criação de formulários do Maritaca, oApp Inventor Design possui uma interface intuitiva na qual os componentes são arrastáveis eo usuário os posiciona na tela da sua aplicação facilmente. O App Inventor Blocks Editor tema função de associar eventos para cada componente adicionado. O App Inventor possui uma

12

Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados 13

interessante funcionalidade que permite ao usuário ver em seu dispositivo móvel a sua aplicaçãosendo montada em tempo real, desde que o dispositivo esteja conectado em seu computador.

O AppInventor é uma aplicação com um escopo generalista, voltado para usuários interessa-dos em criar suas próprias aplicações. Já o Maritaca tem um escopo específico: a Coleta Móvelde Dados.

3.2 Nokia Data Gathering (NDG)

O Nokia Data Gathering (Nokia Corp., 2013b) é um projeto de código aberto desde 2010 etem como objetivo a automatização da coleta móvel de dados. Funciona com a criação dequestionários e o envio dos mesmos para os agentes de campo que acessam os formuláriosatravés de seus celulares por uma conexão sem fio. As respostas são enviadas à central, queas armazena. É possível exportar as informações coletadas para formatos mais manejáveis, taiscomo planilhas.

O NDG é utilizado na prática em alguns projetos sociais. Em Manaus, no estado do Amazo-nas, juntamente com a Secretaria de Estado de Saúde (SUSAM), o NDG foi usado para a coletade informações pertinentes as famílias atingidas pela dengue, ajudando no combate à doença.

Tanto o NDG quanto o Maritaca possuem escopos semelhantes. Uma diferença importanteé que o NDG está disponível apenas para a plataforma Java ME e Windows Phone, que possuemparcelas reduzidas de mercado.

3.3 Open Data Kit (ODK)

O projeto ODK (ODK Community, 2013) possui código aberto e é composto por um conjuntode ferramentas que auxiliam na criação e gerenciamento da coleta móvel de dados. Entre elesestão: Build, Collect e Aggregate. A Build consiste de uma interface web que possibilita a cri-ação de formulários interativamente, inclusive com perguntas multimídia, como áudio, vídeo eimagens. A Collect é uma aplicação para Android que realiza a coleta de dados nos dispositivosmóveis Android. A Aggregate gerencia as informações coletadas através dos formulários quepodem ser exportadas para formatos mais usuais, como planilhas. Outras ferramentas que sãodesenvolvidas pelo ODK são o Form Uploader, Briefcase, Validate e o XLS2XFORM.

O Maritaca e o ODK possuem objetivos diferentes apesar de terem a CMD como escopo.Enquanto o Maritaca oferece uma infraestrutura para a criação de formulários e gereciamentodas informações coletadas, o ODK é basicamente um conjunto de API’s e padrões que podem

Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados 14

ser usados por outros projetos. Alguns dos projetos que usam o ODK são: FormHub, Epi-

Surveyor, Group Complete, KoBo Toolbox, ViewWorld, PhiCollectUm e o doForms, que seráapresentado na próxima seção.

3.4 doForms

O doForms (doForms Inc., 2013) é um projeto cuja proposta é similar ao Maritaca, porém possuicódigo proprietário. O doForms é baseado no projeto ODK, portanto ambos possuem grandessemelhanças. A aplicação para dispositivos móveis é multiplataforma permitindo dispositivosiOS, Android e BlackBerry. É possível usar o sistema gratuitamente com algumas restrições,como cota máxima de dados de 200 MB e somente usar a aplicação móvel para um únicodispositivo. Outra restrição é que somente alguns tipos de questões podem ser usadas paramontar formulários para usuários com contas gratuitas.

Da mesma forma que o NDG e o Maritaca, as respostas coletadas dos questionários nodoForms são enviadas para um servidor. A partir disso, o usuário é capaz de gerenciar essesdados e enviar novos formulários para os dispositivos dos agentes coletores.

As principais diferenças entre o doForms e o Maritaca é que o primeiro se trata de umasolução paga e multiplataforma enquanto que o objeto de estudo deste trabalho apresenta umasolução aberta e exclusiva para a plataforma Android.

3.5 Considerações Finais

Os trabalhos que mais se assemelham tanto no objetivo quanto nos serviços disponibilizadosé o doForms e o NDG. O doForms e o Maritaca apresentam contextos diferentes visto queo Maritaca apresenta uma solução aberta, enquanto que para usar o doForms com todas suasfuncionalidades é necessário custear uma taxa mensal. Apesar disso, o doForms apresenta umasolução multiplataforma para sua aplicação móvel, que é um benefício considerável. O NDGaparenta ser a solução mais madura dentre as citadas, pois possui registros de sua utilização emsituações significativas. Além do caso citado na Seção 3.2, ele foi posto em prática no Kenya ena África Oriental (Nokia Corp., 2013a). Como já explanado anteriormente uma desvantagemnotável é a aplicação móvel do NDG estar disponível para plataformas pouco utilizadas.

CAPÍTULO

4Ferramentas e Ambiente de

Desenvolvimento Distribuído

Uma das grandes vantagens de se trabalhar em grupo é a paralelização das tarefas de um deter-minado projeto, pois teoricamente quanto mais mão de obra mais rápido o projeto é concluído.No entanto, no âmbito de desenvolvimento de software existem algumas variáveis que nãotornam essa afirmação tão simples. São necessárias ferramentas para alinhar conhecimento,documentar os códigos fontes gerados, um repositório online que todos tenham acesso, IDE dedesenvolvimento, controle de versão, entre outras ferramentas. As seções a seguir descrevemas ferramentas utilizadas neste trabalho.

4.1 Eclipse

Eclipse é uma IDE (Integrated Development Environment) de código aberto e robusta para a pla-taforma Java, porém possui diversos plugins que adicionam funcionalidades para a codificaçãoem outras linguagens. No caso de desenvolvimento para Android, a linguagem de programaçãopadrão possui sintaxe similar a da linguagem Java, mas são necessárias outras ferramentas ebibliotecas da API para que seja possível utilizar toda a capacidade do aparelho celular (EclipseFoundation, 2012).

15

Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído 16

4.2 JUnit

JUnit é uma biblioteca de código aberto criada por Kent Beck e Erich Gamma que visa facilitaro processo de teste de código.

O processo de teste de software é parte indispensável no desenvolvimento de qualquer apli-cação porque é ele que indica possíveis falhas ou erros presentes no código fonte. Ou seja,a qualidade do software a ser produzido está fortemente ligada a cobertura dos testes (Neto,Aristides V. P., 2009). O JUnit automatiza esse processo executando todos os testes escritospelo desenvolvedor e gerando, ao final, um relatório intuitivo indicando quais testes passaram equais não passaram.

4.3 Android SDK

O Android SDK (Software Development Kit) provê as ferramentas e bibliotecas necessáriaspara desenvolver, testar e depurar novas aplicações (Google Inc., 2012b).

4.3.1 Plugin ADT

O plugin ADT (Android Development Tools) disponível para o Eclipse, juntamente com o An-droid SDK dá acesso ao usuário as bibliotecas de qualquer versão do Android liberada, faci-litando o desenvolvimento de uma aplicação para uma versão específica. Inclui também umemulador do próprio sistema, assim é possível o desenvolvedor depurar suas aplicações queestão em fase de desenvolvimento, outra opção é exportá-las para um arquivo .apk e instalá-lasem um smartphone Android (Google Inc., 2012a).

4.4 Git

O Git é sistema de controle de versão, ou VCS (Version Control System), utilizado neste trabalhoe também amplamente utilizado pelo mercado. Os VCS’s funcionam armazenando um históricodas modificações que foram feitas em um conjunto de arquivos sendo possível voltar da suaversão atual para qualquer outra versão específica nesse histórico. Além do Git, existem outrosVCS’s ainda muito utilizados atualmente como o CVS (Concurrent Version System) e o SVN(Subversion).

Entre as principais funcionalidades do Git estão retomar arquivos para um estado específico,recuperar projetos inteiros para um estado específico, comparar mudanças ao longo do tempo,


verificar e registrar as alterações e quem foi o autor dessas mudanças, entre outras funcionalida-des. Por ter toda essa flexibilidade, o Git é muito popular desde os desenvolvedores de softwaresque trabalham sozinhos até as grandes corporações (Chacon e Aljord, 2009).

O Git se enquadra no conceito de DVCS (Distributed Version Control System), que é umsistema de controle de versões distribuído. Cada desenvolvedor é potencialmente tanto um hub

como um node, ou seja, todo desenvolvedor pode contribuir com seu código para outros re-positórios e manter um repositório público no qual outros desenvolvedores podem basear seutrabalho e começar a contribuir também. Essa flexibilidade do Git permite que várias configu-rações de fluxo de trabalho sejam usadas de acordo com a necessidade do projeto (Chacon eAljord, 2009).

4.5 SourceForge

O SourceForge é uma entidade que tem como seu principal objetivo o sucesso dos projetosde código aberto. Provê ferramentas para a gerência do código fonte, documentação, fórumde discussão e status do projeto. A página inicial do Maritaca no SourceForge é mostrada naFigura 4.1.

Atualmente, o projeto Maritaca está hospedado no SourceForge através do endereço https://sourceforge.net/projects/maritaca/ e seu código fonte está disponível paradownload por meio de um repositório Git. Ferramentas como o fórum de discussão entre osdesenvolvedores é muito utilizado e facilita a comunicação quando os envolvidos no projetonão estão fisicamente no mesmo lugar. Assim como o wiki que é a documentação de conceitosjá definidos, tutoriais, ambiente de desenvolvimento, entre outros.


Figura 4.1: Página inicial do Maritaca no SourceForge.

CAPÍTULO

5Arquitetura do Maritaca

O projeto Maritaca é hospedado utilizando uma arquitetura de computação em nuvem, ou seja,todo seu código é executado e os dados são armazenados remotamente em servidores disponí-veis para acesso pela Internet. Dessa maneira, as informações geradas pelos usuários nos dis-positivos móveis estão disponíveis em quaisquer computador com acesso a grande rede, atravésde um navegador (Armbrust et al., 2010). Esse tipo de solução é escalável, ou seja, é possívelcontratar ou liberar rapidamente mais servidores equilibrando a demanda de requisições e osrecursos disponíveis do sistema, caso a quantidade de usuários do sistema aumente ou diminuaconsideravelmente.

O Maritaca implementa um modelo de serviço chamado de SaaS (Software as a Service),que é um modelo associado a aplicações baseadas na computação em nuvem que disponibili-zam seus serviços ao usuário via um navegador web. O conceito deste modelo se traduz namudança de paradigma no âmbito de comércio e distribuição de software. No olhar de umcliente, ao invés de comprar a licença de um software e instalá-lo em seus computadores, eleconcorda em usar a aplicação que será hospedada pela empresa que desenvolve e comercializa osoftware, dando ao comprador flexibilidade para alternar fornecedores e evitar problemas commanutenção (Dubey e Wagle, 2007).

A arquitetura do Maritaca é composta por várias componentes que possuem funções espe-cíficas e que interagem entre si. A Figura 5.1 mostra os principais elementos e suas interaçõescom os usuários do sistema no ciclo de coleta e persistência de informações. Basicamente o

19

Capítulo 5. Arquitetura do Maritaca 20

usuário cria o aplicativo que corresponde a um formulário digital no sistema web do Maritaca eo instala em um dispositivo móvel Android. O coletor usa a aplicação no seu dispositivo paraadquirir e enviar às informações coletadas ao servidor do Maritaca. Os dados são salvos nosrepositórios de dados e estão disponíveis para consulta ou download.

No decorrer deste capítulo, serão vistas informações sobre a arquitetura, tecnologias e me-todologias usadas em todos os componentes da solução.

Figura 5.1: Componentes do Maritaca.

5.1 Visão Geral

A arquitetura do projeto possui três grandes pilares: sistema móvel, servidor web e as bases dedados. A Figura 5.2 mostra de modo geral como essas componentes interagem.

A componente mobile devices representa os dispositivos móveis Android e é onde este tra-balho está concentrado. Trata-se de uma aplicação Android que tem como principal funcio-nalidade a execução dos formulários, que são especificados através de arquivos XML, geradosno portal Maritaca. As requisições feitas da aplicação móvel para o servidor são encapsuladaspelo framework OAuth (OAuth Community, 2013), usado para aumentar a segurança do sis-tema no que diz respeito a autenticação dos usuários. A componente móvel e suas interaçõesserão descritas na Seção 5.2.

O desenho modular do maritaca define que as camadas de apresentação (Presentation Layer),a camada de negócios (Business Layer), a camada de Web Services e a camada de acesso as ba-ses de dados (Data Acess) sejam independentes e separadas. A modularidade reduz a complexi-dade de sistemas, facilita futuras manutenções, mudanças no código e agiliza a implementação


Figura 5.2: Componentes do Maritaca.

do software pormitindo o desenvolvimento paralelo em diferentes partes do sistema (Pressman,2006).

Tanto o código escrito para o servidor quanto o código escrito para o dispositivo móvel sãocódigos Java. Mas em uma situação hipotética, o código usado no servidor poderia ser escritoem outra linguagem visto que a comunicação entre o dispositivo móvel e o servidor ocorre viaweb services, o que dispensa o uso da mesma linguagem de programação. Note que se outralinguagem de programação fosse usada, provavelmente algumas tecnologias empregadas nosistema atual teriam de ser trocadas por outras compatíveis com a linguagem escolhida.


5.1.1 Servidor

Os serviços e funcionalidades web do sistema estão incorporados no servidor de aplicações web

open source JBossAS (http://www.jboss.org/jbossas). Logo, o servidor agrupa ascamadas de apresentação, negócio, acesso ao banco de dados e web services.

Quando um usuário cria seu formulário o sistema constrói uma aplicação Android corres-pondente ao formulário criado. O arquivo XML contendo as especificações do formulário éembutido dentro da aplicação. Dessa forma, cada aplicação criada corresponde a apenas umformulário. O usuário pode criar diversos formulários e cada um será uma aplicação diferente.

Os web services foram implementados usando o modelo REST (Representional State Trans-

fer) através do framework RESTEasy (JBoss Community, 2013). O REST é um modelo ide-alizado de como a internet deveria funcionar. Este modelo de interações de aplicações web setornou a base da arquitetura moderna da internet (Fielding e Taylor, 2002). Este estilo arqui-tetural é uma abstração do básico do protocolo HTTP (Hypertext Transfer Protocol) e consisteem conceitos ao invés de sintaxes e detalhes técnicos (Schreier, 2011).

Todas as funcionalidades do sistema que envolvem envio e recebimento de mensagens decorreio eletrônico são implementadas pelo no sistema com o framework de código aberto Rab-

bitMQ (VMware Inc., 2013).

A camada de apresentação representa as telas que são apresentadas ao usuário. As páginasde gerenciamento de formulários foram desenvolvidas com tecnologias altamente utilizadase reconhecidas pelo mercado e pela comunidade de desenvolvedores como JSF (Java Server

Faces) (Oracle Corp., 2013b), Jquery (The jQuery Foundation, 2013) e HTML 5 (W3C, 2010).

5.1.2 Repositórios de Dados

São usados duas bases de dados com propósitos diferentes: o Cassandra (The Apache SoftwareFoundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b).

O Cassandra é um sistema de banco de dados distribuído open source criado pela Apache

Software Foundation. Ele é dito No-SQL, ou seja, não utiliza a predominante arquitetura rela-cional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciargrandes quantidades de dados, provendo um serviço com alta disponibilidade e sem pontos defalha (Lakshman e Malik, 2010). É utilizado por grandes empresas como Google, Facebook eAmazon. O Cassandra é usado no Maritaca para armazenar os dados estruturados em XML dasrespostas dos formulários.

O acesso ao banco de dados Cassandra se dá pela API Hector (Hector Community, 2013).Ela fornece bibliotecas de alto nível para realizar diversos tipos de procedimentos na base de


dados que vão desde operações básicas de CRUD (Create, Read, Update, Delete) até controledo pool de conexões.

O Hadoop é também um projeto open source da Apache Software Foundation que incluiimplementações de um sistema de arquivos distribuído, MapReduce baseado no GFS (Google

File System) e outros projetos de MapReduce (Borthakur et al., 2011). Neste projeto ele éusado para armazenar modelos de dados não estruturados, principalmente arquivos, como áudio,vídeo, imagens e executáveis Android (arquivos com extensão apk).

5.2 Sistema Móvel

Depois de criar ou editar um formulário a partir de um navegador web, o formulário pode serpreenchido no dispositivo móvel no qual os dados coletados serão armazenados temporaria-mente no banco de dados local.

O módulo móvel no Maritaca corresponde ao aplicativo para Android e é responsável porgerenciar e coletar as respostas dos questionários.

5.2.1 MVC no Sistema Móvel

O Sistema Móvel do Maritaca segue o padrão de projeto MVC (Model, View, Controller) que élargamente utilizado na indústria de software. Trata-se da separação clara de cada um de seuscomponentes:

• O Model é o módulo no qual se encontram as regras de negócio da aplicação juntamentecom suas entidades.

• A View é a tela de interface com o usuário. É nessa componente que os dados são visua-lizados pelo usuário e onde ele interage com o sistema.

• O Controller é responsável por intermediar os dois componentes anteriores. Ele basica-mente pega os dados gerados da comunicação do usuário com a View e os entrega para oModel processar, o mesmo ocorre no sentido inverso.

A grande vantagem desse padrão de projeto é tornar o sistema modular, sendo cada camadaindependente da outra. Isso nos leva a facilidade de manutenção, por exemplo, se for necessáriauma mudança nos cálculos de uma aplicação, o desenvolvedor precisa apenas alterar o Model.Analogamente, se for necessária uma mudança de design na tela de visualização, é apenas láque o desenvolvedor vai realizar a mudança (Eric Freeman, 2007).


No cenário do sistema móvel, é no Model que estão concentradas as regras de negócio,ou seja, as implementações do funcionamento de cada questão, validações e comparações. AView é composta pelas telas do sistema. No Android, as telas são definidas por arquivos XMLnos quais estão estabelecidos o posicionamento das componentes como texto, botão, checkbox,entre outros. Quem implementa a ação desses componentes é o Controller, que no contexto doAndroid são suas Activities. A Figura 5.3 mostra como esses componentes se relacionam.

Figura 5.3: Relacionamento entre as componentes do MVC na Engine.

5.2.2 Engine

Toda a comunicação entre dispositivo móvel e servidor ocorre via web services e, sendo maisespecífico, quando essa comunicação envolve questionários ou respostas de questionários elatransmite informações que representam arquivos XML. Esses arquivos precisam ser lidos etransformados em objetos Java que representam uma pergunta no questionário. Ocorre o mesmono sentido inverso, um objeto Java que representa uma resposta é transformado em um arquivoXML e é enviado ao servidor. As manipulações dos arquivos XML são realizadas pela Engine.Ou seja, a Engine é responsável por receber dados que descrevem um questionário e retornarobjetos Java que são efetivamente as questões implementadas.

A Engine implementa o padrão de projeto Interpreter. Este padrão define que dado umalinguagem, é possível determinar uma representação para ela por intermédio de um interpreta-dor que usa essa representação para processar sentenças da linguagem (Gamma et al., 1994). Oconceito fundamental do Interpreter na Engine é apresentar um conjunto hierárquico de clas-ses que representa a especificação de um formulário, que por sua vez representa a linguagema ser interpretada. O arquivo XML, ou a especificação de formulários, é a linguagem a serinterpretada e a Engine é o interpretador.


Cada tipo de questão do formulário digital é representada por uma hierarquia de classes, cujasuperclasse é a classe Question. Essa superclasse possui atributos e métodos que são comuns assubclasses. Essa estrutura de classes pode ser vista na Figura 5.4. O responsável por processaro XML e gerar os objetos definidos pelas subclasses de Question é o Parser.

Figura 5.4: Estrutura de Classes de Question.

Parser

A leitura de formulários é feita baseada em um conjunto de classes que representam o arquivoXML. O formulário em si é representado pela classe Form, seus elementos são compostos pelaclasse Questions e os atributos dos elementos são representados pelas classes Comparison eClause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework

Simple (Simple Community, 2013), que facilita a implementação e melhora a legibilidade docódigo. O Simple também auxilia na serialização dos arquivos XML de respostas dos formulá-rios.

O trabalho de manusear as entidades citadas acima é responsabilidade das classes utilitáriasXMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes são referenciadasna camada de negócio do sistema móvel.

As respostas dos formulários são transmitidas da unidade móvel Android para o servidoratravés de grandes strings de caracteres, encapsuladas em requisições HTTP, que representamseus respectivos arquivos XML.

Comparison

Um formulário com perguntas sequenciais nem sempre é interessante para determinados con-juntos de perguntas. Essa funcionalidade é passível de ser implementada em um formuláriodigital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma per-gunta anterior. Por exemplo, a pergunta: “Você ingere bebidas alcoólicas?” só deverá aparecer


se a pergunta anterior: “Qual é a sua idade?”, obter uma resposta dizendo que o interrogado temmais de 18 anos.

Essa funcionalidade está representada por um atributo no XML do formulário de perguntase que pode ter as seguintes comparações: igual, maior, maior ou igual, menor e menor ou igual.Cada comparação é representada por uma classe e todas elas estendem a classe abstrata Clause,conforme mostra a Figura 5.5.

Figura 5.5: Estrutura de classes do Comparison.

CAPÍTULO

6Funcionalidades do Sistema

O Maritaca oferece ao usuário uma interface simples e intuitiva para a criação de formulários,geração de aplicações e coleta de dados. Basicamente, são necessários três passos para que umciclo de coleta de dados se complete:

1. Pelo navegador de internet, o usuário cria o questionário. O sistema construirá a aplicaçãoAndroid e o disponibilizará para download.

2. A aplicação é instalada no dispositivo Android;

3. O usuário coleta as informações e envia as respostas ao servidor.

Esse capítulo detalha as funcionalidades que o sistema oferece e ao mesmo tempo é um guiapara sua utilização.

6.1 Utilização

O endereço de acesso do Maritaca é http://maritaca.unifesp.br. Para utilizar osistema, é necessário efetuar um cadastro simples e depois se logar, como mostra a Figura 6.1.Caso o usuário já tenha uma conta de usuário da Google, Yahoo ou do Facebook é possívelutilizá-la através da tecnologia OpenID (OpenID Foundation, 2012).

27

Capítulo 6. Funcionalidades do Sistema 28

Figura 6.1: Tela de login.

Após a autenticação, o usuário é levado para a página principal do sistema, onde são listadostodos os formulários criados por ele e os compartilhados, conforme mostra a Figura 6.2. Há ummenu com aba Groups na parte superior, o qual permite o gerenciamento de grupos de usuários.

Figura 6.2: Tela principal.


Ao clicar no botão New Form o usuário é levado para a tela de criação de formulários. Opainel da esquerda contém os tipos de pergunta que o usuário pode adicionar ao seu formulário,como uma pergunta em forma de texto, uma foto, um vídeo, uma data, localização por GPS,entre outras. As perguntas são componentes HTML 5 arrastáveis (drag and drop), dessa formao usuário pode adicionar um desses itens simplesmente arrastando-o para o centro da tela. Noexemplo da Figura 6.3 o formulário possui quatro perguntas.

Figura 6.3: Criação de formulários.

Após salvar o formulário, a criação do aplicativo para Android começa automaticamente deforma assíncrona. Depois de criado, o usuário pode fazer o download do aplicativo e instalá-lono seu dispositivo Android.

Após a instalação, o aplicativo exige uma autenticação do usuário, da mesma forma quequando acessado através do navegador. A interface principal mostrada na Figura 6.4 é compostapor um menu que corresponde ao formulário criado anteriormente. Para coletar informaçõesdeste formulário basta selecionar a opção Collect.

As próximas sequências de telas correspondem às perguntas criadas previamente na inter-face web do Maritaca. A Figura 6.5 ilustra as questões do formulário criado anteriormente. Astelas de questionário são divididas de forma que na região superior fiquem localizados o títulodo formulário, uma barra de progresso, um botão de ajuda e um botão de cancelar. O restanteda tela é ocupado pela questão e sua resposta.

O usuário pode realizar quantas coletas forem necessárias para um mesmo formulário. De-pois dos dados serem coletados, o usuário pode enviar essas informações para os servidores doMaritaca e acessá-las na sua conta via interface web.


Figura 6.4: Autenticação e tela principal do aplicativo móvel.

Figura 6.5: Exemplos de questões no aplicativo móvel.

6.2 Recursos do Formulário Digital

Os questionários podem ser criados utilizando vários tipos de recursos. A interface web doMaritaca disponibiliza perguntas dos seguintes tipos: texto, seleção múltipla (checkbox), nume-ral, data, múltipla escolha (combobox e radiobox), foto, áudio, vídeo, GPS, código de barras,controle deslizante (slider) e desenho. O Maritaca está em constante desenvolvimento e exis-tem planos para adicionar mais tipos de perguntas. Uma grande vantagem do sistema é suaarquitetura modular que facilita a adição de novas componentes. Por exemplo, todos os tiposde questões estão agrupados em um pacote de classes independente, dessa forma, para criar umnovo tipo de questão, basta criar novas classes que representam o tipo de questão desejado. Éimportante salientar que é necessário estender a classe abstrata Question que define como osmétodos devem ser implementados.

Cada questão do formulário digital do Maritaca possui propriedades importantes que deixamo sistema mais robusto para o uso na CMD. Cada questão pode ter seu valor padrão inicial, um


valor mínimo e um valor máximo definidos na etapa da criação do formulário. Também há apossibilidade de tornar uma pergunta obrigatória ou mantê-la opcional. Outra funcionalidadeque merece destaque é a capacidade do desvio do fluxo normal da sequência das perguntasatravés de algumas condicionais, tais como: igual, menor, maior, menor ou igual e maior ouigual. Ou seja, é possível ir pra alguma questão específica do questionário a partir da questãoatual, obviamente que a mudança da sequência depende da resposta.

Uma propriedade útil das questões é o campo ajuda. Trata-se de um campo texto que com-plementa a descrição da questão e pode ser acessado a partir de um botão na região superior doaplicativo móvel.

6.3 Compartilhamento de Informações

O nível de compartilhamento dos formulários e suas respostas podem ocorrer em três graus:privado, público e compartilhado. No compartilhamento privado, o formulário só está acessívelao seu criador (owner). No público, o formulário é acessível para todos. O nível compartilhadode um formulário ocorre quando o seu criador convida outros usuários para acessá-lo. Essenível possui duas ramificações:

• Hierárquico: Os usuários convidados não podem acessar as respostas coletadas de outrosconvidados. Apenas o criador do formulário consegue ver todas as respostas;

• Social: Ao contrário do item anterior, tanto os usuários convidados quanto o criadorconseguem acessar todas as respostas coletadas.

A Tabela 6.1 sintetizou os tipos de permissões de acesso (leitura e escrita dos dados cole-tados) para o criador do formulário e seus convidados, de acordo com o grau de compartilha-mento.

Tabela 6.1: Políticas de compartilhamento de dados no Maritaca.

Privado Comp. Hierárquico Comp. Social Público

Formulário Leitura Criador Criador e Convidados Criador e Convidados TodosEscrita Criador Criador Criador Criador

Resposta Leitura Criador Criador Criador e Convidados TodosEscrita Criador Criador e Convidados Criador e Convidados Criador


6.4 Relatórios

A geração automática de relatórios é uma funcionalidade que está em desenvolvimento, porémnão pode deixar de ser mencionada. Ela permite que a partir das informações coletadas e dasperguntas selecionadas pelo usuário seja gerado um relatório contendo gráficos de pizza oubarras e organizar os dados em forma de tabelas. Por enquanto os relatórios são gerados apenascom questões de seleção múltipla como checkbox e radiobox. A Figura 6.6 exibe a tela decriação de relatórios em que o relatório (coluna central) contém duas questões do formulário(coluna da esquerda).

É possível criar e editar vários relatórios para um mesmo formulário. Para acessá-los, bastaabrir o menu de opções do formulário desejado, exibido na Figura 6.7, e clicar na opção Edit

Report ou View Report, na página principal do Maritaca.

Figura 6.6: Interface para elaboração de relatórios.

Figura 6.7: Menu de acesso aos relatórios.

CAPÍTULO

7Implantação do Maritaca

Este capítulo destaca os passos para a implantação do sistema e configuração do ambiente dedesenvolvimento.

7.1 Ambiente de Desenvolvimento

A preparação do ambiente de desenvolvimento consiste na instalação e configuração das fer-ramentas e bibliotecas utilizadas no desenvolvimento de um sistema. O sistema operacionalrecomendado para o desenvolvimento do Maritaca é o Ubuntu versão 11.10. As ferramentasusadas no desenvolvimento juntamente com suas páginas oficiais são listadas abaixo:

• JDK (Java Development Kit) versão 6: http://www.oracle.com/technetwork/java/javase/downloads/index.html;

• Eclipse IDE para Java EE: http://www.eclipse.org/downloads/;

• Plugin maven para Eclipse: http://www.eclipse.org/m2e/

• Android SDK: http://developer.android.com/sdk/index.html;

• Plugin ADT: http://developer.android.com/tools/sdk/eclipse-adt.html;

33

Capítulo 7. Implantação do Maritaca 34

• Cassandra http://cassandra.apache.org/download/;

• Tomcat 7 http://tomcat.apache.org/download-70.cgi;

• Apache Maven: http://maven.apache.org/;

• Apache Ant: http://ant.apache.org/;

• Git: http://git-scm.com/

• RabbitMQ: http://www.rabbitmq.com/;

Note que para o Eclipse poder ser executado, o JDK 6 precisa ser instalado primeiro.

7.2 Implantação no Servidor

Após todos os itens da seção anterior serem instalados e devidamente configurados, é necessáriofazer o download do código fonte do Maritaca que está disponível na página do Maritaca noSourceForge. O seguinte comando deve ser executado no terminal do Linux:

$ git clone git://git.code.sf.net/p/maritaca/code maritaca-code

Após a execução do comando, a pasta contendo o código fonte estará no diretório corrente.O módulo servidor é divido em quatro projetos: business, persistence, web e webservices. Omódulo móvel possui um único projeto: o maritaca-mobile.

O arquivo de configuração configuration.properties é essencial para a implantação do pro-jeto. Ele pode ser criado em qualquer diretório contanto que sua localização seja fixada pormeio da variável de ambiente MARITACA_CONFIG_PATH. Esse arquivo é exibido na Tabela7.1.

Antes de iniciar o servidor é necessário configurar o Cassandra. Primeiro deve-se subir oserviço no terminal executando o seguinte arquivo, localizado na pasta de instalação do Cassan-dra:

$ sudo ./bin/cassandra

Usando outro terminal é preciso criar o keyspace do Maritaca, executando os seguintescomandos:


Tabela 7.1: Arquivo de configuração configuration.properties.

Propriedade Exemplomaritaca_mobile_path /home/user/workspace/maritaca/client/

android_sdk_path /opt/android/android-sdk-linuxmaritaca_uri_server http://192.168.1.105:8080/maritaca

filesystem_path /var/www/hadoop_mounted/user/seu-usuariohttp_uri_server http://localhost/hadoop_mounted/user/seu-usuario/

ffmpeg_path /usr/local/bin/ffmpegtmp_directory /tmp/cluster_addr localhost:9160

$ ./bin/cassandra-cli -h localhost

create keyspace Maritaca;

exit;

Para configurar o RabbitMQ execute os seguintes comandos:

$ sudo rabbitmqctl add_user maritaca maritaca

$ sudo rabbitmqctl add_vhost Maritaca

$ sudo rabbitmqctl set_permissions -p Maritaca maritaca ".*" ".*" ".*"

Há um projeto chamado rabbit-consumer na pasta services. O projeto deve ser compiladocom o maven através do comando:

$ mvn clean package

Um arquivo JAR referente ao projeto será gerado. Deve-se executá-lo através do comando:

$ java -jar rabbit-consumer-1.0.jar

O servidor de aplicações Tomcat pode ser iniciado através de um script localizado na pastabin que fica no diretório onde foi instalado o Tomcat. Dentro desta pasta, basta executar ocomando:

$ ./catalina.sh run


Após o servidor ser inicializado a interface web do Tomcat pode ser acessada por meio doendereço http://localhost:8080.

O próximo passo é compilar o projeto servidor e gerar um arquivo WAR (Web application

ARchive) que representa a aplicação web do Maritaca a ser implantada no servidor. O projetoé compilado com a ferramenta maven, executado no terminal e na pasta server do projeto, pormeio do comando abaixo:

$ mvn clean install -Dmaven.test.skip=true

O arquivo WAR pode ser encontrado dentro da pasta target do projeto web no móduloservidor. É esse arquivo que deve ser implantado no servidor. O maven possui plugins extrasque se instalados permitem que logo após o projeto ser compilado, o arquivo WAR construído éautomaticamente implantado no servidor. Existem outras maneiras como utilizar a interface web

do servidor e fazer o upload do próprio arquivo WAR. Após a implantação o módulo servidor doMaritaca pode ser acessado através do endereço http://localhost:8080/maritaca.

7.3 Aplicação Android

Se o plugin ADT e o Android SDK foram instalados corretamente, dois ícones devem aparecerno Eclipse: o Android SDK Manager e o Android Virtual Device Manager. O primeiro se tratade um gerenciador das API’s do Android assim como algumas ferramentas. O projeto Maritacapode ser compilado a partir da API 7, portanto se faz necessária a instalação de uma API igualou superior. O Android Virtual Device Manager é um gerenciador de dispositivos virtuais queemulam um smartphone Android. Pode-se criar vários dispositivos virtuais, cada um com suarespectiva versão do Android e atributos como memória principal e resolução de tela.

Se a versão do Ubuntu instalada é 64 bits, então a instalação da biblioteca ia32-libs se faznecessária para trabalhar com o Android SDK.

O módulo móvel do Maritaca depende de outro projeto: o ActionBarSherlock (http://actionbarsherlock.com/). No projeto ele está nomeado como library e está nomesmo diretório do maritaca-mobile. O código fonte do módulo móvel Android está dentroda pasta maritaca-mobile. Para adicionar o projeto ao Eclipse é necessário importa-lo pelomenu File -> Import ou clicando com o botão direito no Package Explorer -> Import conformemostra a Figura 7.1. Após esse passo, surge um menu com vários tipos de projetos. Deve-seescolher um projeto do tipo Android como fonte. Lembre-se de importar tanto o library quantoo maritaca-mobile.


Figura 7.1: Modos de importar projetos no Eclipse.

Após importado, o projeto pode ser visualizado no Package Explorer. Todas as classes,arquivos de layout, bibliotecas adicionais e arquivos de configuração podem ser acessados. Paraexecutar o projeto basta clicar com o botão direito no projeto e selecionar Run As -> Android

Application. O dispositivo virtual criado anteriormente será iniciado e a aplicação instalada eexecutada.

CAPÍTULO

8Contribuições no Código

Este capítulo apresenta as principais contribuições, por mim realizadas, no código fonte dosistema móvel do projeto Maritaca. Foram desenvolvidas três funcionalidades principais: aimplementação do tipo de questão slider, um serviço de notificação de novos dados enviados ea tela de configuração ou settings. Esses três itens cobrem campos diferentes tanto da arquiteturado Maritaca quanto da API do Android, abrangendo tópicos como a criação de telas por arquivosXML, consultas e inserções de dados através do SQLite, uso do sistema de notificação e dealarme do Android, implementação da classe Question, entre outros.

8.1 Question Slider

O Slider no Maritaca é a implementação da Seek Bar presente na API do Android. Com essacomponente é possível selecionar um valor em um intervalo (geralmente de zero a cem) mo-vendo horizontalmente o indicador da barra. O menor valor está no limite da esquerda assimcomo o maior está no limite da direta. A Figura 8.1(b) mostra a Seek Bar da API do Android ea Figura 8.1(a) mostra o Slider do Maritaca.

38

Capítulo 8. Contribuições no Código 39

(a) Slider Maritaca. (b) Seek Bar Android.

Figura 8.1: Customização da componente Seek Bar

8.1.1 Passos da Implementação

A classe abstrata Question, mostrada no Apêndice B, define quais métodos os tipos de questõesdevem implementar. Essa classe é fundamental no contexto do sistema, pois todas as mani-pulações que a Engine faz para criar os objetos, que correspondem as questões no formulário,são feitas com base nos seus métodos. Para desenvolver o Slider foi necessário implementar osseguintes métodos abstratos:

public abstract ComponentType getComponentType();Este método retorna o tipo do componente ou questão a ser implementada. Compo-

nentType é um Enum, ou seja, uma classe estruturada de tal forma que seus dados sejamimutáveis (Sierra e Bates, 2005). É nessa classe que estão definidos todos os tipos dequestões com um respectivo identificador, inclusive o slider.

public abstract Object getValue();Retorna o valor adquirido pela questão. No caso do slider é retornado um valor numérico,mas caso fosse um questão do tipo texto, este método retornaria uma string de caracteres.

public abstract View getLayout(ControllerActivity activity);Este método retorna o Slider customizado. O slider é montado a partir da seek bar jun-tamente com seu esquema de posicionamento da componente na tela. Com o slider foicriada uma componente de texto que mostra o valor atual do slider e o atualiza caso ousuário mude.

public abstract boolean validate();A validação da questão é feita quando o usuário avança ou retrocede no formulário nomenu de coleta. Um tipo de validação é a verificação da obrigatoriedade da resposta, ouseja, a resposta da questão não pode ser vazia. O slider implementa este tipo de validação.

public abstract void save(View answer);A implementação deste método ocorre da mesma forma que o item anterior, porém ométodo salvar é executado antes, pois no contexto do sistema é necessário salvar o valorselecionado pelo usuário para poder executar a validação.


8.2 Serviço de Notificações

Um serviço no Android, representado pela classe Service, é uma componente de aplicação quetem como função realizar operações prolongadas que não interferem com o usuário ou proverfuncionalidades para outras aplicações. Os serviços não são processos ou threads adicionais, ouseja, são executados no mesmo processo da aplicação a qual pertencem. A classe IntentService

estende Service e é usada para lidar com tarefas assíncronas, ou seja, ela cria threads paraprocessar o que foi requisitado e depois elimina a thread (Google Inc., 2012b).

O serviço de notificações é composto por uma IntentService que faz uma requisição HTTPpara o servidor acessando um web service que retorna uma resposta que contém a quantidade denovas coletas enviadas ao servidor, a partir de uma data, por outros coletores para o formulárioem questão. Se houverem novas coletas a própria IntentService lança uma notificação, comoa ilustrada na Figura 8.2. Essa funcionalidade é útil quando existem vários coletores para ummesmo formulário.

Figura 8.2: Notificação de novos dados coletados.


Criação do Serviço

O serviço é representado pela classe NotificationService que estende IntentService. Essa classeé responsável por criar a notificação e gerenciar a requisição e sua resposta HTTP. Caso aresposta do web service retorne um inteiro maior que zero, uma notificação é gerada indicandoo número de novas coletas, caso contrário, uma notificação é gerada indicando que nenhumacoleta foi enviada ao servidor.

O NotificationService é chamado assim que a tela de menu é construída. Quem faz a cha-mada é a classe AlarmManager que provê acesso a sistema de alarmes do Android e permiteagendar a execução do serviço, que é feita repetidamente e em intervalos de tempo definidos


pelo usuário. A tela de configuração, melhor detalhado na Seção 8.3, inclui opções para ligarou desligar o serviço de notificação e determinar o intervalo de tempo que a sincronização como servido é realizada.

Tratamento da Requisição e Resposta

A requisição é feita criando um objeto que representa uma requisição HTTP e o enviando. Acriação da requisição envolve a passagem de parâmetros de dois parâmetros a partir da URL:a identificação do formulário e a data da última sincronização. Depois que a requisição foienviada cabe ao servidor recebê-la e tratá-la. O servidor usa o RESTEasy (JBoss Community,2013) que implementa a especificação JAX-RS (Oracle Corp., 2013a) e provê uma bibliotecapara web services RESTful, facilitando seu uso.

O servidor está configurado para filtrar as requisições feitas aos web services e encaminhá-laspara seu respectivo método de implementação. Este método faz uma busca no banco de dadosque retorna uma lista de formulários enviados ao servidor, por outros usuários, a partir da datarecebida como parâmetro. Com essa lista em mãos, basta retornar seu tamanho. O resultadoé encapsulado em um objeto que corresponde ao uma resposta HTTP e é enviada de volta aoNotificationService. A Figura 8.3 representa a sequência dos eventos e chamadas do sistema denotificações.

Figura 8.3: Fluxograma do sistema de notificações.


8.3 Menu Settings

A partir do menu principal há um botão com opção de ir para tela de configurações ou Settings.As opções de configuração nessa tela fazem referência a seção anterior, logo, ela contém umbotão no qual é possível ativar ou desativar a sincronização com o servidor do sistema de no-tificações. Caso esse botão for habilitado, a escolha do intervalo de tempo de sincronizaçãotambém será. A Figura 8.4 apresenta a tela com suas respectivas componentes.

Figura 8.4: Tela Settings.


A criação de telas, ou interfaces de usuário, no Android ocorre pela representação de seuscomponentes com seus respectivos atributos por um arquivo XML. No arquivo que representaa interface da Figura 8.4 existem alguns componentes a serem destacados:

• O Toggle Button, que alterna entre ativada e desativada a sincronização do sistema denotificações;

• A Seek Bar, responsável por determinar o intervalo de sincronização em minutos. Noteque esta componente só estará habilitada de o botão do item anterior também estiver;

• O botão Save Settings que persiste as configurações no banco de dados local do disposi-tivo móvel.


Para armazenar as preferências do usuário, foi necessário criar uma tabela no banco de dadoslocal. Cada linha desta tabela armazena se o Toggle Button está ativado ou não, o intervalo desincronização e o usuário a quem pertence essas opções.

A API do Android fornece algumas classes que facilitam a manipulação de tabelas no bancode dados local SQLite. Para manipular os dados dessa tabela foram implementados métodospara inserção, atualização e consulta desses dados. A inserção ocorre quando não existem dadosna tabela e o usuário pressiona o botão Save Settings. A atualização ocorre da mesma forma,porém somente quando existem dados na tabela. As consultas são feitas na própria tela Settings,no momento de sua criação, para carregar as componentes com os valores salvos anteriormente,e também no AlarmManager para pegar o valor do intervalo de sincronização.

8.4 Problemas Reportados

Os problemas encontrados no sistema podem ser adicionados na página de notificação de bugs

no SourceForge do Maritaca (https://sourceforge.net/p/maritaca/bug/). Osproblemas encontrados e submetidos são listados a seguir:

• O aplicativo móvel não abre em versões do Android 4.0 ou superior. Esse problemaocorre quando requisições HTTP são executadas na thread principal da aplicação, o quepode acarretar em ANR (Application Not Responding) (Google Inc., 2012b). A página re-ferente ao bug é https://sourceforge.net/p/maritaca/tickets/463/;

• Caso o coletor não tiver acesso à internet ele não consegue coletar dados. A Seção 9.3descreve como este problema foi encontrado. A página referente ao bug é https://sourceforge.net/p/maritaca/bug/53/;

• Quando uma questão do tipo Picture é enviada ao servidor com uma foto grande (2 MBy-tes) o a aplicação para de responder, gerando um aviso de ANR.

CAPÍTULO

9Estudo de Caso

A fim de avaliar o funcionamento do sistema em modo de produção, este capítulo apresenta osresultados da CMD usando o Maritaca em um cenário real.

9.1 Cenário

A Universidade Federal de São Paulo campus São José do Campos iniciou suas atividades em2007 com apenas um curso, cinquenta alunos e dez docentes. Com um evolução rápida, noano de 2012 possuía cerca de mil alunos e oitenta docentes distribuídos entre três cursos e trêsturnos diferentes. Para atender esse público, o campus possui uma cantina e um restauranteuniversitário (criado em 2011), sendo que o último possui parte do valor da refeição subsidiadopela universidade. As refeições são oferecidas em dois horários, no almoço a partir das dozehoras até às catorze horas e no jantar a partir das dezoito horas até às vinte horas.

O Maritaca foi usado nesse cenário para coletar informações sobre a satisfação dos usuáriosdo restaurante universitário durante 15 dias.

44

Capítulo 9. Estudo de Caso 45

9.2 Formulário

As imagens da Seção 6.1 demonstram a construção da aplicação Bandejão, a mesma utilizadanessa demonstração. O formulário digital é composto pelos seguintes itens:

• Qual o seu nome? Figura 9.1(a);

• Qual o seu curso? Figura 9.1(b);

• Qual a data da refeição? Figura 9.1(c);

• Qual sua satisfação? Figura 9.1(d);

• Foto da refeição. Figura 9.1(e).

(a) Pergunta não obrigatória do tipotexto.

(b) Pergunta obrigatória do tipoRadioButton com as opções BCC,BCT ou BMC.

(c) Pergunta obrigatória do tipodata.

(d) Pergunta obrigatória do tipo Ra-dioButton com as opções ótimo,bom, regular, ruim.

(e) Questão não obrigatória do tipoPicture.

Figura 9.1: Questões do formulário Bandejão.


A representação desse formulário pelo sistema é feita por arquivos XML. O formulárioBandejão está especificado em um arquivo XML mostrado no Apêndice A.

O formulário foi criado com a política de compartilhamento hierárquico, ou seja, o criadortem acesso total para leitura e escrita tanto das respostas como do formulário e os convidadostem acesso apenas a leitura do formulário e escrita das respostas. Neste cenário, três coletoresdiferentes participaram da aquisição dos dados e cada um possuía seu respectivo dispositivoAndroid. Os dispositivos, assim como suas versões do Android são listados abaixo.

• Samsung Galaxy SIII, Android versão 4.1.2 Jelly Bean;

• Samgung Galaxy Nexus, Android versão 4.2.2 Jelly Bean;

• Samsung Galaxy 5, Android versão 2.3.3 Gingerbread;

9.3 Resultados

Na aplicação Android e no gerenciador web de formulários é possível ver as respostas coletadaspara cada questionário na forma de tabelas, como mostra a Figura 9.3.

Atente ao fato que não é escopo deste trabalho dissertar sobre a qualidade ou opinião dosalunos e docentes em relação ao restaurante universitário.

O sistema Maritaca de um modo geral respondeu bem aos comandos, sua interface é intui-tiva e os coletores não tiveram problemas em usá-la. Um ponto controverso percebido peloscoletores é que as componentes móvel e web impõe ao usuário sua autenticação de hora emhora, ou seja, depois de sessenta minutos contados a partir da autenticação, o usuário é auto-maticamente desconectado do sistema. Esse método contribui para elevar a segurança porquedificulta que um usuário não autorizado colete informações, porém em algumas situações comoo dispositivo não conseguir acessar a internet por estar em uma área sem cobertura pode obstruiro coletor de usar o sistema.

O resultado da coleta de dados do formulário Bandejão pode ser visualizada na Figura 9.2,que contém um gráfico gerado pelos dados da satisfação dos usuários do restaurante universi-tário da Unifesp. Este gráfico foi criado através da funcionalidade de geração automatizada derelatórios do sistema web.

Foram realizadas no total trinta e seis coletas, sendo que dez delas possuem conteúdo multi-mídia. A Figura 9.3 mostra algumas das respostas do formulário Bandejão retiradas da interfaceweb do Maritaca. O sistema mostra os dados coletados em formato tabular e ao clicar nas ima-gens na coluna mais à direita, outra janela surge mostrando a imagem na sua resolução original.


Figura 9.2: Relatório gerado a partir dos dados coletados no formulário Bandejão.

Figura 9.3: Respostas do formulário Bandejão incluindo arquivos de imagens.

CAPÍTULO

10Conclusões

Este capítulo apresenta as considerações finais deste Trabalho de Conclusão de Curso, as prin-cipais contribuições e os trabalhos futuros que poderão complementar o que foi realizado.

10.1 Considerações Finais

A automatização da Coleta Móvel de Dados é um processo positivo e a tendência de aumentarsua adoção é alta por incorporar vantagens ambientais e econômicas. O Maritaca é um dos pro-jetos que implementam este procedimento e foi o objeto de estudo deste trabalho. Os objetivosprincipais foram estudar sua arquitetura e colaborar com o desenvolvimento em um dos braçosdo projeto: o módulo Android.

A desenho modular do Maritaca é um conceito bem estabelecido e muito usado pelo mer-cado de desenvolvimento de software. Traz vantagens claras de reusabilidade e manutençãode código. Sua arquitetura baseada na nuvem traz benefícios importantes como a alta escala-bilidade e permite que o usuário acesse os serviços do sistema em qualquer lugar do mundo,independente da plataforma usada, desde que tenha acesso à internet.

As funcionalidades desenvolvidas abordaram diferentes tópicos da arquitetura do Maritacaassim como das bibliotecas do Android, fornecendo uma visão mais ampla e concreta de am-bos. As principais implementações foram o slider, o sistema de notificações e a interface deconfiguração, detalhadas no Capítulo 8.

48

Capítulo 10. Conclusões 49

10.2 Contribuições

Este Trabalho de Conclusão de Curso deixa como contribuição as experiências e lições apren-didas na participação no projeto open source Maritaca em um ambiente de desenvolvimentodistribuído. Além de colaborações no código fonte da componente móvel Android. Este traba-lho também pode ser útil como manual e avaliação do sistema.

10.3 Trabalhos Futuros

O projeto Maritaca está numa versão estável, mas há muitos recursos e funcionalidades existen-tes que podem ser melhoradas e novas que podem ser criadas, já que o campo da Coleta Móvelde Dados é bastante abrangente. Abaixo estão descritos dos objetivos futuros mais significati-vos:

• Colaborar no desenvolvimento de outras componentes do sistema, como o servidor ebases de dados;

• Aumentar a abrangência do sistema tornando-o multiplataforma, criando aplicações paraWeb, iOS e BlackBerryOS;

• Analisar a capacidade do sistema, semelhante ao que foi feito no Capítulo 9, porém inse-rindo quantidades maiores de informações usando todos os tipos de perguntas do formu-lário digital;

Referências Bibliográficas

ANATEL Brasil ultrapassa um celular por habitante, disponível em: http://goo.gl/BRnJh (acessado em 28/03/2013), 2010.

ANATEL Telefonia móvel fecha 2012 com 261,78 milhões de linhas, disponível em: http://goo.gl/Xam8j (acessado em 29/01/2013), 2013.

ARMBRUST, M.; FOX, A.; GRIFFITH, R.; JOSEPH, A.; KATZ, R.; KONWINSKI, A.; LEE,G.; PATTERSON, D.; RABKIN, A.; STOICA, I.; et al. A view of cloud computing. Com-munications of the ACM, v. 53, n. 4, p. 50–58, 2010.

BORNSTEIN, D. Dalvik vm internals. In: Google I/O Developer Conference, 2008, p. 17–30.

BORTHAKUR, D.; GRAY, J.; SARMA, J. S.; MUTHUKKARUPPAN, K.; SPIEGELBERG, N.;KUANG, H.; RANGANATHAN, K.; MOLKOV, D.; MENON, A.; RASH, S.; SCHMIDT, R.;AIYER, A. Apache hadoop goes realtime at facebook. In: Proceedings of the 2011 ACMSIGMOD International Conference on Management of data, SIGMOD ’11, New York, NY,USA: ACM, 2011, p. 1071–1080 (SIGMOD ’11, ).Disponível em http://doi.acm.org/10.1145/1989323.1989438

BRAHLER, S. Analysis of the android architecture. Karlsruhe institute for technology, 2010.

CHACON, S.; ALJORD, P. Pro git. Springer-verlag New York Inc, 2009.

CONDER, S.; DARCEY, L. Android wireless application development: Android essentials,v. 1. Addison-Wesley Professional, 2012.

DOFORMS INC. Official doforms website, disponível em: http://www.doforms.com/(acessado em 28/03/2013), 2013.

DUBEY, A.; WAGLE, D. Delivering software as a service. The McKinsey Quarterly, v. 6,p. 1–12, 2007.

ECLIPSE FOUNDATION Eclipse, disponível em: http://www.eclipse.org (acessadoem 14/04/2012), 2012.

50


EHRINGER, D. The dalvik virtual machine architecture. Techn. report (March 2010), 2010.Disponível em http://goo.gl/v2eIy

ERIC FREEMAN, ELISABETH FREEMAN, K. S. B. B. Head first design patterns. O’ReillyMedia, 2007.

FIELDING, R. T.; TAYLOR, R. N. Principled design of the modern web architecture. ACMTrans. Internet Technol., v. 2, n. 2, p. 115–150, 2002.Disponível em http://doi.acm.org/10.1145/514183.514185

GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Design patterns: Elements of reusableobject-oriented software. Pearson Education, 1994.Disponível em http://books.google.com.br/books?id=6oHuKQe3TjQC

GARTNER INC. Gartner says worldwide mobile phone sales declined 1.7 percent in 2012.http://goo.gl/Nxi8K (acessado em 28/03/2013), 2013.

GOOGLE; MEDIACT, I. Nosso planeta mobile: Brasil, disponível em: http://goo.gl/1yfr6 (acessado em 29/01/2013), 2012.

GOOGLE INC. Adt plugin for eclipse, disponível em: http://developer.android.com/sdk/eclipse-adt.html (acessado em 03/06/2012), 2012a.

GOOGLE INC. Android developers, disponível em: http://developer.android.com/index.html (acessado em 06/02/2013), 2012b.

GOOGLE INC. Official android website, disponível em: http://www.android.com/(acessado em 28/03/2013), 2013.

HASHIMI, S. Y.; KOMATINENI, S.; GOYAL, V. Pro android. Apress New York, 2009.

HECTOR COMMUNITY Official hector website, disponível em: http://hector-client.org (acessado em 29/03/2013), 2013.

JADKOWSKI, M. Best practices in mobile data collection, disponível em: www.doforms.com/support/best-practices.pdf (acessado em 04/06/2012), 2012.

JBOSS COMMUNITY Official resteasy website, disponível em: http://www.jboss.org/resteasy/ (acessado em 04/04/2013), 2013.

LAKSHMAN, A.; MALIK, P. Cassandra: a decentralized structured storage system. SIGOPSOper. Syst. Rev., v. 44, n. 2, p. 35–40, 2010.

MAKER, F. Android dalvik virtual machine, disponível em: http://goo.gl/7DvOD(acessado em 20/02/2013), 2011.

MIT Official mit app inventor website, disponível em: http://appinventor.mit.edu/ (acessado em 28/03/2013), 2013.


NETO, ARISTIDES V. P. Criando testes com junit, disponível em: http://goo.gl/jjDgR(acessado em 10/06/2012), 2009.

NOKIA CORP. Nokia data gathering in action, disponível em: https://projects.developer.nokia.com/ndg/wiki/projects (acessado em 29/03/2013), 2013a.

NOKIA CORP. Official nokia data gathering website, disponível em: https://projects.developer.nokia.com/ndg/wiki (acessado em 28/03/2013), 2013b.

OAUTH COMMUNITY Official oauth website, disponível em: http://oauth.net/2/(acessado em 04/04/2013), 2013.

ODK COMMUNITY Official open data kit website, disponível em: http://opendatakit.org/ (acessado em 28/03/2013), 2013.

OPEN HANDSET ALLIANCE Open handset alliance official website, disponível em: http://www.openhandsetalliance.com/ (acessado em 14/04/2012), 2012.

OPENID FOUNDATION Official openid website, disponível em: http://openid.net/developers/ (acessado em 25/06/2012), 2012.

ORACLE CORP. Official jax-rs website, disponível em: http://jax-rs-spec.java.net/ (acessado em 04/04/2013), 2013a.

ORACLE CORP. Official jsf website, disponível em: http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html (acessado em31/03/2013), 2013b.

PRESSMAN, R. Engenharia de software. McGraw-Hill, 2006.

SCHREIER, S. Modeling restful applications. In: Proceedings of the Second InternationalWorkshop on RESTful Design, WS-REST ’11, New York, NY, USA: ACM, 2011, p. 15–21(WS-REST ’11, ).Disponível em http://doi.acm.org/10.1145/1967428.1967434

SIERRA, K.; BATES, B. Head first java. O’Reilly Media, Incorporated, 2005.

SIMPLE COMMUNITY Official simple website, disponível em: http://simple.sourceforge.net/ (acessado em 04/04/2013), 2013.

SQLITE COMMUNITY Official sqlite website, disponível em: http://www.sqlite.org/ (acessado em 04/04/2013), 2013.

STRAUCH, C.; SITES, U.-L. S.; KRIHA, W. Nosql databases. 2011.Disponível em http://www.christof-strauch.de/nosqldbs.pdf

THE APACHE SOFTWARE FOUNDATION Official cassandra website, disponível em: http://cassandra.apache.org/ (acessado em 29/03/2013), 2013a.


THE APACHE SOFTWARE FOUNDATION Official hadoop website, disponível em: http://hadoop.apache.org/ (acessado em 29/03/2013), 2013b.

THE JQUERY FOUNDATION Official jquery website, disponível em: http://jquery.com/ (acessado em 29/03/2013), 2013.

VMWARE INC. Official rabbitmq website, disponível em: http://www.rabbitmq.com/(acessado em 04/04/2013), 2013.

W3C The syntax, vocabulary and apis of html5, disponível em: http://dev.w3.org/html5/html-author/ (acessado em 31/03/2013), 2010.

APÊNDICE

AEspecificação de Formulário no

Arquivo XML

O arquivo XML abaixo descreve a especificação do formulário digital Bandejão, que foi usadono capítulo 9.

<?xml version="1.0" encoding="UTF-8"?><form>

<title>Bandejão</title><questions>

<text id="0" next="1" required="false" ><label>Qual seu nome?</label><help></help><size>100</size><default></default>

</text><radio id="1" next="2" required="true" >

<label>Qual seu curso?</label><help></help><default></default><option value="0" checked="false">BCC</option><option value="1" checked="false">BMC</option><option value="2" checked="false">BCT</option>

</radio><date id="2" next="3" required="true" >

<label>Data da refeição.</label><help></help><default></default><format>mm/dd/yy</format>

54

Capítulo A. Especificação de Formulário no Arquivo XML 55

</date><radio id="3" next="4" required="true" >

<label>Qual sua satisfação?</label><help></help><default></default><option value="0" checked="false">Ótimo</option><option value="1" checked="false">Bom</option><option value="2" checked="false">Regular</option><option value="3" checked="false">Ruim</option>

</radio><picture id="4" next="-1" required="false" >

<label>Foto da Refeição</label><help></help>

</picture></questions>

</form>

APÊNDICE

BClasse Question

O arquivo Java abaixo representa a classe abstrata Question, peça importante do sistema móveldo Maritaca. Note que algumas linhas de código foram ocultadas (imports, package, getters esetters) porque não são necessárias para compreensão de sua implementação.

/* Imports and Package (Hidden)*/

public abstract class Question implements Serializable {

private static final long serialVersionUID = 1L;

@Attribute(required = true)protected Integer id;

@Attribute(required = false)protected Integer next;

@Attribute(required = false)protected Integer previous;

@Element(required = false)protected String help;

@Element(name = "default", required = false)protected String _default;

@Attribute(required = false)protected Boolean required;

56

Capítulo B. Classe Question 57

@Elementprotected String label;

protected Object value;

@ElementListUnion({@ElementList(entry = "equal", inline = true,type = Equal.class, required = false),@ElementList(entry = "less", inline = true,type = Less.class, required = false),@ElementList(entry = "greater", inline = true,type = Greater.class, required = false),@ElementList(entry = "lessequal", inline = true,type = LessEqual.class, required = false),@ElementList(entry = "greaterequal", inline = true,type = GreaterEqual.class, required = false) })

protected List<Comparison> comparisons;

/* Abstract methods */public abstract ComponentType getComponentType();

public abstract Object getValue();

public abstract View getLayout(ControllerActivity activity);

public abstract boolean validate();

public abstract void save(View answer);

/* Getters and Setter (Hidden)*/}

Coleta Móvel de Dados em dispositivos Android: um estudo...

Documents

Transcript of Coleta Móvel de Dados em dispositivos Android: um estudo...