Marita CA Tutorial

Coleta Mvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca
Leonardo Betto Sueoka
Trabalho de concluso de curso apresentado ao Instituto de Cincia e Tecnologia UNIFESP, como parte das atividades para obteno do ttulo de Bacharel em Cincia da Computao.
Orientador: Prof. Dr. Arlindo Flavio da Conceio
So Jos dos Campos SP Maro, 2013
Trabalho de concluso de curso apresentado ao Instituto de Cincia e Tecnologia UNIFESP, como parte das atividades para obteno do ttulo de Bacharel em Cincia da Computao.
Orientador: Prof. Dr. Arlindo Flavio da Conceio
Banca Examinadora: Prof. Dr. Arlindo Flavio da Conceio Prof. Dr. Ezequiel Roberto Zorzal Prof. Dr. Luiz Eduardo Galvo Martins
Aprovado em:
Aos meus pais, pelo amor, dedicao e pelo eterno incentivo.
Agradecimentos
Agradeo minha famlia e meus amigos Mathias, Scott, Vivian, Konishi e Marcio, pois com vocs minha vida universitria foi mais divertida. A minha namorada Cssia Vieira de Oliveira pelas palavras de incentivo e por estar sempre presente. Ao membros da equipe Maritaca, sempre prestativos para ajudar. Agradeo tambm ao meu orientador Arlindo Flavio da Conceio e a todos meus professores, pois eles ajudaram a formar o que sou hoje.
Resumo
de dados um campo com muito espao para o uso de dispositivos mveis, como os smartphones Android. O projeto Maritaca tem como objetivo o desenvolvimento de uma infraestrutura para um sistema distribudo de coleta mvel de dados (CMD), com base em formulrios digitais, na qual trs componentes se destacam: a aplicao do dispositivo Android, os servios web para gerenciamento dos formulrios e os repositrios de dados. Este trabalho est focado no estudo da arquitetura do Maritaca e no desenvolvimento colaborativo da componente Android. Este trabalho gerou como resultados a criao de novas funcionalidades para a componente mvel Android, assim como a avaliao e um caso de uso do sistema. Palavras-chave: TCC, Android, Coleta Mvel de Dados, Sistemas Distribudos.
C oleta
Abstract
data collection is a eld with a large space for mobile devices, such as the Android smartphones. The Maritaca project aims the development of an infrastructure for a mobile data collection (MDC) distributed application, based in digital forms, in wich three components are highlighted: Android application, form management web services and the databases. This work is focused on study the Maritacas architecture and collaborative development of Android component. This work has produced results as the creation of new features for the Android mobile component, as well as evaluation and a case of use of the system.
He
Keywords: TCC, Android, Mobile Data Collection, Distributed Systems.
ii
Sumrio
Resumo Abstract Lista de Figuras Lista de Tabelas Lista de Acrnimos 1 Introduo 1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Organizao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Android e a Mquina Virtual Dalvik 2.1 Histrico . . . . . . . . . . . . 2.1.1 Histrico das Verses . . 2.2 Arquitetura . . . . . . . . . . . 2.3 Fragmentao . . . . . . . . . . 2.4 A Mquina Virtual Dalvik . . . 2.4.1 Arquivos .dex . . . . . .
i ii vi vii viii 1 2 3 4 4 5 6 8 9 9 12 12 13 13 14 14 15 15 16
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Trabalhos Relacionados Coleta Mvel de Dados 3.1 MIT App Inventor . . . . . . . . . . . . . . . . 3.2 Nokia Data Gathering (NDG) . . . . . . . . . . 3.3 Open Data Kit (ODK) . . . . . . . . . . . . . . 3.4 doForms . . . . . . . . . . . . . . . . . . . . . 3.5 Consideraes Finais . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Ferramentas e Ambiente de Desenvolvimento Distribudo 4.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
4.3 4.4 4.5 5
Android SDK . . . 4.3.1 Plugin ADT Git . . . . . . . . . SourceForge . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
16 16 16 17 19 20 22 22 23 23 24 27 27 30 31 32 33 33 34 36 38 38 39 40 40 42 42 43 44 44 45 46 48 48 49 49 50 54
Arquitetura do Maritaca 5.1 Viso Geral . . . . . . . . . . . 5.1.1 Servidor . . . . . . . . . 5.1.2 Repositrios de Dados . 5.2 Sistema Mvel . . . . . . . . . 5.2.1 MVC no Sistema Mvel 5.2.2 Engine . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Funcionalidades do Sistema 6.1 Utilizao . . . . . . . . . . . . . 6.2 Recursos do Formulrio Digital . . 6.3 Compartilhamento de Informaes 6.4 Relatrios . . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Implantao do Maritaca 7.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Implantao no Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.3 Aplicao Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribuies no Cdigo 8.1 Question Slider . . . . . . . . . . 8.1.1 Passos da Implementao 8.2 Servio de Noticaes . . . . . . 8.2.1 Passos da Implementao 8.3 Menu Settings . . . . . . . . . . . 8.3.1 Passos da Implementao 8.4 Problemas Reportados . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Estudo de Caso 9.1 Cenrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Formulrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 Concluses 10.1 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Referncias Bibliogrcas A Especicao de Formulrio no Arquivo XML iv
B Classe Question
56
Lista de Figuras
2.1 2.2 2.3 4.1 5.1 5.2 5.3 5.4 5.5 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7.1 8.1 8.2 8.3 8.4 9.1 9.2 9.3
Arquitetura do Sistema (Google Inc., 2012b). . . . . . . . . . . . . . . . . . . Distribuio Atual de Verses - Maro de 2013 (Google Inc., 2012b). . . . . . Comparativo entre arquivos .dex e .class (Ehringer, 2010). . . . . . . . . . . . Pgina inicial do Maritaca no SourceForge. . . . . . . . . . . . . . . . . . . . Componentes do Maritaca. . . . . . . . . . . . . . . . . . Componentes do Maritaca. . . . . . . . . . . . . . . . . . Relacionamento entre as componentes do MVC na Engine. Estrutura de Classes de Question. . . . . . . . . . . . . . . Estrutura de classes do Comparison. . . . . . . . . . . . . Tela de login. . . . . . . . . . . . . . . . . . . . Tela principal. . . . . . . . . . . . . . . . . . . . Criao de formulrios. . . . . . . . . . . . . . . Autenticao e tela principal do aplicativo mvel. Exemplos de questes no aplicativo mvel. . . . Interface para elaborao de relatrios. . . . . . . Menu de acesso aos relatrios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 8 11 18 20 21 24 25 26 28 28 29 30 30 32 32 37 39 40 41 42 45 47 47
Modos de importar projetos no Eclipse. . . . . . . . . . . . . . . . . . . . . . Customizao da componente Seek Bar Noticao de novos dados coletados. . Fluxograma do sistema de noticaes. Tela Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Questes do formulrio Bandejo. . . . . . . . . . . . . . . . . . . . . . . . . Relatrio gerado a partir dos dados coletados no formulrio Bandejo. . . . . . Respostas do formulrio Bandejo incluindo arquivos de imagens. . . . . . . .
vi
Lista de Tabelas
2.1 6.1 7.1
Comparao do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). . Polticas de compartilhamento de dados no Maritaca. . . . . . . . . . . . . . . Arquivo de congurao conguration.properties. . . . . . . . . . . . . . . . .
10 31 35
vii
Lista de Acrnimos
AAC ANR API BCC BCT BMC CDMA CMD CRUD CVS DVCS DVM GFS HDP HTML HTTP IDE JavaME JavaSE JDK JPEG JSF JSR JVM Maritaca MIT MPEG MVC NDG NFC ODK OHA
Advanced Audio Coding Application Not Responding Application Programming Interface Bacharelado em Cincia da Computao Bacharelado em Cincia e Tecnologia Bacharelado em Matemtica Computacional Code Division Multiple Access Coleta Mvel de Dados Create, Read, Update, Delete Concurrent Version System Distributed Version Control System Dalvik Virtual Machine Google File System Health Device Prole Hypertext Markup Language Hypertext Transfer Protocol Integrated Development Environment Java Mobile Edition Java Standart Edition Java Development Kit Joint Photographic Experts Group Java Server Faces Java Specication Request Java Virtual Machine MARitaca Is a Tool to creAte Cellular phone Applications Massachusetts Institute of Technology Moving Picture Experts Group Model, View, Controller Nokia Data Gathering Near Field Communication Open Data Kit Open Handset Alliance
viii
PNG REST SaaS SDK SMS SQL VCS XML WAR
Portable Network Graphics Representional State Transfer Software as a Service Software Development Kit Short Message Service Structured Query Language Version Control System eXtensible Markup Language Web application ARchive
ix
C APTULO
1
Introduo
Obter informaes de diferentes localidades, armazen-las e analis-las, na maioria das vezes ainda so processos manuais. As informaes coletadas so muitas vezes transcritas para formulrios impressos e depois arquivadas, consumindo espao e recursos. A coleta de dados praticada com formulrios impressos suscetvel a erros humanos, assim como qualquer procedimento manual, dessa forma, natural que a coleta de dados a partir de dispositivos mveis se sobressaia como uma soluo vivel para automatizar esse processo. Dispositivos mveis como celulares, tablets e smartphones so aparelhos cada vez mais presentes na vida das pessoas. De acordo com a Anatel, no ano de 2010 o Brasil havia ultrapassado a marca de um celular por habitante, o que signica mais de 190 milhes de dispositivos mveis em territrio nacional (Anatel, 2010). Com um aumento expressivo, o Brasil fechou o ano de 2012 com 261 milhes de linhas mveis (Anatel, 2013). Desse montante aproximadamente 27 milhes so os chamados smartphones (Google e MediaCT, 2012). Um smartphone, ou celular inteligente, um pequeno computador com diversos instrumentos como sensores, cmeras, conectividade sem o, GPS (Global Positioning System) e uma tela sensvel ao toque. Apesar de muitos recursos, os smartphones possuem limitaes como alimentao por bateria, memria principal e armazenamento em disco reduzidos. O Android uma plataforma baseada no Linux desenvolvida especicamente para smartphones. O Android um projeto open source, ou seja, possui o cdigo aberto, mantido pela Open Handset Alliance (OHA) que formada por um grupo de grandes empresas, lideradas pela Google, interessadas 1
Captulo 1. Introduo
na evoluo dessa plataforma. De acordo com dados do nal de 2012, 69,7% da parcela do mercado pertence ao Android (Gartner Inc., 2013). A adoo de dispositivos mveis inteligentes e o abandono do uso de formulrios impressos na Coleta Mvel de Dados (CMD) pode gerar uma grande economia de material (pranchetas, folhas de papis e tintas para impresso etc.), alm de importantes benefcios ambientais. Por exemplo, o custo ambiental de uma folha de escritrio, considerando todo o processo desde cultivo e retirada da rvore, produo de papel e eliminao de resduos, de 20,9 gramas de emisso de dixido de carbono na atmosfera. E a cada 80 mil e 500 folhas de papis no fabricadas uma rvore salva (Jadkowski, 2012). Apenas a praticidade de utilizar smartphones para CMD aliada as suas vantagens econmicas e ambientais j justicariam sua implementao. Mas alm desses benefcios, eles possibilitam o uso de recursos multimdia como fotos, udio e vdeo. Tais recursos tornam muito mais ricas tanto a interao dos usurios quanto a qualidade das informaes presentes nos formulrios digitais, pois a apresentao da informao ocorre de maneira multissensorial, estimulando mais os sentidos humanos do que um texto comum. O projeto Maritaca (MARitaca Is a Tool to creAte Cellular phone Applications) busca suprir as necessidades de automatizar o processo de CMD provendo uma infraestrutura baseada na nuvem para criao de aplicativos mveis para smartphones Android. Esses aplicativos representam os formulrios digitais. O Maritaca proporciona uma interface web interativa para a concepo do formulrio e o gerenciamento das informaes coletadas. O projeto possui trs vertentes principais: a aplicao mvel Android, os servios web e os repositrios de dados. O foco deste trabalho estudar a arquitetura do Maritaca com nfase na componente mvel Android e colaborar com seu desenvolvimento.
1.1
Objetivos
O objetivo deste trabalho estudar a arquitetura da componente mvel Android do projeto Maritaca, como ela interage com as outras componentes e colaborar com seu desenvolvimento em um ambiente distribudo e open source. Tambm faz parte do escopo integrar a equipe de desenvolvedores do projeto, assim como explorar as funcionalidades do sistema em uma situao real. Pode-se listar os seguintes objetivos especcos: 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 questo do formulrio digital: o slider;
Captulo 1. Introduo
Um sistema de noticaes que informa ao usurio a quantidade de novas coletas realizadas por outros usurios que compartilham o mesmo formulrio; Uma interface na qual o usurio pode denir conguraes sobre o intervalo de sincronizao com o servidor. Para mais informaes sobre o projeto Maritaca acesse http://maritaca.unifesp. br.
1.2
Organizao do Texto
Este trabalho est organizado em nove captulos. O Captulo 2 disserta sobre o histrico do Android e esclarece os principais conceitos e caractersticas dessa plataforma e de sua mquina virtual chamada Dalvik. O Captulo 3 compara o Maritaca com outros trabalhos com objetivos e funcionalidades similares. As ferramentas colaborativas utilizadas no desenvolvimento do Maritaca so listadas e descritas no Captulo 4. O Captulo 5 apresenta a arquitetura aplicada no desenvolvimento do sistema com foco no sistema mvel. O Captulo 6 expe as caractersticas funcionais do sistema e pode ser usado como tutorial para sua utilizao. A implantao do mdulo servidor e mvel descrita no Captulo 7. O Captulo 8 apresenta as principais contribuies para a componente mvel. O Captulo 9 apresenta um caso de uso do sistema e comenta sobre o potencial da ferramenta e, por m, o Captulo 10 discorre sobre as lies aprendidas, consideraes nais e trabalhos futuros.
C APTULO
2
Android e a Mquina Virtual Dalvik
A plataforma Android (Google Inc., 2013) um sistema operacional para dispositivos celulares com alto poder computacional, conhecidos como smartphones. A capacidade de processamento melhorada a medida que a demanda por tal capacidade aumenta e esse crescimento tende a aumentar ao longo dos anos. Usurios cada vez mais exigentes e aplicaes cada vez mais complexas e sosticadas surgiro. O objetivo dessa plataforma prover um sistema aberto, no qual os desenvolvedores de aplicaes possam usar quaisquer recursos disponveis para cada aparelho, inclusive os utilizados pelas aplicaes internas, aproveitando ao mximo o que eles tm a oferecer. Este captulo discorre sobre o histrico, arquitetura, desaos e a mquina virtual da plataforma Android.
2.1
Histrico
A Google adquiriu uma startup chamada Android Inc., em 2005, com o objetivo de entrar no mercado de dispositivos mveis. 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 mveis 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
Captulo 2. Android e a Mquina Virtual Dalvik
aliana comercial composta por muitas das maiores e bem sucedidas empresas do mundo. Seus membros representam toda a cadeia comercial de dispositivos mveis, incluindo fabricantes de chips, fabricantes de celulares, desenvolvedores de software e provedores de servio (Conder e Darcey, 2012). Alm disso, objetivo da OHA garantir que o projeto tenha cdigo aberto e assim reagir mais rapidamente e de forma inovadora as exigncias do mercado (Open Handset Alliance, 2012). Em novembro de 2007, foi divulgada uma verso pr-lanamento do Android SDK (Software Development Kit) e j em 2008 foi lanado o primeiro aparelho baseado na plataforma Android, o T-Mobile G1. Poucos dias depois a verso 1.0 do Android SDK foi lanada e em outubro de 2008 a Google tornou o cdigo fonte da plataforma Android aberto sob a licena Apache (Hashimi et al., 2009). A partir desse momento, muitas fabricantes comearam a produzir dispositivos Android em 2009 e incio de 2010. A plataforma ganhou mercado rapidamente e no nal de 2010 o Android tornou-se lder de mercado, ganhando espao de plataformas competitivas como o BlackBerry da RIM, o iOS da Apple e o Windows Mobile (Conder e Darcey, 2012).
2.1.1
Histrico das Verses
Vrias verses do Android foram lanadas desde seu incio, agregando novos recursos e funcionalidades. Atualmente o Android encontra-se na verso 4.2 Jelly Bean. O histrico da evoluo das verses, assim como as principais mudanas e suas datas de lanamento so listadas abaixo (Google Inc., 2012b): 1.1 - Fevereiro de 2009: Verso inicial; 1.5 (Cupcake) - Abril de 2009 Nova API, renamentos da interface de usurio, melhorias de desempenho, atualizao do Kernel do Linux para a verso 2.6.27. 1.6 (Donut) - Setembro de 2009 Nova API, aperfeioamento da interface de usurio, atualizao do Kernel do Linux para a verso 2.6.29, suporte para resolues e densidades de telas, suporte para CDMA, API para reconhecimento de gestos e uma engine de texto-para-fala. 2.0, 2.1 (clair) - Outubro de 2009 Nova API, aperfeioamento da interface de usurio, melhoria na renderizao de grcos, bluetooth 2.1,
2.2 (Froyo) - Maio de 2010 Nova API, aperfeioamento da interface de usurio, novo framework de mdia, novas funcionalidades para o bluetooth, atualizao do Kernel do Linux para a verso 2.6.32. 2.3 (Gingerbread) - Dezembro de 2010 Nova API, aperfeioamento da interface de usurio, suporte para NFC (Near Field Communications), mudanas na Dalvik e atualizao do Kernel do Linux para a verso 2.6.35. 3.0, 3.1, 3.2 (Honeycomb) - Fevereiro de 2011 As melhorias das verses do Android Honeycomb so focadas em adaptaes para os tablets. Nova API, aperfeioamento da interface de usurio. 4.0, 4.0.1, 4.0.3, 4.0.4 (Ice Cream Sandwich) - Outubro de 2011 Nova API, aperfeioamento da interface de usurio, novos recursos multimdia, novos tipos de conectividade como o Wi-Fi Direct e Bluetooth Health Device Prole (HDP). 4.1, 4.2 (Jelly Bean) - Julho de 2012 Melhorias de segurana, otimizaes na Dalvik, evoluo do software da cmera e bluetooth, melhora no suporte ao NFC (Android Beam) e reproduo de udio com baixa latncia.
2.2
Arquitetura
O Android composto por uma pilha de software que inclui um Sistema Operacional, Middleware e aplicaes chave (Google Inc., 2012b). A arquitetura do Android composta pelas componentes mostradas na Figura 2.1. Essa pilha composta por cinco camadas: Aplicaes, Framework para Aplicaes, Bibliotecas juntamente com a Android Runtime e Kernel do Linux. A camada de Aplicaes o conjunto de todos os aplicativos instalados no dispositivo e que so escritos com uma sintaxe similar ao do Java. Estes so todos os aplicativos nativos indispensveis (tais como navegador de internet, cliente de correio eletrnico, aplicativo para gerenciar SMS, calendrio, contatos etc.) e os aplicativos que o usurio pode instalar pela Google Play (Google Inc., 2012b). Na camada Application Framework, esto todas as APIs disponibilizadas no SDK do Android para desenvolver aplicaes ricas utilizando os diversos recursos presentes nesse sistema operacional, como: Views: so usadas para construir a interface com o usurio (telas da aplicao);
Figura 2.1: Arquitetura do Sistema (Google Inc., 2012b). Content Providers: possibilitam que aplicaes troquem informaes entre si; Resource Manager: permite acesso a arquivos externos como grcos, arquivos de layout e de internacionalizao; Notication Manager: prov a capacidade de gerar noticaes personalizadas na barra de status; Activity Manager: gerencia o ciclo de vida das aplicaes e o uxo de navegao. A camada de bibliotecas representa um conjunto de bibliotecas escritas em C e C++ que possuem funcionalidades especcas e muito usadas pela camada acima. Nessa camada encontram-se bibliotecas para execuo de mdia altamente otimizadas para dispositivos com recursos limitados (Brahler, 2010), como codicadores e decodicadores para execuo e gravao de vdeo (H264, MPEG4), udio (MP3, AAC, AMR) e imagens (JPEG, PNG). Inclui-se nessas bibliotecas o SQLite (SQLite Community, 2013), pacotes para renderizao 2D e 3D, entre outros (Google Inc., 2012b). J a Runtime Android possui bibliotecas chaves do Java, alm da DVM (Dalvik Virtual Machine) que ser mais detalhada na Seo 2.4 (Google Inc., 2012b). Na camada de mais baixo nvel, h o Kernel Linux na verso 2.6 modicado para atuar em aspectos fundamentais do sistema como gerenciamento do consumo de energia, memria,
processos, rede e segurana. Alm de operar tambm como intermediria entre o hardware e as outras camadas da pilha (Google Inc., 2012b).
2.3
Fragmentao
Um tema que gera muita discusso entre usurios e fabricantes do Android o problema de fragmentao. O Android continua evoluindo rapidamente desde seu incio e, com isso, muitas verses foram lanadas. Existem diversas verses deste sistema operacional instalados em diversos modelos de smartphones de diversas marcas, desde a antiga verso 1.5 lanada em abril de 2009, tambm chamada de Cupcake, at recm-lanada verso 4.2, chamada de Jelly Bean. A discusso se d pela incompatibilidade das verses que esto sendo efetivamente utilizadas pelos usurios, ou seja, existem dispositivos Android ativos em todas as suas verses. De acordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as verses do Android Gingerbread, 28,6% possuem as verses do Ice Cream Sanduich, 15,5% possuem as verses mais recente do Jelly Bean e tambm 7,5% possuem verso 2.2 Froyo. De fato, h uma fragmentao de verses no Android. O grande problema da fragmentao que as verses antigas no desfrutam de todas as novas funcionalidades das verses mais atuais, alm disso, os desenvolvedores de aplicativos priorizam o suporte de seus produtos para as verses mais recentes. Ou seja, os usurios que possuem smartphones com Android desatualizado no possuem acesso aos aplicativos que exigem as verses mais recentes instaladas. Por um lado existe o aspecto negativo, que a fragmentao, mas pelo outro h o aspecto positivo que a evoluo rpida e constante do sistema.
Figura 2.2: Distribuio Atual de Verses - Maro de 2013 (Google Inc., 2012b).
Fabricantes vendem seus smartphones e tablets com determinadas verses do Android e ca sob seu juzo a atualizao desses aparelhos quando so lanadas novas verses. Porm, desenvolver pacotes de atualizao gera despesas e geralmente apenas os aparelhos mais populares os recebem. Note que o aparelho precisa ter poder de processamento suciente para executar as verses mais novas, ou seja, os aparelhos mais antigos dicilmente recebero atualizaes do Android.
2.4
A Mquina Virtual Dalvik
Grande parte do sucesso de uma plataforma para smartphones se d pela sua capacidade de cativar desenvolvedores de aplicativos dessa plataforma. A Google escolheu o Java para ser a linguagem primria do Android pela grande comunidade de desenvolvedores e pela relativa facilidade de utilizao. Apesar disso, a Dalvik no uma verdadeira plataforma Java. O Android usa uma implementao alternativa e mais limitada da biblioteca padro do Java, na qual grande parte das bibliotecas principais do JavaSE esto presentes. Alguns dos motivos da Google decidir criar sua prpria mquina virtual no padronizada foram os problemas apresentados pelo JavaMe, problemas burocrticos no licenciamento de novas funcionalidades do Java pelo JSR (Java Specication Request), desempenho, segurana, entre outros (Maker, 2011). O objetivo da plataforma Android abranger a maior quantidade possvel de dispositivos, desde os mais antigos de baixa capacidade at os mais atuais de alta capacidade. Essa inteno faz com que os dispositivos obsoletos imponham que a plataforma seja eciente o suciente para que tais dispositivos sejam capazes de execut-la. A execuo do Android precisa suportar condies como baixa capacidade de processamento, baixa capacidade da memria RAM, nenhum espao para swap, funcionamento bateria, diversos modelos de dispositivos e execuo segura de aplicativos (Ehringer, 2010). Dados todos esses requisitos a DVM foi projetada para usar o mnimo dos recursos do sistema. Mltiplas instncias da Dalvik so executadas simultaneamente. Este fato ocorre porque cada aplicao Android representa um processo sendo executado, o qual possui uma instncia da DVM. Dessa maneira, os processos cam bem isolados, criando uma forte barreira entre as aplicaes (Maker, 2011).
2.4.1
Arquivos .dex
Na plataforma Java padro, um arquivo .java compilado pela JVM (Java Virtual Machine) e o resultado disso o bytecode Java no arquivo .class correspondente. Por exemplo, um arquivo
10
.java possui uma classe pblica, uma classe esttica interna e trs classes annimas o resultado da compilao sero 5 arquivos .class que sero lidos em tempo de execuo pela JVM (Ehringer, 2010). Apesar da linguagem de desenvolvimento do Android ser o Java, isso no acontece da mesma forma nos dispositivos mveis. Na plataforma Android os arquivos .class continuam sendo gerados, porm a ferramenta chamada dx os converte para a extenso .dex (Dalvik Executable) e so esses arquivos que so executados pela DVM. A funo da dx alm de converter otimizar o uso de memria e o espao em disco, alocando vrios .class em apenas um .dx (Ehringer, 2010). Os arquivos .dex otimizam espao de armazenamento contendo dados nicos, ou seja, no h repetio de informaes. Por exemplo, se vrias classes fazem referncia a uma string constante de caracteres, esse objeto existe apenas uma vez nos arquivos .dex e suas mltiplas ocorrncias so apenas ponteiros para esse objeto (Brahler, 2010). As constantes como strings, campos, variveis, classes, interfaces, e nomes de mtodos so armazenadas em pools de constantes. Um pool um conjunto de recursos inicializados e prontos para serem usados. Na Figura 2.3 so exibidos os pools de constantes em azul. Temos que cada arquivo .class possui seu prprio pool heterogneo de constantes que agrupa todas as constantes em um s lugar. Em contrapartida, o arquivo .dex, que contm vrias classes, possui vrios pools de constantes organizados e compartilhados (Ehringer, 2010). Na Tabela 2.1 os arquivos .dex apenas com as otimizaes citadas no pargrafo anterior possuem menor tamanho em bytes que os arquivos .jar comprimidos. Tabela 2.1: Comparao do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). Bibliotecas do Sistema 21445320 (100%) 10662048 (50%) 10311972 (48%) App Navegador 470312 (100%) 232065 (49%) 209248 (44%) App Alarme 119200 (100%) 61658 (52%) 53020 (44%)
Sem compresso Compresso Jar Arquivo Dex sem compresso
11
Figura 2.3: Comparativo entre arquivos .dex e .class (Ehringer, 2010).
C APTULO
3
Trabalhos Relacionados Coleta Mvel de Dados
Existem projetos com objetivos e funcionalidades semelhantes ao do Maritaca e que tiverem seu desenvolvimento iniciado em paralelo. Este captulo analisa esses projetos e os compara ao Maritaca.
3.1
MIT App Inventor
O MIT App Inventor (MIT, 2013) era um projeto da Google que foi descontinuado em agosto de 2011 e teve seu cdigo disponibilizado. O MIT (Massachusetts Institute of Technology) com o apoio da Google criou um centro para estudo sobre tecnologias mveis, cujo objetivo principal dar continuidade ao desenvolvimento do App Inventor para Android. O App Inventor constri uma aplicao sem a necessidade do usurio ter conhecimento de programao. O projeto consiste principalmente de duas aplicaes: o App Inventor Design e o App Inventor Blocks Editor. Semelhante a tela de criao de formulrios do Maritaca, o App Inventor Design possui uma interface intuitiva na qual os componentes so arrastveis e o usurio os posiciona na tela da sua aplicao facilmente. O App Inventor Blocks Editor tem a funo de associar eventos para cada componente adicionado. O App Inventor possui uma 12
Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados
13
interessante funcionalidade que permite ao usurio ver em seu dispositivo mvel a sua aplicao sendo montada em tempo real, desde que o dispositivo esteja conectado em seu computador. O AppInventor uma aplicao com um escopo generalista, voltado para usurios interessados em criar suas prprias aplicaes. J o Maritaca tem um escopo especco: a Coleta Mvel de Dados.
3.2
Nokia Data Gathering (NDG)
O Nokia Data Gathering (Nokia Corp., 2013b) um projeto de cdigo aberto desde 2010 e tem como objetivo a automatizao da coleta mvel de dados. Funciona com a criao de questionrios e o envio dos mesmos para os agentes de campo que acessam os formulrios atravs de seus celulares por uma conexo sem o. As respostas so enviadas central, que as armazena. possvel exportar as informaes coletadas para formatos mais manejveis, tais como planilhas. O NDG utilizado na prtica em alguns projetos sociais. Em Manaus, no estado do Amazonas, juntamente com a Secretaria de Estado de Sade (SUSAM), o NDG foi usado para a coleta de informaes pertinentes as famlias atingidas pela dengue, ajudando no combate doena. Tanto o NDG quanto o Maritaca possuem escopos semelhantes. Uma diferena importante que o NDG est disponvel apenas para a plataforma Java ME e Windows Phone, que possuem parcelas reduzidas de mercado.
3.3
Open Data Kit (ODK)
O projeto ODK (ODK Community, 2013) possui cdigo aberto e composto por um conjunto de ferramentas que auxiliam na criao e gerenciamento da coleta mvel de dados. Entre eles esto: Build, Collect e Aggregate. A Build consiste de uma interface web que possibilita a criao de formulrios interativamente, inclusive com perguntas multimdia, como udio, vdeo e imagens. A Collect uma aplicao para Android que realiza a coleta de dados nos dispositivos mveis Android. A Aggregate gerencia as informaes coletadas atravs dos formulrios que podem ser exportadas para formatos mais usuais, como planilhas. Outras ferramentas que so desenvolvidas pelo ODK so 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 criao de formulrios e gereciamento das informaes coletadas, o ODK basicamente um conjunto de APIs e padres que podem
Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados
14
ser usados por outros projetos. Alguns dos projetos que usam o ODK so: FormHub, EpiSurveyor, Group Complete, KoBo Toolbox, ViewWorld, PhiCollectUm e o doForms, que ser apresentado na prxima seo.
3.4
doForms
O doForms (doForms Inc., 2013) um projeto cuja proposta similar ao Maritaca, porm possui cdigo proprietrio. O doForms baseado no projeto ODK, portanto ambos possuem grandes semelhanas. A aplicao para dispositivos mveis multiplataforma permitindo dispositivos iOS, Android e BlackBerry. possvel usar o sistema gratuitamente com algumas restries, como cota mxima de dados de 200 MB e somente usar a aplicao mvel para um nico dispositivo. Outra restrio que somente alguns tipos de questes podem ser usadas para montar formulrios para usurios com contas gratuitas. Da mesma forma que o NDG e o Maritaca, as respostas coletadas dos questionrios no doForms so enviadas para um servidor. A partir disso, o usurio capaz de gerenciar esses dados e enviar novos formulrios para os dispositivos dos agentes coletores. As principais diferenas entre o doForms e o Maritaca que o primeiro se trata de uma soluo paga e multiplataforma enquanto que o objeto de estudo deste trabalho apresenta uma soluo aberta e exclusiva para a plataforma Android.
3.5
Consideraes Finais
Os trabalhos que mais se assemelham tanto no objetivo quanto nos servios disponibilizados o doForms e o NDG. O doForms e o Maritaca apresentam contextos diferentes visto que o Maritaca apresenta uma soluo aberta, enquanto que para usar o doForms com todas suas funcionalidades necessrio custear uma taxa mensal. Apesar disso, o doForms apresenta uma soluo multiplataforma para sua aplicao mvel, que um benefcio considervel. O NDG aparenta ser a soluo mais madura dentre as citadas, pois possui registros de sua utilizao em situaes signicativas. Alm do caso citado na Seo 3.2, ele foi posto em prtica no Kenya e na frica Oriental (Nokia Corp., 2013a). Como j explanado anteriormente uma desvantagem notvel a aplicao mvel do NDG estar disponvel para plataformas pouco utilizadas.
C APTULO
4
Ferramentas e Ambiente de Desenvolvimento Distribudo
Uma das grandes vantagens de se trabalhar em grupo a paralelizao das tarefas de um determinado projeto, pois teoricamente quanto mais mo de obra mais rpido o projeto concludo. No entanto, no mbito de desenvolvimento de software existem algumas variveis que no tornam essa armao to simples. So necessrias ferramentas para alinhar conhecimento, documentar os cdigos fontes gerados, um repositrio online que todos tenham acesso, IDE de desenvolvimento, controle de verso, entre outras ferramentas. As sees a seguir descrevem as ferramentas utilizadas neste trabalho.
4.1
Eclipse
Eclipse uma IDE (Integrated Development Environment) de cdigo aberto e robusta para a plataforma Java, porm possui diversos plugins que adicionam funcionalidades para a codicao em outras linguagens. No caso de desenvolvimento para Android, a linguagem de programao padro possui sintaxe similar a da linguagem Java, mas so necessrias outras ferramentas e bibliotecas da API para que seja possvel utilizar toda a capacidade do aparelho celular (Eclipse Foundation, 2012).
15
Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo
16
4.2
JUnit
JUnit uma biblioteca de cdigo aberto criada por Kent Beck e Erich Gamma que visa facilitar o processo de teste de cdigo. O processo de teste de software parte indispensvel no desenvolvimento de qualquer aplicao porque ele que indica possveis falhas ou erros presentes no cdigo 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 escritos pelo desenvolvedor e gerando, ao nal, um relatrio intuitivo indicando quais testes passaram e quais no passaram.
4.3
Android SDK
O Android SDK (Software Development Kit) prov as ferramentas e bibliotecas necessrias para desenvolver, testar e depurar novas aplicaes (Google Inc., 2012b).
4.3.1
Plugin ADT
O plugin ADT (Android Development Tools) disponvel para o Eclipse, juntamente com o Android SDK d acesso ao usurio as bibliotecas de qualquer verso do Android liberada, facilitando o desenvolvimento de uma aplicao para uma verso especca. Inclui tambm um emulador do prprio sistema, assim possvel o desenvolvedor depurar suas aplicaes que esto em fase de desenvolvimento, outra opo export-las para um arquivo .apk e instal-las em um smartphone Android (Google Inc., 2012a).
4.4
Git
O Git sistema de controle de verso, ou VCS (Version Control System), utilizado neste trabalho e tambm amplamente utilizado pelo mercado. Os VCSs funcionam armazenando um histrico das modicaes que foram feitas em um conjunto de arquivos sendo possvel voltar da sua verso atual para qualquer outra verso especca nesse histrico. Alm do Git, existem outros VCSs ainda muito utilizados atualmente como o CVS (Concurrent Version System) e o SVN (Subversion). Entre as principais funcionalidades do Git esto retomar arquivos para um estado especco, recuperar projetos inteiros para um estado especco, comparar mudanas ao longo do tempo,
17
vericar e registrar as alteraes e quem foi o autor dessas mudanas, entre outras funcionalidades. Por ter toda essa exibilidade, o Git muito popular desde os desenvolvedores de softwares que trabalham sozinhos at as grandes corporaes (Chacon e Aljord, 2009). O Git se enquadra no conceito de DVCS (Distributed Version Control System), que um sistema de controle de verses distribudo. Cada desenvolvedor potencialmente tanto um hub como um node, ou seja, todo desenvolvedor pode contribuir com seu cdigo para outros repositrios e manter um repositrio pblico no qual outros desenvolvedores podem basear seu trabalho e comear a contribuir tambm. Essa exibilidade do Git permite que vrias conguraes de uxo de trabalho sejam usadas de acordo com a necessidade do projeto (Chacon e Aljord, 2009).
4.5
SourceForge
O SourceForge uma entidade que tem como seu principal objetivo o sucesso dos projetos de cdigo aberto. Prov ferramentas para a gerncia do cdigo fonte, documentao, frum de discusso e status do projeto. A pgina inicial do Maritaca no SourceForge mostrada na Figura 4.1. Atualmente, o projeto Maritaca est hospedado no SourceForge atravs do endereo https: //sourceforge.net/projects/maritaca/ e seu cdigo fonte est disponvel para download por meio de um repositrio Git. Ferramentas como o frum de discusso entre os desenvolvedores muito utilizado e facilita a comunicao quando os envolvidos no projeto no esto sicamente no mesmo lugar. Assim como o wiki que a documentao de conceitos j denidos, tutoriais, ambiente de desenvolvimento, entre outros.
18
Figura 4.1: Pgina inicial do Maritaca no SourceForge.
C APTULO
5
Arquitetura do Maritaca
O projeto Maritaca hospedado utilizando uma arquitetura de computao em nuvem, ou seja, todo seu cdigo executado e os dados so armazenados remotamente em servidores disponveis para acesso pela Internet. Dessa maneira, as informaes geradas pelos usurios nos dispositivos mveis esto disponveis em quaisquer computador com acesso a grande rede, atravs de um navegador (Armbrust et al., 2010). Esse tipo de soluo escalvel, ou seja, possvel contratar ou liberar rapidamente mais servidores equilibrando a demanda de requisies e os recursos disponveis do sistema, caso a quantidade de usurios do sistema aumente ou diminua consideravelmente. O Maritaca implementa um modelo de servio chamado de SaaS (Software as a Service), que um modelo associado a aplicaes baseadas na computao em nuvem que disponibilizam seus servios ao usurio via um navegador web. O conceito deste modelo se traduz na mudana de paradigma no mbito de comrcio e distribuio de software. No olhar de um cliente, ao invs de comprar a licena de um software e instal-lo em seus computadores, ele concorda em usar a aplicao que ser hospedada pela empresa que desenvolve e comercializa o software, dando ao comprador exibilidade para alternar fornecedores e evitar problemas com manuteno (Dubey e Wagle, 2007). A arquitetura do Maritaca composta por vrias componentes que possuem funes especcas e que interagem entre si. A Figura 5.1 mostra os principais elementos e suas interaes com os usurios do sistema no ciclo de coleta e persistncia de informaes. Basicamente o 19
Captulo 5. Arquitetura do Maritaca
20
usurio cria o aplicativo que corresponde a um formulrio digital no sistema web do Maritaca e o instala em um dispositivo mvel Android. O coletor usa a aplicao no seu dispositivo para adquirir e enviar s informaes coletadas ao servidor do Maritaca. Os dados so salvos nos repositrios de dados e esto disponveis para consulta ou download. No decorrer deste captulo, sero vistas informaes sobre a arquitetura, tecnologias e metodologias usadas em todos os componentes da soluo.
Figura 5.1: Componentes do Maritaca.
5.1
Viso Geral
A arquitetura do projeto possui trs grandes pilares: sistema mvel, servidor web e as bases de dados. A Figura 5.2 mostra de modo geral como essas componentes interagem. A componente mobile devices representa os dispositivos mveis Android e onde este trabalho est concentrado. Trata-se de uma aplicao Android que tem como principal funcionalidade a execuo dos formulrios, que so especicados atravs de arquivos XML, gerados no portal Maritaca. As requisies feitas da aplicao mvel para o servidor so encapsuladas pelo framework OAuth (OAuth Community, 2013), usado para aumentar a segurana do sistema no que diz respeito a autenticao dos usurios. A componente mvel e suas interaes sero descritas na Seo 5.2. O desenho modular do maritaca dene que as camadas de apresentao (Presentation Layer), a camada de negcios (Business Layer), a camada de Web Services e a camada de acesso as bases de dados (Data Acess) sejam independentes e separadas. A modularidade reduz a complexidade de sistemas, facilita futuras manutenes, mudanas no cdigo e agiliza a implementao
21
Figura 5.2: Componentes do Maritaca. do software pormitindo o desenvolvimento paralelo em diferentes partes do sistema (Pressman, 2006). Tanto o cdigo escrito para o servidor quanto o cdigo escrito para o dispositivo mvel so cdigos Java. Mas em uma situao hipottica, o cdigo usado no servidor poderia ser escrito em outra linguagem visto que a comunicao entre o dispositivo mvel e o servidor ocorre via web services, o que dispensa o uso da mesma linguagem de programao. Note que se outra linguagem de programao fosse usada, provavelmente algumas tecnologias empregadas no sistema atual teriam de ser trocadas por outras compatveis com a linguagem escolhida.
22
5.1.1
Servidor
Os servios e funcionalidades web do sistema esto incorporados no servidor de aplicaes web open source JBossAS (http://www.jboss.org/jbossas). Logo, o servidor agrupa as camadas de apresentao, negcio, acesso ao banco de dados e web services. Quando um usurio cria seu formulrio o sistema constri uma aplicao Android correspondente ao formulrio criado. O arquivo XML contendo as especicaes do formulrio embutido dentro da aplicao. Dessa forma, cada aplicao criada corresponde a apenas um formulrio. O usurio pode criar diversos formulrios e cada um ser uma aplicao diferente. Os web services foram implementados usando o modelo REST (Representional State Transfer) atravs do framework RESTEasy (JBoss Community, 2013). O REST um modelo idealizado de como a internet deveria funcionar. Este modelo de interaes de aplicaes web se tornou a base da arquitetura moderna da internet (Fielding e Taylor, 2002). Este estilo arquitetural uma abstrao do bsico do protocolo HTTP (Hypertext Transfer Protocol) e consiste em conceitos ao invs de sintaxes e detalhes tcnicos (Schreier, 2011). Todas as funcionalidades do sistema que envolvem envio e recebimento de mensagens de correio eletrnico so implementadas pelo no sistema com o framework de cdigo aberto RabbitMQ (VMware Inc., 2013). A camada de apresentao representa as telas que so apresentadas ao usurio. As pginas de gerenciamento de formulrios foram desenvolvidas com tecnologias altamente utilizadas e 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
Repositrios de Dados
So usados duas bases de dados com propsitos diferentes: o Cassandra (The Apache Software Foundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b). O Cassandra um sistema de banco de dados distribudo open source criado pela Apache Software Foundation. Ele dito No-SQL, ou seja, no utiliza a predominante arquitetura relacional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciar grandes quantidades de dados, provendo um servio com alta disponibilidade e sem pontos de falha (Lakshman e Malik, 2010). utilizado por grandes empresas como Google, Facebook e Amazon. O Cassandra usado no Maritaca para armazenar os dados estruturados em XML das respostas dos formulrios. O acesso ao banco de dados Cassandra se d pela API Hector (Hector Community, 2013). Ela fornece bibliotecas de alto nvel para realizar diversos tipos de procedimentos na base de
23
dados que vo desde operaes bsicas de CRUD (Create, Read, Update, Delete) at controle do pool de conexes. O Hadoop tambm um projeto open source da Apache Software Foundation que inclui implementaes de um sistema de arquivos distribudo, 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 no estruturados, principalmente arquivos, como udio, vdeo, imagens e executveis Android (arquivos com extenso apk).
5.2
Sistema Mvel
Depois de criar ou editar um formulrio a partir de um navegador web, o formulrio pode ser preenchido no dispositivo mvel no qual os dados coletados sero armazenados temporariamente no banco de dados local. O mdulo mvel no Maritaca corresponde ao aplicativo para Android e responsvel por gerenciar e coletar as respostas dos questionrios.
5.2.1
MVC no Sistema Mvel
O Sistema Mvel do Maritaca segue o padro de projeto MVC (Model, View, Controller) que largamente utilizado na indstria de software. Trata-se da separao clara de cada um de seus componentes: O Model o mdulo no qual se encontram as regras de negcio da aplicao juntamente com suas entidades. A View a tela de interface com o usurio. nessa componente que os dados so visualizados pelo usurio e onde ele interage com o sistema. O Controller responsvel por intermediar os dois componentes anteriores. Ele basicamente pega os dados gerados da comunicao do usurio com a View e os entrega para o Model processar, o mesmo ocorre no sentido inverso. A grande vantagem desse padro de projeto tornar o sistema modular, sendo cada camada independente da outra. Isso nos leva a facilidade de manuteno, por exemplo, se for necessria uma mudana nos clculos de uma aplicao, o desenvolvedor precisa apenas alterar o Model. Analogamente, se for necessria uma mudana de design na tela de visualizao, apenas l que o desenvolvedor vai realizar a mudana (Eric Freeman, 2007).
24
No cenrio do sistema mvel, no Model que esto concentradas as regras de negcio, ou seja, as implementaes do funcionamento de cada questo, validaes e comparaes. A View composta pelas telas do sistema. No Android, as telas so denidas por arquivos XML nos quais esto estabelecidos o posicionamento das componentes como texto, boto, checkbox, entre outros. Quem implementa a ao desses componentes o Controller, que no contexto do Android so 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 comunicao entre dispositivo mvel e servidor ocorre via web services e, sendo mais especco, quando essa comunicao envolve questionrios ou respostas de questionrios ela transmite informaes que representam arquivos XML. Esses arquivos precisam ser lidos e transformados em objetos Java que representam uma pergunta no questionrio. Ocorre o mesmo no sentido inverso, um objeto Java que representa uma resposta transformado em um arquivo XML e enviado ao servidor. As manipulaes dos arquivos XML so realizadas pela Engine. Ou seja, a Engine responsvel por receber dados que descrevem um questionrio e retornar objetos Java que so efetivamente as questes implementadas. A Engine implementa o padro de projeto Interpreter. Este padro dene que dado uma linguagem, possvel determinar uma representao para ela por intermdio de um interpretador que usa essa representao para processar sentenas da linguagem (Gamma et al., 1994). O conceito fundamental do Interpreter na Engine apresentar um conjunto hierrquico de classes que representa a especicao de um formulrio, que por sua vez representa a linguagem a ser interpretada. O arquivo XML, ou a especicao de formulrios, a linguagem a ser interpretada e a Engine o interpretador.
25
Cada tipo de questo do formulrio digital representada por uma hierarquia de classes, cuja superclasse a classe Question. Essa superclasse possui atributos e mtodos que so comuns as subclasses. Essa estrutura de classes pode ser vista na Figura 5.4. O responsvel por processar o XML e gerar os objetos denidos pelas subclasses de Question o Parser.
Figura 5.4: Estrutura de Classes de Question.
Parser A leitura de formulrios feita baseada em um conjunto de classes que representam o arquivo XML. O formulrio em si representado pela classe Form, seus elementos so compostos pela classe Questions e os atributos dos elementos so representados pelas classes Comparison e Clause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework Simple (Simple Community, 2013), que facilita a implementao e melhora a legibilidade do cdigo. O Simple tambm auxilia na serializao dos arquivos XML de respostas dos formulrios. O trabalho de manusear as entidades citadas acima responsabilidade das classes utilitrias XMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes so referenciadas na camada de negcio do sistema mvel. As respostas dos formulrios so transmitidas da unidade mvel Android para o servidor atravs de grandes strings de caracteres, encapsuladas em requisies HTTP, que representam seus respectivos arquivos XML. Comparison Um formulrio com perguntas sequenciais nem sempre interessante para determinados conjuntos de perguntas. Essa funcionalidade passvel de ser implementada em um formulrio digital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma pergunta anterior. Por exemplo, a pergunta: Voc ingere bebidas alcolicas? s dever aparecer
26
se a pergunta anterior: Qual a sua idade?, obter uma resposta dizendo que o interrogado tem mais de 18 anos. Essa funcionalidade est representada por um atributo no XML do formulrio de perguntas e que pode ter as seguintes comparaes: igual, maior, maior ou igual, menor e menor ou igual. Cada comparao 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.
C APTULO
6
Funcionalidades do Sistema
O Maritaca oferece ao usurio uma interface simples e intuitiva para a criao de formulrios, gerao de aplicaes e coleta de dados. Basicamente, so necessrios trs passos para que um ciclo de coleta de dados se complete: 1. Pelo navegador de internet, o usurio cria o questionrio. O sistema construir a aplicao Android e o disponibilizar para download. 2. A aplicao instalada no dispositivo Android; 3. O usurio coleta as informaes e envia as respostas ao servidor. Esse captulo detalha as funcionalidades que o sistema oferece e ao mesmo tempo um guia para sua utilizao.
6.1
Utilizao
O endereo de acesso do Maritaca http://maritaca.unifesp.br. Para utilizar o sistema, necessrio efetuar um cadastro simples e depois se logar, como mostra a Figura 6.1. Caso o usurio j tenha uma conta de usurio da Google, Yahoo ou do Facebook possvel utiliz-la atravs da tecnologia OpenID (OpenID Foundation, 2012). 27
Captulo 6. Funcionalidades do Sistema
28
Figura 6.1: Tela de login. Aps a autenticao, o usurio levado para a pgina principal do sistema, onde so listados todos os formulrios criados por ele e os compartilhados, conforme mostra a Figura 6.2. H um menu com aba Groups na parte superior, o qual permite o gerenciamento de grupos de usurios.
Figura 6.2: Tela principal.
29
Ao clicar no boto New Form o usurio levado para a tela de criao de formulrios. O painel da esquerda contm os tipos de pergunta que o usurio pode adicionar ao seu formulrio, como uma pergunta em forma de texto, uma foto, um vdeo, uma data, localizao por GPS, entre outras. As perguntas so componentes HTML 5 arrastveis (drag and drop), dessa forma o usurio pode adicionar um desses itens simplesmente arrastando-o para o centro da tela. No exemplo da Figura 6.3 o formulrio possui quatro perguntas.
Figura 6.3: Criao de formulrios. Aps salvar o formulrio, a criao do aplicativo para Android comea automaticamente de forma assncrona. Depois de criado, o usurio pode fazer o download do aplicativo e instal-lo no seu dispositivo Android. Aps a instalao, o aplicativo exige uma autenticao do usurio, da mesma forma que quando acessado atravs do navegador. A interface principal mostrada na Figura 6.4 composta por um menu que corresponde ao formulrio criado anteriormente. Para coletar informaes deste formulrio basta selecionar a opo Collect. As prximas sequncias de telas correspondem s perguntas criadas previamente na interface web do Maritaca. A Figura 6.5 ilustra as questes do formulrio criado anteriormente. As telas de questionrio so divididas de forma que na regio superior quem localizados o ttulo do formulrio, uma barra de progresso, um boto de ajuda e um boto de cancelar. O restante da tela ocupado pela questo e sua resposta. O usurio pode realizar quantas coletas forem necessrias para um mesmo formulrio. Depois dos dados serem coletados, o usurio pode enviar essas informaes para os servidores do Maritaca e acess-las na sua conta via interface web.
30
Figura 6.4: Autenticao e tela principal do aplicativo mvel.
Figura 6.5: Exemplos de questes no aplicativo mvel.
6.2
Recursos do Formulrio Digital
Os questionrios podem ser criados utilizando vrios tipos de recursos. A interface web do Maritaca disponibiliza perguntas dos seguintes tipos: texto, seleo mltipla (checkbox), numeral, data, mltipla escolha (combobox e radiobox), foto, udio, vdeo, GPS, cdigo de barras, controle deslizante (slider) e desenho. O Maritaca est em constante desenvolvimento e existem planos para adicionar mais tipos de perguntas. Uma grande vantagem do sistema sua arquitetura modular que facilita a adio de novas componentes. Por exemplo, todos os tipos de questes esto agrupados em um pacote de classes independente, dessa forma, para criar um novo tipo de questo, basta criar novas classes que representam o tipo de questo desejado. importante salientar que necessrio estender a classe abstrata Question que dene como os mtodos devem ser implementados. Cada questo do formulrio digital do Maritaca possui propriedades importantes que deixam o sistema mais robusto para o uso na CMD. Cada questo pode ter seu valor padro inicial, um
31
valor mnimo e um valor mximo denidos na etapa da criao do formulrio. Tambm h a possibilidade de tornar uma pergunta obrigatria ou mant-la opcional. Outra funcionalidade que merece destaque a capacidade do desvio do uxo normal da sequncia das perguntas atravs de algumas condicionais, tais como: igual, menor, maior, menor ou igual e maior ou igual. Ou seja, possvel ir pra alguma questo especca do questionrio a partir da questo atual, obviamente que a mudana da sequncia depende da resposta. Uma propriedade til das questes o campo ajuda. Trata-se de um campo texto que complementa a descrio da questo e pode ser acessado a partir de um boto na regio superior do aplicativo mvel.
6.3
Compartilhamento de Informaes
O nvel de compartilhamento dos formulrios e suas respostas podem ocorrer em trs graus: privado, pblico e compartilhado. No compartilhamento privado, o formulrio s est acessvel ao seu criador (owner). No pblico, o formulrio acessvel para todos. O nvel compartilhado de um formulrio ocorre quando o seu criador convida outros usurios para acess-lo. Esse nvel possui duas ramicaes: Hierrquico: Os usurios convidados no podem acessar as respostas coletadas de outros convidados. Apenas o criador do formulrio consegue ver todas as respostas; Social: Ao contrrio do item anterior, tanto os usurios convidados quanto o criador conseguem acessar todas as respostas coletadas. A Tabela 6.1 sintetizou os tipos de permisses de acesso (leitura e escrita dos dados coletados) para o criador do formulrio e seus convidados, de acordo com o grau de compartilhamento. Tabela 6.1: Polticas de compartilhamento de dados no Maritaca. Privado Criador Criador Criador Criador Comp. Hierrquico Criador e Convidados Criador Criador Criador e Convidados Comp. Social Criador e Convidados Criador Criador e Convidados Criador e Convidados Pblico Todos Criador Todos Criador
Formulrio Resposta
Leitura Escrita Leitura Escrita
32
6.4
Relatrios
A gerao automtica de relatrios uma funcionalidade que est em desenvolvimento, porm no pode deixar de ser mencionada. Ela permite que a partir das informaes coletadas e das perguntas selecionadas pelo usurio seja gerado um relatrio contendo grcos de pizza ou barras e organizar os dados em forma de tabelas. Por enquanto os relatrios so gerados apenas com questes de seleo mltipla como checkbox e radiobox. A Figura 6.6 exibe a tela de criao de relatrios em que o relatrio (coluna central) contm duas questes do formulrio (coluna da esquerda). possvel criar e editar vrios relatrios para um mesmo formulrio. Para acess-los, basta abrir o menu de opes do formulrio desejado, exibido na Figura 6.7, e clicar na opo Edit Report ou View Report, na pgina principal do Maritaca.
Figura 6.6: Interface para elaborao de relatrios.
Figura 6.7: Menu de acesso aos relatrios.
C APTULO
7
Implantao do Maritaca
Este captulo destaca os passos para a implantao do sistema e congurao do ambiente de desenvolvimento.
7.1
Ambiente de Desenvolvimento
A preparao do ambiente de desenvolvimento consiste na instalao e congurao das ferramentas e bibliotecas utilizadas no desenvolvimento de um sistema. O sistema operacional recomendado para o desenvolvimento do Maritaca o Ubuntu verso 11.10. As ferramentas usadas no desenvolvimento juntamente com suas pginas ociais so listadas abaixo: JDK (Java Development Kit) verso 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
Captulo 7. Implantao do Maritaca 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.
34
7.2
Implantao no Servidor
Aps todos os itens da seo anterior serem instalados e devidamente congurados, necessrio fazer o download do cdigo fonte do Maritaca que est disponvel na pgina do Maritaca no SourceForge. O seguinte comando deve ser executado no terminal do Linux: $ git clone git://git.code.sf.net/p/maritaca/code maritaca-code Aps a execuo do comando, a pasta contendo o cdigo fonte estar no diretrio corrente. O mdulo servidor divido em quatro projetos: business, persistence, web e webservices. O mdulo mvel possui um nico projeto: o maritaca-mobile. O arquivo de congurao conguration.properties essencial para a implantao do projeto. Ele pode ser criado em qualquer diretrio contanto que sua localizao seja xada por meio da varivel de ambiente MARITACA_CONFIG_PATH. Esse arquivo exibido na Tabela 7.1. Antes de iniciar o servidor necessrio congurar o Cassandra. Primeiro deve-se subir o servio no terminal executando o seguinte arquivo, localizado na pasta de instalao do Cassandra: $ sudo ./bin/cassandra Usando outro terminal preciso criar o keyspace do Maritaca, executando os seguintes comandos:
Captulo 7. Implantao do Maritaca Tabela 7.1: Arquivo de congurao conguration.properties. Propriedade maritaca_mobile_path android_sdk_path maritaca_uri_server lesystem_path http_uri_server ffmpeg_path tmp_directory cluster_addr Exemplo /home/user/workspace/maritaca/client/ /opt/android/android-sdk-linux http://192.168.1.105:8080/maritaca /var/www/hadoop_mounted/user/seu-usuario http://localhost/hadoop_mounted/user/seu-usuario/ /usr/local/bin/ffmpeg /tmp/ localhost:9160
35
$ ./bin/cassandra-cli -h localhost create keyspace Maritaca; exit; Para congurar 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 compilado com o maven atravs do comando: $ mvn clean package Um arquivo JAR referente ao projeto ser gerado. Deve-se execut-lo atravs do comando: $ java -jar rabbit-consumer-1.0.jar O servidor de aplicaes Tomcat pode ser iniciado atravs de um script localizado na pasta bin que ca no diretrio onde foi instalado o Tomcat. Dentro desta pasta, basta executar o comando: $ ./catalina.sh run
Captulo 7. Implantao do Maritaca
36
Aps o servidor ser inicializado a interface web do Tomcat pode ser acessada por meio do endereo http://localhost:8080. O prximo passo compilar o projeto servidor e gerar um arquivo WAR (Web application ARchive) que representa a aplicao web do Maritaca a ser implantada no servidor. O projeto compilado com a ferramenta maven, executado no terminal e na pasta server do projeto, por meio do comando abaixo: $ mvn clean install -Dmaven.test.skip=true O arquivo WAR pode ser encontrado dentro da pasta target do projeto web no mdulo servidor. esse arquivo que deve ser implantado no servidor. O maven possui plugins extras que se instalados permitem que logo aps o projeto ser compilado, o arquivo WAR construdo automaticamente implantado no servidor. Existem outras maneiras como utilizar a interface web do servidor e fazer o upload do prprio arquivo WAR. Aps a implantao o mdulo servidor do Maritaca pode ser acessado atravs do endereo http://localhost:8080/maritaca.
7.3
Aplicao Android
Se o plugin ADT e o Android SDK foram instalados corretamente, dois cones devem aparecer no Eclipse: o Android SDK Manager e o Android Virtual Device Manager. O primeiro se trata de um gerenciador das APIs do Android assim como algumas ferramentas. O projeto Maritaca pode ser compilado a partir da API 7, portanto se faz necessria a instalao de uma API igual ou superior. O Android Virtual Device Manager um gerenciador de dispositivos virtuais que emulam um smartphone Android. Pode-se criar vrios dispositivos virtuais, cada um com sua respectiva verso do Android e atributos como memria principal e resoluo de tela. Se a verso do Ubuntu instalada 64 bits, ento a instalao da biblioteca ia32-libs se faz necessria para trabalhar com o Android SDK. O mdulo mvel do Maritaca depende de outro projeto: o ActionBarSherlock (http: //actionbarsherlock.com/). No projeto ele est nomeado como library e est no mesmo diretrio do maritaca-mobile. O cdigo fonte do mdulo mvel Android est dentro da pasta maritaca-mobile. Para adicionar o projeto ao Eclipse necessrio importa-lo pelo menu File -> Import ou clicando com o boto direito no Package Explorer -> Import conforme mostra a Figura 7.1. Aps esse passo, surge um menu com vrios tipos de projetos. Deve-se escolher um projeto do tipo Android como fonte. Lembre-se de importar tanto o library quanto o maritaca-mobile.
Captulo 7. Implantao do Maritaca
37
Figura 7.1: Modos de importar projetos no Eclipse. Aps importado, o projeto pode ser visualizado no Package Explorer. Todas as classes, arquivos de layout, bibliotecas adicionais e arquivos de congurao podem ser acessados. Para executar o projeto basta clicar com o boto direito no projeto e selecionar Run As -> Android Application. O dispositivo virtual criado anteriormente ser iniciado e a aplicao instalada e executada.
C APTULO
8
Contribuies no Cdigo
Este captulo apresenta as principais contribuies, por mim realizadas, no cdigo fonte do sistema mvel do projeto Maritaca. Foram desenvolvidas trs funcionalidades principais: a implementao do tipo de questo slider, um servio de noticao de novos dados enviados e a tela de congurao ou settings. Esses trs itens cobrem campos diferentes tanto da arquitetura do Maritaca quanto da API do Android, abrangendo tpicos como a criao de telas por arquivos XML, consultas e inseres de dados atravs do SQLite, uso do sistema de noticao e de alarme do Android, implementao da classe Question, entre outros.
8.1
Question Slider
O Slider no Maritaca a implementao da Seek Bar presente na API do Android. Com essa componente possvel selecionar um valor em um intervalo (geralmente de zero a cem) movendo horizontalmente o indicador da barra. O menor valor est no limite da esquerda assim como o maior est no limite da direta. A Figura 8.1(b) mostra a Seek Bar da API do Android e a Figura 8.1(a) mostra o Slider do Maritaca.
38
Captulo 8. Contribuies no Cdigo
39
(a) Slider Maritaca.
(b) Seek Bar Android.
Figura 8.1: Customizao da componente Seek Bar
8.1.1
Passos da Implementao
A classe abstrata Question, mostrada no Apndice B, dene quais mtodos os tipos de questes devem implementar. Essa classe fundamental no contexto do sistema, pois todas as manipulaes que a Engine faz para criar os objetos, que correspondem as questes no formulrio, so feitas com base nos seus mtodos. Para desenvolver o Slider foi necessrio implementar os seguintes mtodos abstratos: public abstract ComponentType getComponentType(); Este mtodo retorna o tipo do componente ou questo a ser implementada. ComponentType um Enum, ou seja, uma classe estruturada de tal forma que seus dados sejam imutveis (Sierra e Bates, 2005). nessa classe que esto denidos todos os tipos de questes com um respectivo identicador, inclusive o slider. public abstract Object getValue(); Retorna o valor adquirido pela questo. No caso do slider retornado um valor numrico, mas caso fosse um questo do tipo texto, este mtodo retornaria uma string de caracteres. public abstract View getLayout(ControllerActivity activity); Este mtodo retorna o Slider customizado. O slider montado a partir da seek bar juntamente com seu esquema de posicionamento da componente na tela. Com o slider foi criada uma componente de texto que mostra o valor atual do slider e o atualiza caso o usurio mude. public abstract boolean validate(); A validao da questo feita quando o usurio avana ou retrocede no formulrio no menu de coleta. Um tipo de validao a vericao da obrigatoriedade da resposta, ou seja, a resposta da questo no pode ser vazia. O slider implementa este tipo de validao. public abstract void save(View answer); A implementao deste mtodo ocorre da mesma forma que o item anterior, porm o mtodo salvar executado antes, pois no contexto do sistema necessrio salvar o valor selecionado pelo usurio para poder executar a validao.
40
8.2
Servio de Noticaes
Um servio no Android, representado pela classe Service, uma componente de aplicao que tem como funo realizar operaes prolongadas que no interferem com o usurio ou prover funcionalidades para outras aplicaes. Os servios no so processos ou threads adicionais, ou seja, so executados no mesmo processo da aplicao a qual pertencem. A classe IntentService estende Service e usada para lidar com tarefas assncronas, ou seja, ela cria threads para processar o que foi requisitado e depois elimina a thread (Google Inc., 2012b). O servio de noticaes composto por uma IntentService que faz uma requisio HTTP para o servidor acessando um web service que retorna uma resposta que contm a quantidade de novas coletas enviadas ao servidor, a partir de uma data, por outros coletores para o formulrio em questo. Se houverem novas coletas a prpria IntentService lana uma noticao, como a ilustrada na Figura 8.2. Essa funcionalidade til quando existem vrios coletores para um mesmo formulrio.
Figura 8.2: Noticao de novos dados coletados.
8.2.1
Criao do Servio O servio representado pela classe NoticationService que estende IntentService. Essa classe responsvel por criar a noticao e gerenciar a requisio e sua resposta HTTP. Caso a resposta do web service retorne um inteiro maior que zero, uma noticao gerada indicando o nmero de novas coletas, caso contrrio, uma noticao gerada indicando que nenhuma coleta foi enviada ao servidor. O NoticationService chamado assim que a tela de menu construda. Quem faz a chamada a classe AlarmManager que prov acesso a sistema de alarmes do Android e permite agendar a execuo do servio, que feita repetidamente e em intervalos de tempo denidos
41
pelo usurio. A tela de congurao, melhor detalhado na Seo 8.3, inclui opes para ligar ou desligar o servio de noticao e determinar o intervalo de tempo que a sincronizao com o servido realizada. Tratamento da Requisio e Resposta A requisio feita criando um objeto que representa uma requisio HTTP e o enviando. A criao da requisio envolve a passagem de parmetros de dois parmetros a partir da URL: a identicao do formulrio e a data da ltima sincronizao. Depois que a requisio foi enviada cabe ao servidor receb-la e trat-la. O servidor usa o RESTEasy (JBoss Community, 2013) que implementa a especicao JAX-RS (Oracle Corp., 2013a) e prov uma biblioteca para web services RESTful, facilitando seu uso. O servidor est congurado para ltrar as requisies feitas aos web services e encaminh-las para seu respectivo mtodo de implementao. Este mtodo faz uma busca no banco de dados que retorna uma lista de formulrios enviados ao servidor, por outros usurios, a partir da data recebida como parmetro. Com essa lista em mos, basta retornar seu tamanho. O resultado encapsulado em um objeto que corresponde ao uma resposta HTTP e enviada de volta ao NoticationService. A Figura 8.3 representa a sequncia dos eventos e chamadas do sistema de noticaes.
Figura 8.3: Fluxograma do sistema de noticaes.
42
8.3
Menu Settings
A partir do menu principal h um boto com opo de ir para tela de conguraes ou Settings. As opes de congurao nessa tela fazem referncia a seo anterior, logo, ela contm um boto no qual possvel ativar ou desativar a sincronizao com o servidor do sistema de noticaes. Caso esse boto for habilitado, a escolha do intervalo de tempo de sincronizao tambm ser. A Figura 8.4 apresenta a tela com suas respectivas componentes.
Figura 8.4: Tela Settings.
8.3.1
A criao de telas, ou interfaces de usurio, no Android ocorre pela representao de seus componentes com seus respectivos atributos por um arquivo XML. No arquivo que representa a interface da Figura 8.4 existem alguns componentes a serem destacados: O Toggle Button, que alterna entre ativada e desativada a sincronizao do sistema de noticaes; A Seek Bar, responsvel por determinar o intervalo de sincronizao em minutos. Note que esta componente s estar habilitada de o boto do item anterior tambm estiver; O boto Save Settings que persiste as conguraes no banco de dados local do dispositivo mvel.
43
Para armazenar as preferncias do usurio, foi necessrio criar uma tabela no banco de dados local. Cada linha desta tabela armazena se o Toggle Button est ativado ou no, o intervalo de sincronizao e o usurio a quem pertence essas opes. A API do Android fornece algumas classes que facilitam a manipulao de tabelas no banco de dados local SQLite. Para manipular os dados dessa tabela foram implementados mtodos para insero, atualizao e consulta desses dados. A insero ocorre quando no existem dados na tabela e o usurio pressiona o boto Save Settings. A atualizao ocorre da mesma forma, porm somente quando existem dados na tabela. As consultas so feitas na prpria tela Settings, no momento de sua criao, para carregar as componentes com os valores salvos anteriormente, e tambm no AlarmManager para pegar o valor do intervalo de sincronizao.
8.4
Problemas Reportados
Os problemas encontrados no sistema podem ser adicionados na pgina de noticao de bugs no SourceForge do Maritaca (https://sourceforge.net/p/maritaca/bug/). Os problemas encontrados e submetidos so listados a seguir: O aplicativo mvel no abre em verses do Android 4.0 ou superior. Esse problema ocorre quando requisies HTTP so executadas na thread principal da aplicao, o que pode acarretar em ANR (Application Not Responding) (Google Inc., 2012b). A pgina referente ao bug https://sourceforge.net/p/maritaca/tickets/463/; Caso o coletor no tiver acesso internet ele no consegue coletar dados. A Seo 9.3 descreve como este problema foi encontrado. A pgina referente ao bug https:// sourceforge.net/p/maritaca/bug/53/; Quando uma questo do tipo Picture enviada ao servidor com uma foto grande (2 MBytes) o a aplicao para de responder, gerando um aviso de ANR.
C APTULO
9
Estudo de Caso
A m de avaliar o funcionamento do sistema em modo de produo, este captulo apresenta os resultados da CMD usando o Maritaca em um cenrio real.
9.1
Cenrio
A Universidade Federal de So Paulo campus So Jos do Campos iniciou suas atividades em 2007 com apenas um curso, cinquenta alunos e dez docentes. Com um evoluo rpida, no ano de 2012 possua cerca de mil alunos e oitenta docentes distribudos entre trs cursos e trs turnos diferentes. Para atender esse pblico, o campus possui uma cantina e um restaurante universitrio (criado em 2011), sendo que o ltimo possui parte do valor da refeio subsidiado pela universidade. As refeies so oferecidas em dois horrios, no almoo a partir das doze horas at s catorze horas e no jantar a partir das dezoito horas at s vinte horas. O Maritaca foi usado nesse cenrio para coletar informaes sobre a satisfao dos usurios do restaurante universitrio durante 15 dias.
44
Captulo 9. Estudo de Caso
45
9.2
Formulrio
As imagens da Seo 6.1 demonstram a construo da aplicao Bandejo, a mesma utilizada nessa demonstrao. O formulrio 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 refeio? Figura 9.1(c); Qual sua satisfao? Figura 9.1(d); Foto da refeio. Figura 9.1(e).
(a) Pergunta no obrigatria do tipo (b) Pergunta obrigatria do tipo (c) Pergunta obrigatria do tipo texto. RadioButton com as opes BCC, data. BCT ou BMC.
(d) Pergunta obrigatria do tipo Ra- (e) Questo no obrigatria do tipo dioButton com as opes timo, Picture. bom, regular, ruim.
Figura 9.1: Questes do formulrio Bandejo.
46
A representao desse formulrio pelo sistema feita por arquivos XML. O formulrio Bandejo est especicado em um arquivo XML mostrado no Apndice A. O formulrio foi criado com a poltica de compartilhamento hierrquico, ou seja, o criador tem acesso total para leitura e escrita tanto das respostas como do formulrio e os convidados tem acesso apenas a leitura do formulrio e escrita das respostas. Neste cenrio, trs coletores diferentes participaram da aquisio dos dados e cada um possua seu respectivo dispositivo Android. Os dispositivos, assim como suas verses do Android so listados abaixo. Samsung Galaxy SIII, Android verso 4.1.2 Jelly Bean; Samgung Galaxy Nexus, Android verso 4.2.2 Jelly Bean; Samsung Galaxy 5, Android verso 2.3.3 Gingerbread;
9.3
Resultados
Na aplicao Android e no gerenciador web de formulrios possvel ver as respostas coletadas para cada questionrio na forma de tabelas, como mostra a Figura 9.3. Atente ao fato que no escopo deste trabalho dissertar sobre a qualidade ou opinio dos alunos e docentes em relao ao restaurante universitrio. O sistema Maritaca de um modo geral respondeu bem aos comandos, sua interface intuitiva e os coletores no tiveram problemas em us-la. Um ponto controverso percebido pelos coletores que as componentes mvel e web impe ao usurio sua autenticao de hora em hora, ou seja, depois de sessenta minutos contados a partir da autenticao, o usurio automaticamente desconectado do sistema. Esse mtodo contribui para elevar a segurana porque diculta que um usurio no autorizado colete informaes, porm em algumas situaes como o dispositivo no conseguir acessar a internet por estar em uma rea sem cobertura pode obstruir o coletor de usar o sistema. O resultado da coleta de dados do formulrio Bandejo pode ser visualizada na Figura 9.2, que contm um grco gerado pelos dados da satisfao dos usurios do restaurante universitrio da Unifesp. Este grco foi criado atravs da funcionalidade de gerao automatizada de relatrios do sistema web. Foram realizadas no total trinta e seis coletas, sendo que dez delas possuem contedo multimdia. A Figura 9.3 mostra algumas das respostas do formulrio Bandejo retiradas da interface web do Maritaca. O sistema mostra os dados coletados em formato tabular e ao clicar nas imagens na coluna mais direita, outra janela surge mostrando a imagem na sua resoluo original.
47
Figura 9.2: Relatrio gerado a partir dos dados coletados no formulrio Bandejo.
Figura 9.3: Respostas do formulrio Bandejo incluindo arquivos de imagens.
C APTULO
10
Concluses
Este captulo apresenta as consideraes nais deste Trabalho de Concluso de Curso, as principais contribuies e os trabalhos futuros que podero complementar o que foi realizado.
10.1
Consideraes Finais
A automatizao da Coleta Mvel de Dados um processo positivo e a tendncia de aumentar sua adoo alta por incorporar vantagens ambientais e econmicas. O Maritaca um dos projetos que implementam este procedimento e foi o objeto de estudo deste trabalho. Os objetivos principais foram estudar sua arquitetura e colaborar com o desenvolvimento em um dos braos do projeto: o mdulo Android. A desenho modular do Maritaca um conceito bem estabelecido e muito usado pelo mercado de desenvolvimento de software. Traz vantagens claras de reusabilidade e manuteno de cdigo. Sua arquitetura baseada na nuvem traz benefcios importantes como a alta escalabilidade e permite que o usurio acesse os servios do sistema em qualquer lugar do mundo, independente da plataforma usada, desde que tenha acesso internet. As funcionalidades desenvolvidas abordaram diferentes tpicos da arquitetura do Maritaca assim como das bibliotecas do Android, fornecendo uma viso mais ampla e concreta de ambos. As principais implementaes foram o slider, o sistema de noticaes e a interface de congurao, detalhadas no Captulo 8. 48
Captulo 10. Concluses
49
10.2
Contribuies
Este Trabalho de Concluso de Curso deixa como contribuio as experincias e lies aprendidas na participao no projeto open source Maritaca em um ambiente de desenvolvimento distribudo. Alm de colaboraes no cdigo fonte da componente mvel Android. Este trabalho tambm pode ser til como manual e avaliao do sistema.
10.3
Trabalhos Futuros
O projeto Maritaca est numa verso estvel, mas h muitos recursos e funcionalidades existentes que podem ser melhoradas e novas que podem ser criadas, j que o campo da Coleta Mvel de Dados bastante abrangente. Abaixo esto descritos dos objetivos futuros mais signicativos: Colaborar no desenvolvimento de outras componentes do sistema, como o servidor e bases de dados; Aumentar a abrangncia do sistema tornando-o multiplataforma, criando aplicaes para Web, iOS e BlackBerryOS; Analisar a capacidade do sistema, semelhante ao que foi feito no Captulo 9, porm inserindo quantidades maiores de informaes usando todos os tipos de perguntas do formulrio digital;
Referncias Bibliogrcas
A NATEL Brasil ultrapassa um celular por habitante, disponvel em: http://goo.gl/ BRnJh (acessado em 28/03/2013), 2010. A NATEL Telefonia mvel fecha 2012 com 261,78 milhes de linhas, disponvel em: http: //goo.gl/Xam8j (acessado em 29/01/2013), 2013. A RMBRUST, M.; F OX , A.; G RIFFITH , R.; J OSEPH , A.; K ATZ , R.; KONWINSKI , A.; L EE , G.; PATTERSON , D.; R ABKIN , A.; S TOICA , I.; et al. A view of cloud computing. Communications of the ACM, v. 53, n. 4, p. 5058, 2010. B ORNSTEIN , D. Dalvik vm internals. In: Google I/O Developer Conference, 2008, p. 1730. B ORTHAKUR , D.; G RAY, J.; S ARMA , J. S.; M UTHUKKARUPPAN , K.; S PIEGELBERG , N.; K UANG , H.; R ANGANATHAN , K.; M OLKOV, D.; M ENON , A.; R ASH , S.; S CHMIDT, R.; A IYER , A. Apache hadoop goes realtime at facebook. In: Proceedings of the 2011 ACM SIGMOD International Conference on Management of data, SIGMOD 11, New York, NY, USA: ACM, 2011, p. 10711080 (SIGMOD 11, ). Disponvel em http://doi.acm.org/10.1145/1989323.1989438 B RAHLER , S. Analysis of the android architecture. Karlsruhe institute for technology, 2010. C HACON , S.; A LJORD , P. Pro git. Springer-verlag New York Inc, 2009. C ONDER , S.; DARCEY, L. Android wireless application development: Android essentials, v. 1. Addison-Wesley Professional, 2012.
DO F ORMS I NC .
Ofcial doforms website, disponvel em: http://www.doforms.com/ (acessado em 28/03/2013), 2013.
D UBEY, A.; WAGLE , D. Delivering software as a service. The McKinsey Quarterly, v. 6, p. 112, 2007. E CLIPSE F OUNDATION Eclipse, disponvel em: http://www.eclipse.org (acessado em 14/04/2012), 2012. 50
51
E HRINGER , D. The dalvik virtual machine architecture. Techn. report (March 2010), 2010. Disponvel em http://goo.gl/v2eIy E RIC F REEMAN , E LISABETH F REEMAN , K. S. B. B. Head rst design patterns. OReilly Media, 2007. F IELDING , R. T.; TAYLOR , R. N. Principled design of the modern web architecture. ACM Trans. Internet Technol., v. 2, n. 2, p. 115150, 2002. Disponvel em http://doi.acm.org/10.1145/514183.514185 G AMMA , E.; H ELM , R.; J OHNSON , R.; V LISSIDES , J. Design patterns: Elements of reusable object-oriented software. Pearson Education, 1994. Disponvel em http://books.google.com.br/books?id=6oHuKQe3TjQC G ARTNER I NC . Gartner says worldwide mobile phone sales declined 1.7 percent in 2012. http://goo.gl/Nxi8K (acessado em 28/03/2013), 2013. G OOGLE ; M EDIACT, I. Nosso planeta mobile: Brasil, disponvel em: http://goo.gl/ 1yfr6 (acessado em 29/01/2013), 2012. G OOGLE I NC . Adt plugin for eclipse, disponvel em: http://developer.android. com/sdk/eclipse-adt.html (acessado em 03/06/2012), 2012a. G OOGLE I NC . Android developers, disponvel em: http://developer.android. com/index.html (acessado em 06/02/2013), 2012b. G OOGLE I NC . Ofcial android website, disponvel em: http://www.android.com/ (acessado em 28/03/2013), 2013. H ASHIMI , S. Y.; KOMATINENI , S.; G OYAL , V. Pro android. Apress New York, 2009. H ECTOR C OMMUNITY Ofcial hector website, disponvel hector-client.org (acessado em 29/03/2013), 2013. em: http://
JADKOWSKI , M. Best practices in mobile data collection, disponvel em: www.doforms. com/support/best-practices.pdf (acessado em 04/06/2012), 2012. JB OSS C OMMUNITY Ofcial resteasy website, disponvel em: http://www.jboss. org/resteasy/ (acessado em 04/04/2013), 2013. L AKSHMAN , A.; M ALIK , P. Cassandra: a decentralized structured storage system. SIGOPS Oper. Syst. Rev., v. 44, n. 2, p. 3540, 2010. M AKER , F. Android dalvik virtual machine, disponvel em: http://goo.gl/7DvOD (acessado em 20/02/2013), 2011. MIT Ofcial mit app inventor website, disponvel em: http://appinventor.mit. edu/ (acessado em 28/03/2013), 2013.
52
N ETO , A RISTIDES V. P. Criando testes com junit, disponvel em: http://goo.gl/jjDgR (acessado em 10/06/2012), 2009. N OKIA C ORP. Nokia data gathering in action, disponvel em: https://projects. developer.nokia.com/ndg/wiki/projects (acessado em 29/03/2013), 2013a. N OKIA C ORP. Ofcial nokia data gathering website, disponvel em: https://projects. developer.nokia.com/ndg/wiki (acessado em 28/03/2013), 2013b. OAUTH C OMMUNITY Ofcial oauth website, disponvel em: http://oauth.net/2/ (acessado em 04/04/2013), 2013. ODK C OMMUNITY Ofcial open data kit website, disponvel em: opendatakit.org/ (acessado em 28/03/2013), 2013. http://
O PEN H ANDSET A LLIANCE Open handset alliance ofcial website, disponvel em: http: //www.openhandsetalliance.com/ (acessado em 14/04/2012), 2012. O PEN ID F OUNDATION Ofcial openid website, disponvel em: http://openid.net/ developers/ (acessado em 25/06/2012), 2012. O RACLE C ORP. Ofcial jax-rs website, disponvel em: http://jax-rs-spec.java. net/ (acessado em 04/04/2013), 2013a. O RACLE C ORP. Ofcial jsf website, disponvel em: http://www.oracle.com/ technetwork/java/javaee/javaserverfaces-139869.html (acessado em 31/03/2013), 2013b. P RESSMAN , R. Engenharia de software. McGraw-Hill, 2006. S CHREIER , S. Modeling restful applications. In: Proceedings of the Second International Workshop on RESTful Design, WS-REST 11, New York, NY, USA: ACM, 2011, p. 1521 (WS-REST 11, ). Disponvel em http://doi.acm.org/10.1145/1967428.1967434 S IERRA , K.; BATES , B. Head rst java. OReilly Media, Incorporated, 2005. S IMPLE C OMMUNITY Ofcial simple website, disponvel em: sourceforge.net/ (acessado em 04/04/2013), 2013. http://simple.
SQL ITE C OMMUNITY Ofcial sqlite website, disponvel em: http://www.sqlite. org/ (acessado em 04/04/2013), 2013. S TRAUCH , C.; S ITES , U.-L. S.; K RIHA , W. Nosql databases. 2011. Disponvel em http://www.christof-strauch.de/nosqldbs.pdf T HE A PACHE S OFTWARE F OUNDATION Ofcial cassandra website, disponvel em: http: //cassandra.apache.org/ (acessado em 29/03/2013), 2013a.
53
T HE A PACHE S OFTWARE F OUNDATION Ofcial hadoop website, disponvel em: http: //hadoop.apache.org/ (acessado em 29/03/2013), 2013b. T HE J Q UERY F OUNDATION Ofcial jquery website, disponvel em: http://jquery. com/ (acessado em 29/03/2013), 2013. VM WARE I NC . Ofcial rabbitmq website, disponvel em: http://www.rabbitmq.com/ (acessado em 04/04/2013), 2013. W3C The syntax, vocabulary and apis of html5, disponvel em: http://dev.w3.org/ html5/html-author/ (acessado em 31/03/2013), 2010.
A PNDICE
A
Especicao de Formulrio no Arquivo XML
O arquivo XML abaixo descreve a especicao do formulrio digital Bandejo, que foi usado no captulo 9.
<?xml version="1.0" encoding="UTF-8"?> <form> <title>Bandejo</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 refeio.</label> <help></help> <default></default> <format>mm/dd/yy</format>
54
Captulo A. Especicao de Formulrio no Arquivo XML

</date> <radio id="3" next="4" required="true" > <label>Qual sua satisfao?</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 Refeio</label> <help></help> </picture> </questions> </form>
55
A PNDICE
B
Classe Question
O arquivo Java abaixo representa a classe abstrata Question, pea importante do sistema mvel do Maritaca. Note que algumas linhas de cdigo foram ocultadas (imports, package, getters e setters) porque no so necessrias para compreenso de sua implementao.
/* 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
Captulo B. Classe Question

@Element protected 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)*/ }
57

Marita CA Tutorial

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Marita CA Tutorial

Enviado por

Direitos autorais:

Formatos disponíveis

Coleta Mvel de Dados em dispositivos Android: um estudo sobre a arquitetura do projeto Maritaca

Leonardo Betto Sueoka

Leonardo Betto Sueoka

Orientador: Prof. Dr. Arlindo Flavio da Conceio

So Jos dos Campos SP Maro, 2013

Leonardo Betto Sueoka

Orientador: Prof. Dr. Arlindo Flavio da Conceio

Aos meus pais, pelo amor, dedicao e pelo eterno incentivo.

Keywords: TCC, Android, Mobile Data Collection, Distributed Systems.

Ferramentas e Ambiente de Desenvolvimento Distribudo 4.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

4.3 4.4 4.5 5

Android SDK . . . 4.3.1 Plugin ADT Git . . . . . . . . . SourceForge . . . .

Estudo de Caso 9.1 Cenrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2 Formulrio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 6.1 7.1

PNG REST SaaS SDK SMS SQL VCS XML WAR

Captulo 2. Android e a Mquina Virtual Dalvik

Histrico das Verses

Captulo 2. Android e a Mquina Virtual Dalvik

Captulo 2. Android e a Mquina Virtual Dalvik

Captulo 2. Android e a Mquina Virtual Dalvik

Captulo 2. Android e a Mquina Virtual Dalvik

A Mquina Virtual Dalvik

Captulo 2. Android e a Mquina Virtual Dalvik

Sem compresso Compresso Jar Arquivo Dex sem compresso

Captulo 2. Android e a Mquina Virtual Dalvik

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

MIT App Inventor

Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados

Nokia Data Gathering (NDG)

Open Data Kit (ODK)

Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

Figura 4.1: Pgina inicial do Maritaca no SourceForge.

Captulo 5. Arquitetura do Maritaca

Figura 5.1: Componentes do Maritaca.

Captulo 5. Arquitetura do Maritaca

Captulo 5. Arquitetura do Maritaca

Captulo 5. Arquitetura do Maritaca

MVC no Sistema Mvel

Captulo 5. Arquitetura do Maritaca

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

Captulo 5. Arquitetura do Maritaca

Figura 5.4: Estrutura de Classes de Question.

Captulo 5. Arquitetura do Maritaca

Figura 5.5: Estrutura de classes do Comparison.

Captulo 6. Funcionalidades do Sistema

Figura 6.2: Tela principal.

Captulo 6. Funcionalidades do Sistema

Captulo 6. Funcionalidades do Sistema

Figura 6.4: Autenticao e tela principal do aplicativo mvel.

Figura 6.5: Exemplos de questes no aplicativo mvel.

Recursos do Formulrio Digital

Captulo 6. Funcionalidades do Sistema

Leitura Escrita Leitura Escrita

Captulo 6. Funcionalidades do Sistema

Figura 6.6: Interface para elaborao de relatrios.

Figura 6.7: Menu de acesso aos relatrios.

Captulo 7. Implantao do Maritaca

Captulo 7. Implantao do Maritaca

Captulo 8. Contribuies no Cdigo

(a) Slider Maritaca.

(b) Seek Bar Android.