Coleta Móvel de Dados em dispositivos Android: um

Coleta Móvel de Dados em
dispositivos Android: um estudo
sobre a arquitetura do projeto
Maritaca
Leonardo Betto Sueoka
Coleta Móvel de Dados em dispositivos Android: um
estudo sobre a arquitetura do projeto Maritaca
Leonardo Betto Sueoka
Trabalho de conclusão de curso apresentado ao
Instituto de Ciência e Tecnologia – UNIFESP,
como parte das atividades para obtenção do
título de Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Arlindo Flavio da Conceição
São José dos Campos – SP
Março, 2013
Coleta Móvel de Dados em dispositivos Android: um
estudo sobre a arquitetura do projeto Maritaca
Leonardo Betto Sueoka
Trabalho de conclusão de curso apresentado ao
Instituto de Ciência e Tecnologia – UNIFESP,
como parte das atividades para obtenção do
título de Bacharel em Ciência da Computação.
Orientador: Prof. Dr. Arlindo Flavio da Conceição
Banca Examinadora:
——————————————
Prof. Dr. Arlindo Flavio da Conceição
——————————————
Prof. Dr. Ezequiel Roberto Zorzal
——————————————
Prof. Dr. Luiz Eduardo Galvão Martins
Aprovado em:
Aos meus pais, pelo amor, dedicação e pelo eterno incentivo.
Agradecimentos
Agradeço à minha família e meus amigos Mathias, Scott, Vivian, Konishi e Marcio, pois com
vocês minha vida universitária foi mais divertida.
A minha namorada Cássia Vieira de Oliveira pelas palavras de incentivo e por estar sempre
presente.
Ao membros da equipe Maritaca, sempre prestativos para ajudar.
Agradeço também ao meu orientador Arlindo Flavio da Conceição e a todos meus professores,
pois eles ajudaram a formar o que sou hoje.
Resumo
de dados é um campo com muito espaço para o uso de
dispositivos móveis, como os smartphones Android. O projeto
Maritaca tem como objetivo o desenvolvimento de uma infraestrutura para um sistema distribuído de coleta móvel de dados (CMD),
com base em formulários digitais, na qual três componentes se destacam:
a aplicação do dispositivo Android, os serviços web para gerenciamento
dos formulários e os repositórios 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 criação de
novas funcionalidades para a componente móvel Android, assim como a
avaliação e um caso de uso do sistema.
A
C oleta
Palavras-chave: TCC, Android, Coleta Móvel de Dados, Sistemas Distribuídos.
i
Abstract
data collection is a field 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 Maritaca’s
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.
T
He
Keywords: TCC, Android, Mobile Data Collection, Distributed Systems.
ii
Sumário
Resumo
i
Abstract
ii
Lista de Figuras
vi
Lista de Tabelas
vii
Lista de Acrônimos
viii
1
Introdução
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
3
2
Android e a Máquina Virtual Dalvik
2.1 Histórico . . . . . . . . . . . .
2.1.1 Histórico das Versões . .
2.2 Arquitetura . . . . . . . . . . .
2.3 Fragmentação . . . . . . . . . .
2.4 A Máquina Virtual Dalvik . . .
2.4.1 Arquivos .dex . . . . . .
3
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
8
9
9
Trabalhos Relacionados à Coleta Móvel de Dados
3.1 MIT App Inventor . . . . . . . . . . . . . . . .
3.2 Nokia Data Gathering (NDG) . . . . . . . . . .
3.3 Open Data Kit (ODK) . . . . . . . . . . . . . .
3.4 doForms . . . . . . . . . . . . . . . . . . . . .
3.5 Considerações Finais . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
14
14
Ferramentas e Ambiente de Desenvolvimento Distribuído
4.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
15
16
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4.3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
16
16
17
Arquitetura do Maritaca
5.1 Visão Geral . . . . . . . . . . .
5.1.1 Servidor . . . . . . . . .
5.1.2 Repositórios de Dados .
5.2 Sistema Móvel . . . . . . . . .
5.2.1 MVC no Sistema Móvel
5.2.2 Engine . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
22
22
23
23
24
Funcionalidades do Sistema
6.1 Utilização . . . . . . . . . . . . .
6.2 Recursos do Formulário Digital . .
6.3 Compartilhamento de Informações
6.4 Relatórios . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
30
31
32
7
Implantação do Maritaca
7.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Implantação no Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Aplicação Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33
34
36
8
Contribuições no Código
8.1 Question Slider . . . . . . . . . .
8.1.1 Passos da Implementação
8.2 Serviço de Notificações . . . . . .
8.2.1 Passos da Implementação
8.3 Menu Settings . . . . . . . . . . .
8.3.1 Passos da Implementação
8.4 Problemas Reportados . . . . . .
.
.
.
.
.
.
.
38
38
39
40
40
42
42
43
Estudo de Caso
9.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Formulário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
44
45
46
10 Conclusões
10.1 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
48
49
49
Referências Bibliográficas
50
A Especificação de Formulário no Arquivo XML
54
4.4
4.5
5
6
9
Android SDK . . .
4.3.1 Plugin ADT
Git . . . . . . . . .
SourceForge . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Classe Question
56
v
Lista de Figuras
2.1
2.2
2.3
Arquitetura do Sistema (Google Inc., 2012b). . . . . . . . . . . . . . . . . . .
Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b). . . . . .
Comparativo entre arquivos .dex e .class (Ehringer, 2010). . . . . . . . . . . .
7
8
11
4.1
Página inicial do Maritaca no SourceForge. . . . . . . . . . . . . . . . . . . .
18
5.1
5.2
5.3
5.4
5.5
Componentes do Maritaca. . . . . . . . . . . . . . . . . .
Componentes do Maritaca. . . . . . . . . . . . . . . . . .
Relacionamento entre as componentes do MVC na Engine.
Estrutura de Classes de Question. . . . . . . . . . . . . . .
Estrutura de classes do Comparison. . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
24
25
26
6.1
6.2
6.3
6.4
6.5
6.6
6.7
Tela de login. . . . . . . . . . . . . . . . . . . .
Tela principal. . . . . . . . . . . . . . . . . . . .
Criação de formulários. . . . . . . . . . . . . . .
Autenticação e tela principal do aplicativo móvel.
Exemplos de questões no aplicativo móvel. . . .
Interface para elaboração de relatórios. . . . . . .
Menu de acesso aos relatórios. . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
29
30
30
32
32
7.1
Modos de importar projetos no Eclipse. . . . . . . . . . . . . . . . . . . . . .
37
8.1
8.2
8.3
8.4
Customização da componente Seek Bar
Notificação de novos dados coletados. .
Fluxograma do sistema de notificações.
Tela Settings. . . . . . . . . . . . . . .
.
.
.
.
39
40
41
42
9.1
9.2
9.3
Questões do formulário Bandejão. . . . . . . . . . . . . . . . . . . . . . . . .
Relatório gerado a partir dos dados coletados no formulário Bandejão. . . . . .
Respostas do formulário Bandejão incluindo arquivos de imagens. . . . . . . .
45
47
47
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lista de Tabelas
2.1
Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). .
10
6.1
Políticas de compartilhamento de dados no Maritaca. . . . . . . . . . . . . . .
31
7.1
Arquivo de configuração configuration.properties. . . . . . . . . . . . . . . . .
35
vii
Lista de Acrônimos
AAC
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 Ciência da Computação
Bacharelado em Ciência e Tecnologia
Bacharelado em Matemática Computacional
Code Division Multiple Access
Coleta Móvel de Dados
Create, Read, Update, Delete
Concurrent Version System
Distributed Version Control System
Dalvik Virtual Machine
Google File System
Health Device Profile
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 Specification 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 APÍTULO
1
Introdução
Obter informações de diferentes localidades, armazená-las e analisá-las, na maioria das vezes
ainda são processos manuais. As informações coletadas são muitas vezes transcritas para formulários impressos e depois arquivadas, consumindo espaço e recursos. A coleta de dados
praticada com formulários impressos é suscetível a erros humanos, assim como qualquer procedimento manual, dessa forma, é natural que a coleta de dados a partir de dispositivos móveis
se sobressaia como uma solução viável para automatizar esse processo.
Dispositivos móveis como celulares, tablets e smartphones são aparelhos cada vez mais 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 significa mais de 190 milhões de dispositivos móveis
em território nacional (Anatel, 2010). Com um aumento expressivo, o Brasil fechou o ano de
2012 com 261 milhões de linhas móveis (Anatel, 2013). Desse montante aproximadamente 27
milhões são os chamados smartphones (Google e MediaCT, 2012).
Um smartphone, ou celular inteligente, é um pequeno computador com diversos instrumentos como sensores, câmeras, conectividade sem fio, GPS (Global Positioning System) e uma
tela sensível ao toque. Apesar de muitos recursos, os smartphones possuem limitações como
alimentação por bateria, memória principal e armazenamento em disco reduzidos. O Android é
uma plataforma baseada no Linux desenvolvida especificamente para smartphones. O Android
é um projeto open source, ou seja, possui o código aberto, mantido pela Open Handset Alliance
(OHA) que é formada por um grupo de grandes empresas, lideradas pela Google, interessadas
1
Capítulo 1. Introdução
2
na evolução dessa plataforma. De acordo com dados do final de 2012, 69,7% da parcela do
mercado pertence ao Android (Gartner Inc., 2013).
A adoção de dispositivos móveis inteligentes e o abandono do uso de formulários impressos
na Coleta Móvel de Dados (CMD) pode gerar uma grande economia de material (pranchetas,
folhas de papéis e tintas para impressão etc.), além de importantes benefícios ambientais. Por
exemplo, o custo ambiental de uma folha de escritório, considerando todo o processo desde
cultivo e retirada da árvore, produção de papel e eliminação de resíduos, é de 20,9 gramas
de emissão de dióxido de carbono na atmosfera. E a cada 80 mil e 500 folhas de papéis não
fabricadas uma árvore é salva (Jadkowski, 2012).
Apenas a praticidade de utilizar smartphones para CMD aliada as suas vantagens econômicas e ambientais já justificariam sua implementação. Mas além desses benefícios, eles possibilitam o uso de recursos multimídia como fotos, áudio e vídeo. Tais recursos tornam muito mais
ricas tanto a interação dos usuários quanto a qualidade das informações presentes nos formulários digitais, pois a apresentação da informação ocorre de maneira multissensorial, 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 criação de aplicativos móveis para smartphones Android. Esses aplicativos
representam os formulários digitais. O Maritaca proporciona uma interface web interativa para
a concepção do formulário e o gerenciamento das informações coletadas. O projeto possui três
vertentes principais: a aplicação móvel Android, os serviços web e os repositórios de dados.
O foco deste trabalho é estudar a arquitetura do Maritaca com ênfase na componente móvel
Android e colaborar com seu desenvolvimento.
1.1
Objetivos
O objetivo deste trabalho é estudar a arquitetura da componente móvel Android do projeto
Maritaca, como ela interage com as outras componentes e colaborar com seu desenvolvimento
em um ambiente distribuído e open source. Também faz parte do escopo integrar a equipe
de desenvolvedores do projeto, assim como explorar as funcionalidades do sistema em uma
situação real. Pode-se listar os seguintes objetivos específicos:
• Estudar, avaliar e testar, por meio de um estudo de caso, a arquitetura do projeto Maritaca;
• Implementar os seguintes itens na componente Android:
– Um tipo de questão do formulário digital: o slider;
Capítulo 1. Introdução
3
– Um sistema de notificações que informa ao usuário a quantidade de novas coletas
realizadas por outros usuários que compartilham o mesmo formulário;
– Uma interface na qual o usuário pode definir configurações sobre o intervalo de
sincronização com o servidor.
Para mais informações sobre o projeto Maritaca acesse http://maritaca.unifesp.
br.
1.2
Organização do Texto
Este trabalho está organizado em nove capítulos. O Capítulo 2 disserta sobre o histórico do
Android e esclarece os principais conceitos e características dessa plataforma e de sua máquina
virtual chamada Dalvik. O Capítulo 3 compara o Maritaca com outros trabalhos com objetivos e funcionalidades similares. As ferramentas colaborativas utilizadas no desenvolvimento do
Maritaca são listadas e descritas no Capítulo 4. O Capítulo 5 apresenta a arquitetura aplicada no
desenvolvimento do sistema com foco no sistema móvel. O Capítulo 6 expõe as características
funcionais do sistema e pode ser usado como tutorial para sua utilização. A implantação do
módulo servidor e móvel é descrita no Capítulo 7. O Capítulo 8 apresenta as principais contribuições para a componente móvel. O Capítulo 9 apresenta um caso de uso do sistema e comenta
sobre o potencial da ferramenta e, por fim, o Capítulo 10 discorre sobre as lições aprendidas,
considerações finais e trabalhos futuros.
C APÍTULO
2
Android e a Máquina 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. Usuários cada vez mais exigentes e aplicações cada vez mais
complexas e sofisticadas surgirão. O objetivo dessa plataforma é prover um sistema aberto, no
qual os desenvolvedores de aplicações possam usar quaisquer recursos disponíveis para cada
aparelho, inclusive os utilizados pelas aplicações internas, aproveitando ao máximo o que eles
têm a oferecer.
Este capítulo discorre sobre o histórico, arquitetura, desafios e a máquina virtual da plataforma Android.
2.1
Histórico
A Google adquiriu uma startup chamada Android Inc., em 2005, com o objetivo de entrar
no mercado de dispositivos móveis. Os principais nomes da Android Inc. eram Andy Rubin
(considerado o criador do Android), Rich Miner, Nick Sears, e Chris White (Hashimi et al.,
2009). Andy Rubin é hoje é vice-presidente de plataformas móveis da Google.
Em 2007, um grupo de empresas, liderado pela Google, chamado de Open Handset Alliance
foi criado para gerenciar e criar novas diretrizes para a plataforma Android. A OHA é uma
4
Capítulo 2. Android e a Máquina Virtual Dalvik
5
aliança comercial composta por muitas das maiores e bem sucedidas empresas do mundo. Seus
membros representam toda a cadeia comercial de dispositivos móveis, incluindo fabricantes de
chips, fabricantes de celulares, desenvolvedores de software e provedores de serviço (Conder
e Darcey, 2012). Além disso, é objetivo da OHA garantir que o projeto tenha código aberto e
assim reagir mais rapidamente e de forma inovadora as exigências do mercado (Open Handset
Alliance, 2012).
Em novembro de 2007, foi divulgada uma versão pré-lançamento do Android SDK (Software Development Kit) e já em 2008 foi lançado o primeiro aparelho baseado na plataforma
Android, o T-Mobile G1. Poucos dias depois a versão 1.0 do Android SDK foi lançada e em
outubro de 2008 a Google tornou o código fonte da plataforma Android aberto sob a licença
Apache (Hashimi et al., 2009). A partir desse momento, muitas fabricantes começaram a produzir dispositivos Android em 2009 e início de 2010. A plataforma ganhou mercado rapidamente
e no final de 2010 o Android tornou-se líder de mercado, ganhando espaço de plataformas competitivas como o BlackBerry da RIM, o iOS da Apple e o Windows Mobile (Conder e Darcey,
2012).
2.1.1
Histórico das Versões
Várias versões do Android foram lançadas desde seu início, agregando novos recursos e funcionalidades. Atualmente o Android encontra-se na versão 4.2 Jelly Bean. O histórico da evolução das versões, assim como as principais mudanças e suas datas de lançamento são listadas
abaixo (Google Inc., 2012b):
1.1 - Fevereiro de 2009: Versão inicial;
1.5 (Cupcake) - Abril de 2009
Nova API, refinamentos da interface de usuário, melhorias de desempenho, atualização
do Kernel do Linux para a versão 2.6.27.
1.6 (Donut) - Setembro de 2009
Nova API, aperfeiçoamento da interface de usuário, atualização do Kernel do Linux para
a versão 2.6.29, suporte para resoluções 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, aperfeiçoamento da interface de usuário, melhoria na renderização de gráficos,
bluetooth 2.1,
Capítulo 2. Android e a Máquina Virtual Dalvik
6
2.2 (Froyo) - Maio de 2010
Nova API, aperfeiçoamento da interface de usuário, novo framework de mídia, novas
funcionalidades para o bluetooth, atualização do Kernel do Linux para a versão 2.6.32.
2.3 (Gingerbread) - Dezembro de 2010
Nova API, aperfeiçoamento da interface de usuário, suporte para NFC (Near Field Communications), mudanças na Dalvik e atualização do Kernel do Linux para a versão 2.6.35.
3.0, 3.1, 3.2 (Honeycomb) - Fevereiro de 2011
As melhorias das versões do Android Honeycomb são focadas em adaptações para os
tablets. Nova API, aperfeiçoamento da interface de usuário.
4.0, 4.0.1, 4.0.3, 4.0.4 (Ice Cream Sandwich) - Outubro de 2011
Nova API, aperfeiçoamento da interface de usuário, novos recursos multimídia, novos
tipos de conectividade como o Wi-Fi Direct e Bluetooth Health Device Profile (HDP).
4.1, 4.2 (Jelly Bean) - Julho de 2012
Melhorias de segurança, otimizações na Dalvik, evolução do software da câmera e bluetooth, melhora no suporte ao NFC (Android Beam) e reprodução de áudio com baixa
latência.
2.2
Arquitetura
O Android é composto por uma pilha de software que inclui um Sistema Operacional, Middleware e aplicações chave (Google Inc., 2012b). A arquitetura do Android é composta pelas
componentes mostradas na Figura 2.1.
Essa pilha é composta por cinco camadas: Aplicações, Framework para Aplicações, Bibliotecas juntamente com a Android Runtime e Kernel do Linux. A camada de Aplicações é o
conjunto de todos os aplicativos instalados no dispositivo e que são escritos com uma sintaxe
similar ao do Java. Estes são todos os aplicativos nativos indispensáveis (tais como navegador
de internet, cliente de correio eletrônico, aplicativo para gerenciar SMS, calendário, contatos
etc.) e os aplicativos que o usuário pode instalar pela Google Play (Google Inc., 2012b).
Na camada Application Framework, estão todas as API’s disponibilizadas no SDK do Android para desenvolver aplicações ricas utilizando os diversos recursos presentes nesse sistema
operacional, como:
• Views: são usadas para construir a interface com o usuário (telas da aplicação);
Capítulo 2. Android e a Máquina Virtual Dalvik
7
Figura 2.1: Arquitetura do Sistema (Google Inc., 2012b).
• Content Providers: possibilitam que aplicações troquem informações entre si;
• Resource Manager: permite acesso a arquivos externos como gráficos, arquivos de layout
e de internacionalização;
• Notification Manager: provê a capacidade de gerar notificações personalizadas na barra
de status;
• Activity Manager: gerencia o ciclo de vida das aplicações e o fluxo de navegação.
A camada de bibliotecas representa um conjunto de bibliotecas escritas em C e C++ que possuem funcionalidades específicas e muito usadas pela camada acima. Nessa camada encontram-se
bibliotecas para execução de mídia altamente otimizadas para dispositivos com recursos limitados (Brahler, 2010), como codificadores e decodificadores para execução e gravação de vídeo
(H264, MPEG4), áudio (MP3, AAC, AMR) e imagens (JPEG, PNG). Inclui-se nessas bibliotecas o SQLite (SQLite Community, 2013), pacotes para renderização 2D e 3D, entre outros (Google Inc., 2012b).
Já a Runtime Android possui bibliotecas chaves do Java, além da DVM (Dalvik Virtual
Machine) que será mais detalhada na Seção 2.4 (Google Inc., 2012b).
Na camada de mais baixo nível, há o Kernel Linux na versão 2.6 modificado para atuar
em aspectos fundamentais do sistema como gerenciamento do consumo de energia, memória,
Capítulo 2. Android e a Máquina Virtual Dalvik
8
processos, rede e segurança. Além de operar também como intermediária entre o hardware e as
outras camadas da pilha (Google Inc., 2012b).
2.3
Fragmentação
Um tema que gera muita discussão entre usuários e fabricantes do Android é o problema de
fragmentação. O Android continua evoluindo rapidamente desde seu início e, com isso, muitas
versões foram lançadas. Existem diversas versões deste sistema operacional instalados em diversos modelos de smartphones de diversas marcas, desde a antiga versão 1.5 lançada em abril
de 2009, também chamada de Cupcake, até recém-lançada versão 4.2, chamada de Jelly Bean.
A discussão se dá pela incompatibilidade das versões que estão sendo efetivamente utilizadas pelos usuários, ou seja, existem dispositivos Android ativos em todas as suas versões. De
acordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as versões do
Android Gingerbread, 28,6% possuem as versões do Ice Cream Sanduich, 15,5% possuem as
versões mais recente do Jelly Bean e também 7,5% possuem versão 2.2 Froyo. De fato, há uma
fragmentação de versões no Android.
O grande problema da fragmentação é que as versões antigas não desfrutam de todas as
novas funcionalidades das versões mais atuais, além disso, os desenvolvedores de aplicativos
priorizam o suporte de seus produtos para as versões mais recentes. Ou seja, os usuários que
possuem smartphones com Android desatualizado não possuem acesso aos aplicativos que exigem as versões mais recentes instaladas. Por um lado existe o aspecto negativo, que é a fragmentação, mas pelo outro há o aspecto positivo que é a evolução rápida e constante do sistema.
Figura 2.2: Distribuição Atual de Versões - Março de 2013 (Google Inc., 2012b).
Capítulo 2. Android e a Máquina Virtual Dalvik
9
Fabricantes vendem seus smartphones e tablets com determinadas versões do Android e fica
sob seu juízo a atualização desses aparelhos quando são lançadas novas versões. Porém, desenvolver pacotes de atualização gera despesas e geralmente apenas os aparelhos mais populares
os recebem. Note que o aparelho precisa ter poder de processamento suficiente para executar as
versões mais novas, ou seja, os aparelhos mais antigos dificilmente receberão atualizações do
Android.
2.4
A Máquina 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 primária do Android pela grande comunidade de desenvolvedores e pela relativa
facilidade de utilização. Apesar disso, a Dalvik não é uma verdadeira plataforma Java. O Android usa uma implementação alternativa e mais limitada da biblioteca padrão do Java, na qual
grande parte das bibliotecas principais do JavaSE estão presentes. Alguns dos motivos da Google decidir criar sua própria máquina virtual não padronizada foram os problemas apresentados
pelo JavaMe, problemas burocráticos no licenciamento de novas funcionalidades do Java pelo
JSR (Java Specification Request), desempenho, segurança, entre outros (Maker, 2011).
O objetivo da plataforma Android é abranger a maior quantidade possível de dispositivos,
desde os mais antigos de baixa capacidade até os mais atuais de alta capacidade. Essa intenção
faz com que os dispositivos obsoletos imponham que a plataforma seja eficiente o suficiente
para que tais dispositivos sejam capazes de executá-la. A execução do Android precisa suportar
condições como baixa capacidade de processamento, baixa capacidade da memória RAM, nenhum espaço para swap, funcionamento à bateria, diversos modelos de dispositivos e execução
segura de aplicativos (Ehringer, 2010). Dados todos esses requisitos a DVM foi projetada para
usar o mínimo dos recursos do sistema.
Múltiplas instâncias da Dalvik são executadas simultaneamente. Este fato ocorre porque
cada aplicação Android representa um processo sendo executado, o qual possui uma instância
da DVM. Dessa maneira, os processos ficam bem isolados, criando uma forte barreira entre as
aplicações (Maker, 2011).
2.4.1
Arquivos .dex
Na plataforma Java padrão, um arquivo .java é compilado pela JVM (Java Virtual Machine) e
o resultado disso é o bytecode Java no arquivo .class correspondente. Por exemplo, um arquivo
Capítulo 2. Android e a Máquina Virtual Dalvik
10
.java possui uma classe pública, uma classe estática interna e três classes anônimas o resultado
da compilação serão 5 arquivos .class que serão lidos em tempo de execução pela JVM (Ehringer, 2010). Apesar da linguagem de desenvolvimento do Android ser o Java, isso não acontece
da mesma forma nos dispositivos móveis.
Na plataforma Android os arquivos .class continuam sendo gerados, porém a ferramenta
chamada dx os converte para a extensão .dex (Dalvik Executable) e são esses arquivos que são
executados pela DVM. A função da dx além de converter é otimizar o uso de memória e o
espaço em disco, alocando vários .class em apenas um .dx (Ehringer, 2010).
Os arquivos .dex otimizam espaço de armazenamento contendo dados únicos, ou seja, não
há repetição de informações. Por exemplo, se várias classes fazem referência a uma string
constante de caracteres, esse objeto existe apenas uma vez nos arquivos .dex e suas múltiplas
ocorrências são apenas ponteiros para esse objeto (Brahler, 2010). As constantes como strings,
campos, variáveis, classes, interfaces, e nomes de métodos são armazenadas em pools de constantes. Um pool é um conjunto de recursos inicializados e prontos para serem usados. Na
Figura 2.3 são exibidos os pools de constantes em azul. Temos que cada arquivo .class possui
seu próprio pool heterogêneo de constantes que agrupa todas as constantes em um só lugar.
Em contrapartida, o arquivo .dex, que contém várias classes, possui vários pools de constantes
organizados e compartilhados (Ehringer, 2010).
Na Tabela 2.1 os arquivos .dex apenas com as otimizações citadas no parágrafo anterior
possuem menor tamanho em bytes que os arquivos .jar comprimidos.
Tabela 2.1: Comparação do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008).
Sem compressão
Compressão Jar
Arquivo Dex sem compressão
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%)
Capítulo 2. Android e a Máquina Virtual Dalvik
Figura 2.3: Comparativo entre arquivos .dex e .class (Ehringer, 2010).
11
C APÍTULO
3
Trabalhos Relacionados à Coleta
Móvel de Dados
Existem projetos com objetivos e funcionalidades semelhantes ao do Maritaca e que tiverem
seu desenvolvimento iniciado em paralelo. Este capítulo 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 código disponibilizado. O MIT (Massachusetts Institute of Technology)
com o apoio da Google criou um centro para estudo sobre tecnologias móveis, cujo objetivo
principal é dar continuidade ao desenvolvimento do App Inventor para Android.
O App Inventor constrói uma aplicação sem a necessidade do usuário ter conhecimento de
programação. O projeto consiste principalmente de duas aplicações: o App Inventor Design
e o App Inventor Blocks Editor. Semelhante a tela de criação de formulários do Maritaca, o
App Inventor Design possui uma interface intuitiva na qual os componentes são arrastáveis e
o usuário os posiciona na tela da sua aplicação facilmente. O App Inventor Blocks Editor tem
a função de associar eventos para cada componente adicionado. O App Inventor possui uma
12
Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados
13
interessante funcionalidade que permite ao usuário ver em seu dispositivo móvel a sua aplicação
sendo montada em tempo real, desde que o dispositivo esteja conectado em seu computador.
O AppInventor é uma aplicação com um escopo generalista, voltado para usuários interessados em criar suas próprias aplicações. Já o Maritaca tem um escopo específico: a Coleta Móvel
de Dados.
3.2
Nokia Data Gathering (NDG)
O Nokia Data Gathering (Nokia Corp., 2013b) é um projeto de código aberto desde 2010 e
tem como objetivo a automatização da coleta móvel de dados. Funciona com a criação de
questionários e o envio dos mesmos para os agentes de campo que acessam os formulários
através de seus celulares por uma conexão sem fio. As respostas são enviadas à central, que
as armazena. É possível exportar as informações coletadas para formatos mais manejáveis, tais
como planilhas.
O NDG é utilizado na prática em alguns projetos sociais. Em Manaus, no estado do Amazonas, juntamente com a Secretaria de Estado de Saúde (SUSAM), o NDG foi usado para a coleta
de informações pertinentes as famílias atingidas pela dengue, ajudando no combate à doença.
Tanto o NDG quanto o Maritaca possuem escopos semelhantes. Uma diferença importante
é que o NDG está disponível apenas para a plataforma Java ME e Windows Phone, que possuem
parcelas reduzidas de mercado.
3.3
Open Data Kit (ODK)
O projeto ODK (ODK Community, 2013) possui código aberto e é composto por um conjunto
de ferramentas que auxiliam na criação e gerenciamento da coleta móvel de dados. Entre eles
estão: Build, Collect e Aggregate. A Build consiste de uma interface web que possibilita a criação de formulários interativamente, inclusive com perguntas multimídia, como áudio, vídeo e
imagens. A Collect é uma aplicação para Android que realiza a coleta de dados nos dispositivos
móveis Android. A Aggregate gerencia as informações coletadas através dos formulários que
podem ser exportadas para formatos mais usuais, como planilhas. Outras ferramentas que são
desenvolvidas pelo ODK são o Form Uploader, Briefcase, Validate e o XLS2XFORM.
O Maritaca e o ODK possuem objetivos diferentes apesar de terem a CMD como escopo.
Enquanto o Maritaca oferece uma infraestrutura para a criação de formulários e gereciamento
das informações coletadas, o ODK é basicamente um conjunto de API’s e padrões que podem
Capítulo 3. Trabalhos Relacionados à Coleta Móvel de Dados
14
ser usados por outros projetos. Alguns dos projetos que usam o ODK são: FormHub, EpiSurveyor, Group Complete, KoBo Toolbox, ViewWorld, PhiCollectUm e o doForms, que será
apresentado na próxima seção.
3.4
doForms
O doForms (doForms Inc., 2013) é um projeto cuja proposta é similar ao Maritaca, porém possui
código proprietário. O doForms é baseado no projeto ODK, portanto ambos possuem grandes
semelhanças. A aplicação para dispositivos móveis é multiplataforma permitindo dispositivos
iOS, Android e BlackBerry. É possível usar o sistema gratuitamente com algumas restrições,
como cota máxima de dados de 200 MB e somente usar a aplicação móvel para um único
dispositivo. Outra restrição é que somente alguns tipos de questões podem ser usadas para
montar formulários para usuários com contas gratuitas.
Da mesma forma que o NDG e o Maritaca, as respostas coletadas dos questionários no
doForms são enviadas para um servidor. A partir disso, o usuário é capaz de gerenciar esses
dados e enviar novos formulários para os dispositivos dos agentes coletores.
As principais diferenças entre o doForms e o Maritaca é que o primeiro se trata de uma
solução paga e multiplataforma enquanto que o objeto de estudo deste trabalho apresenta uma
solução aberta e exclusiva para a plataforma Android.
3.5
Considerações Finais
Os trabalhos que mais se assemelham tanto no objetivo quanto nos serviços disponibilizados
é o doForms e o NDG. O doForms e o Maritaca apresentam contextos diferentes visto que
o Maritaca apresenta uma solução aberta, enquanto que para usar o doForms com todas suas
funcionalidades é necessário custear uma taxa mensal. Apesar disso, o doForms apresenta uma
solução multiplataforma para sua aplicação móvel, que é um benefício considerável. O NDG
aparenta ser a solução mais madura dentre as citadas, pois possui registros de sua utilização em
situações significativas. Além do caso citado na Seção 3.2, ele foi posto em prática no Kenya e
na África Oriental (Nokia Corp., 2013a). Como já explanado anteriormente uma desvantagem
notável é a aplicação móvel do NDG estar disponível para plataformas pouco utilizadas.
C APÍTULO
4
Ferramentas e Ambiente de
Desenvolvimento Distribuído
Uma das grandes vantagens de se trabalhar em grupo é a paralelização das tarefas de um determinado projeto, pois teoricamente quanto mais mão de obra mais rápido o projeto é concluído.
No entanto, no âmbito de desenvolvimento de software existem algumas variáveis que não
tornam essa afirmação tão simples. São necessárias ferramentas para alinhar conhecimento,
documentar os códigos fontes gerados, um repositório online que todos tenham acesso, IDE de
desenvolvimento, controle de versão, entre outras ferramentas. As seções a seguir descrevem
as ferramentas utilizadas neste trabalho.
4.1
Eclipse
Eclipse é uma IDE (Integrated Development Environment) de código aberto e robusta para a plataforma Java, porém possui diversos plugins que adicionam funcionalidades para a codificação
em outras linguagens. No caso de desenvolvimento para Android, a linguagem de programação
padrão possui sintaxe similar a da linguagem Java, mas são necessárias outras ferramentas e
bibliotecas da API para que seja possível utilizar toda a capacidade do aparelho celular (Eclipse
Foundation, 2012).
15
Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído
4.2
16
JUnit
JUnit é uma biblioteca de código aberto criada por Kent Beck e Erich Gamma que visa facilitar
o processo de teste de código.
O processo de teste de software é parte indispensável no desenvolvimento de qualquer aplicação porque é ele que indica possíveis falhas ou erros presentes no código fonte. Ou seja,
a qualidade do software a ser produzido está fortemente ligada a cobertura dos testes (Neto,
Aristides V. P., 2009). O JUnit automatiza esse processo executando todos os testes escritos
pelo desenvolvedor e gerando, ao final, um relatório intuitivo indicando quais testes passaram e
quais não passaram.
4.3
Android SDK
O Android SDK (Software Development Kit) provê as ferramentas e bibliotecas necessárias
para desenvolver, testar e depurar novas aplicações (Google Inc., 2012b).
4.3.1
Plugin ADT
O plugin ADT (Android Development Tools) disponível para o Eclipse, juntamente com o Android SDK dá acesso ao usuário as bibliotecas de qualquer versão do Android liberada, facilitando o desenvolvimento de uma aplicação para uma versão específica. Inclui também um
emulador do próprio sistema, assim é possível o desenvolvedor depurar suas aplicações que
estão em fase de desenvolvimento, outra opção é 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 versão, ou VCS (Version Control System), utilizado neste trabalho
e também amplamente utilizado pelo mercado. Os VCS’s funcionam armazenando um histórico
das modificações que foram feitas em um conjunto de arquivos sendo possível voltar da sua
versão atual para qualquer outra versão específica nesse histórico. Além do Git, existem outros
VCS’s ainda muito utilizados atualmente como o CVS (Concurrent Version System) e o SVN
(Subversion).
Entre as principais funcionalidades do Git estão retomar arquivos para um estado específico,
recuperar projetos inteiros para um estado específico, comparar mudanças ao longo do tempo,
Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído
17
verificar e registrar as alterações e quem foi o autor dessas mudanças, entre outras funcionalidades. Por ter toda essa flexibilidade, o Git é muito popular desde os desenvolvedores de softwares
que trabalham sozinhos até as grandes corporações (Chacon e Aljord, 2009).
O Git se enquadra no conceito de DVCS (Distributed Version Control System), que é um
sistema de controle de versões distribuído. Cada desenvolvedor é potencialmente tanto um hub
como um node, ou seja, todo desenvolvedor pode contribuir com seu código para outros repositórios e manter um repositório público no qual outros desenvolvedores podem basear seu
trabalho e começar a contribuir também. Essa flexibilidade do Git permite que várias configurações de fluxo 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 código aberto. Provê ferramentas para a gerência do código fonte, documentação, fórum
de discussão e status do projeto. A página inicial do Maritaca no SourceForge é mostrada na
Figura 4.1.
Atualmente, o projeto Maritaca está hospedado no SourceForge através do endereço https:
//sourceforge.net/projects/maritaca/ e seu código fonte está disponível para
download por meio de um repositório Git. Ferramentas como o fórum de discussão entre os
desenvolvedores é muito utilizado e facilita a comunicação quando os envolvidos no projeto
não estão fisicamente no mesmo lugar. Assim como o wiki que é a documentação de conceitos
já definidos, tutoriais, ambiente de desenvolvimento, entre outros.
Capítulo 4. Ferramentas e Ambiente de Desenvolvimento Distribuído
Figura 4.1: Página inicial do Maritaca no SourceForge.
18
C APÍTULO
5
Arquitetura do Maritaca
O projeto Maritaca é hospedado utilizando uma arquitetura de computação em nuvem, ou seja,
todo seu código é executado e os dados são armazenados remotamente em servidores disponíveis para acesso pela Internet. Dessa maneira, as informações geradas pelos usuários nos dispositivos móveis estão disponíveis em quaisquer computador com acesso a grande rede, através
de um navegador (Armbrust et al., 2010). Esse tipo de solução é escalável, ou seja, é possível
contratar ou liberar rapidamente mais servidores equilibrando a demanda de requisições e os
recursos disponíveis do sistema, caso a quantidade de usuários do sistema aumente ou diminua
consideravelmente.
O Maritaca implementa um modelo de serviço chamado de SaaS (Software as a Service),
que é um modelo associado a aplicações baseadas na computação em nuvem que disponibilizam seus serviços ao usuário via um navegador web. O conceito deste modelo se traduz na
mudança de paradigma no âmbito de comércio e distribuição de software. No olhar de um
cliente, ao invés de comprar a licença de um software e instalá-lo em seus computadores, ele
concorda em usar a aplicação que será hospedada pela empresa que desenvolve e comercializa o
software, dando ao comprador flexibilidade para alternar fornecedores e evitar problemas com
manutenção (Dubey e Wagle, 2007).
A arquitetura do Maritaca é composta por várias componentes que possuem funções específicas e que interagem entre si. A Figura 5.1 mostra os principais elementos e suas interações
com os usuários do sistema no ciclo de coleta e persistência de informações. Basicamente o
19
Capítulo 5. Arquitetura do Maritaca
20
usuário cria o aplicativo que corresponde a um formulário digital no sistema web do Maritaca e
o instala em um dispositivo móvel Android. O coletor usa a aplicação no seu dispositivo para
adquirir e enviar às informações coletadas ao servidor do Maritaca. Os dados são salvos nos
repositórios de dados e estão disponíveis para consulta ou download.
No decorrer deste capítulo, serão vistas informações sobre a arquitetura, tecnologias e metodologias usadas em todos os componentes da solução.
Figura 5.1: Componentes do Maritaca.
5.1
Visão Geral
A arquitetura do projeto possui três grandes pilares: sistema móvel, servidor web e as bases de
dados. A Figura 5.2 mostra de modo geral como essas componentes interagem.
A componente mobile devices representa os dispositivos móveis Android e é onde este trabalho está concentrado. Trata-se de uma aplicação Android que tem como principal funcionalidade a execução dos formulários, que são especificados através de arquivos XML, gerados
no portal Maritaca. As requisições feitas da aplicação móvel para o servidor são encapsuladas
pelo framework OAuth (OAuth Community, 2013), usado para aumentar a segurança do sistema no que diz respeito a autenticação dos usuários. A componente móvel e suas interações
serão descritas na Seção 5.2.
O desenho modular do maritaca define que as camadas de apresentação (Presentation Layer),
a camada de negócios (Business Layer), a camada de Web Services e a camada de acesso as bases de dados (Data Acess) sejam independentes e separadas. A modularidade reduz a complexidade de sistemas, facilita futuras manutenções, mudanças no código e agiliza a implementação
Capítulo 5. Arquitetura do Maritaca
21
Figura 5.2: Componentes do Maritaca.
do software pormitindo o desenvolvimento paralelo em diferentes partes do sistema (Pressman,
2006).
Tanto o código escrito para o servidor quanto o código escrito para o dispositivo móvel são
códigos Java. Mas em uma situação hipotética, o código usado no servidor poderia ser escrito
em outra linguagem visto que a comunicação entre o dispositivo móvel e o servidor ocorre via
web services, o que dispensa o uso da mesma linguagem de programação. Note que se outra
linguagem de programação fosse usada, provavelmente algumas tecnologias empregadas no
sistema atual teriam de ser trocadas por outras compatíveis com a linguagem escolhida.
Capítulo 5. Arquitetura do Maritaca
5.1.1
22
Servidor
Os serviços e funcionalidades web do sistema estão incorporados no servidor de aplicações web
open source JBossAS (http://www.jboss.org/jbossas). Logo, o servidor agrupa as
camadas de apresentação, negócio, acesso ao banco de dados e web services.
Quando um usuário cria seu formulário o sistema constrói uma aplicação Android correspondente ao formulário criado. O arquivo XML contendo as especificações do formulário é
embutido dentro da aplicação. Dessa forma, cada aplicação criada corresponde a apenas um
formulário. O usuário pode criar diversos formulários e cada um será uma aplicação diferente.
Os web services foram implementados usando o modelo REST (Representional State Transfer) através do framework RESTEasy (JBoss Community, 2013). O REST é um modelo idealizado de como a internet deveria funcionar. Este modelo de interações de aplicações web se
tornou a base da arquitetura moderna da internet (Fielding e Taylor, 2002). Este estilo arquitetural é uma abstração do básico do protocolo HTTP (Hypertext Transfer Protocol) e consiste
em conceitos ao invés de sintaxes e detalhes técnicos (Schreier, 2011).
Todas as funcionalidades do sistema que envolvem envio e recebimento de mensagens de
correio eletrônico são implementadas pelo no sistema com o framework de código aberto RabbitMQ (VMware Inc., 2013).
A camada de apresentação representa as telas que são apresentadas ao usuário. As páginas
de gerenciamento de formulários 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
Repositórios de Dados
São usados duas bases de dados com propósitos diferentes: o Cassandra (The Apache Software
Foundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b).
O Cassandra é um sistema de banco de dados distribuído open source criado pela Apache
Software Foundation. Ele é dito No-SQL, ou seja, não utiliza a predominante arquitetura relacional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciar
grandes quantidades de dados, provendo um serviço 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 formulários.
O acesso ao banco de dados Cassandra se dá pela API Hector (Hector Community, 2013).
Ela fornece bibliotecas de alto nível para realizar diversos tipos de procedimentos na base de
Capítulo 5. Arquitetura do Maritaca
23
dados que vão desde operações básicas de CRUD (Create, Read, Update, Delete) até controle
do pool de conexões.
O Hadoop é também um projeto open source da Apache Software Foundation que inclui
implementações de um sistema de arquivos distribuído, MapReduce baseado no GFS (Google
File System) e outros projetos de MapReduce (Borthakur et al., 2011). Neste projeto ele é
usado para armazenar modelos de dados não estruturados, principalmente arquivos, como áudio,
vídeo, imagens e executáveis Android (arquivos com extensão apk).
5.2
Sistema Móvel
Depois de criar ou editar um formulário a partir de um navegador web, o formulário pode ser
preenchido no dispositivo móvel no qual os dados coletados serão armazenados temporariamente no banco de dados local.
O módulo móvel no Maritaca corresponde ao aplicativo para Android e é responsável por
gerenciar e coletar as respostas dos questionários.
5.2.1
MVC no Sistema Móvel
O Sistema Móvel do Maritaca segue o padrão de projeto MVC (Model, View, Controller) que é
largamente utilizado na indústria de software. Trata-se da separação clara de cada um de seus
componentes:
• O Model é o módulo no qual se encontram as regras de negócio da aplicação juntamente
com suas entidades.
• A View é a tela de interface com o usuário. É nessa componente que os dados são visualizados pelo usuário e onde ele interage com o sistema.
• O Controller é responsável por intermediar os dois componentes anteriores. Ele basicamente pega os dados gerados da comunicação do usuário com a View e os entrega para o
Model processar, o mesmo ocorre no sentido inverso.
A grande vantagem desse padrão de projeto é tornar o sistema modular, sendo cada camada
independente da outra. Isso nos leva a facilidade de manutenção, por exemplo, se for necessária
uma mudança nos cálculos de uma aplicação, o desenvolvedor precisa apenas alterar o Model.
Analogamente, se for necessária uma mudança de design na tela de visualização, é apenas lá
que o desenvolvedor vai realizar a mudança (Eric Freeman, 2007).
Capítulo 5. Arquitetura do Maritaca
24
No cenário do sistema móvel, é no Model que estão concentradas as regras de negócio,
ou seja, as implementações do funcionamento de cada questão, validações e comparações. A
View é composta pelas telas do sistema. No Android, as telas são definidas por arquivos XML
nos quais estão estabelecidos o posicionamento das componentes como texto, botão, checkbox,
entre outros. Quem implementa a ação desses componentes é o Controller, que no contexto do
Android são suas Activities. A Figura 5.3 mostra como esses componentes se relacionam.
Figura 5.3: Relacionamento entre as componentes do MVC na Engine.
5.2.2 Engine
Toda a comunicação entre dispositivo móvel e servidor ocorre via web services e, sendo mais
específico, quando essa comunicação envolve questionários ou respostas de questionários ela
transmite informações que representam arquivos XML. Esses arquivos precisam ser lidos e
transformados em objetos Java que representam uma pergunta no questionário. Ocorre o mesmo
no sentido inverso, um objeto Java que representa uma resposta é transformado em um arquivo
XML e é enviado ao servidor. As manipulações dos arquivos XML são realizadas pela Engine.
Ou seja, a Engine é responsável por receber dados que descrevem um questionário e retornar
objetos Java que são efetivamente as questões implementadas.
A Engine implementa o padrão de projeto Interpreter. Este padrão define que dado uma
linguagem, é possível determinar uma representação para ela por intermédio de um interpretador que usa essa representação para processar sentenças da linguagem (Gamma et al., 1994). O
conceito fundamental do Interpreter na Engine é apresentar um conjunto hierárquico de classes que representa a especificação de um formulário, que por sua vez representa a linguagem
a ser interpretada. O arquivo XML, ou a especificação de formulários, é a linguagem a ser
interpretada e a Engine é o interpretador.
Capítulo 5. Arquitetura do Maritaca
25
Cada tipo de questão do formulário digital é representada por uma hierarquia de classes, cuja
superclasse é a classe Question. Essa superclasse possui atributos e métodos que são comuns as
subclasses. Essa estrutura de classes pode ser vista na Figura 5.4. O responsável por processar
o XML e gerar os objetos definidos pelas subclasses de Question é o Parser.
Figura 5.4: Estrutura de Classes de Question.
Parser
A leitura de formulários é feita baseada em um conjunto de classes que representam o arquivo
XML. O formulário em si é representado pela classe Form, seus elementos são compostos pela
classe Questions e os atributos dos elementos são representados pelas classes Comparison e
Clause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework
Simple (Simple Community, 2013), que facilita a implementação e melhora a legibilidade do
código. O Simple também auxilia na serialização dos arquivos XML de respostas dos formulários.
O trabalho de manusear as entidades citadas acima é responsabilidade das classes utilitárias
XMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes são referenciadas
na camada de negócio do sistema móvel.
As respostas dos formulários são transmitidas da unidade móvel Android para o servidor
através de grandes strings de caracteres, encapsuladas em requisições HTTP, que representam
seus respectivos arquivos XML.
Comparison
Um formulário com perguntas sequenciais nem sempre é interessante para determinados conjuntos de perguntas. Essa funcionalidade é passível de ser implementada em um formulário
digital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma pergunta anterior. Por exemplo, a pergunta: “Você ingere bebidas alcoólicas?” só deverá aparecer
Capítulo 5. Arquitetura do Maritaca
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 formulário de perguntas
e que pode ter as seguintes comparações: igual, maior, maior ou igual, menor e menor ou igual.
Cada comparação é representada por uma classe e todas elas estendem a classe abstrata Clause,
conforme mostra a Figura 5.5.
Figura 5.5: Estrutura de classes do Comparison.
C APÍTULO
6
Funcionalidades do Sistema
O Maritaca oferece ao usuário uma interface simples e intuitiva para a criação de formulários,
geração de aplicações e coleta de dados. Basicamente, são necessários três passos para que um
ciclo de coleta de dados se complete:
1. Pelo navegador de internet, o usuário cria o questionário. O sistema construirá a aplicação
Android e o disponibilizará para download.
2. A aplicação é instalada no dispositivo Android;
3. O usuário coleta as informações e envia as respostas ao servidor.
Esse capítulo detalha as funcionalidades que o sistema oferece e ao mesmo tempo é um guia
para sua utilização.
6.1
Utilização
O endereço de acesso do Maritaca é http://maritaca.unifesp.br. Para utilizar o
sistema, é necessário efetuar um cadastro simples e depois se logar, como mostra a Figura 6.1.
Caso o usuário já tenha uma conta de usuário da Google, Yahoo ou do Facebook é possível
utilizá-la através da tecnologia OpenID (OpenID Foundation, 2012).
27
Capítulo 6. Funcionalidades do Sistema
28
Figura 6.1: Tela de login.
Após a autenticação, o usuário é levado para a página principal do sistema, onde são listados
todos os formulários 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 usuários.
Figura 6.2: Tela principal.
Capítulo 6. Funcionalidades do Sistema
29
Ao clicar no botão New Form o usuário é levado para a tela de criação de formulários. O
painel da esquerda contém os tipos de pergunta que o usuário pode adicionar ao seu formulário,
como uma pergunta em forma de texto, uma foto, um vídeo, uma data, localização por GPS,
entre outras. As perguntas são componentes HTML 5 arrastáveis (drag and drop), dessa forma
o usuário pode adicionar um desses itens simplesmente arrastando-o para o centro da tela. No
exemplo da Figura 6.3 o formulário possui quatro perguntas.
Figura 6.3: Criação de formulários.
Após salvar o formulário, a criação do aplicativo para Android começa automaticamente de
forma assíncrona. Depois de criado, o usuário pode fazer o download do aplicativo e instalá-lo
no seu dispositivo Android.
Após a instalação, o aplicativo exige uma autenticação do usuário, da mesma forma que
quando acessado através do navegador. A interface principal mostrada na Figura 6.4 é composta
por um menu que corresponde ao formulário criado anteriormente. Para coletar informações
deste formulário basta selecionar a opção Collect.
As próximas sequências de telas correspondem às perguntas criadas previamente na interface web do Maritaca. A Figura 6.5 ilustra as questões do formulário criado anteriormente. As
telas de questionário são divididas de forma que na região superior fiquem localizados o título
do formulário, uma barra de progresso, um botão de ajuda e um botão de cancelar. O restante
da tela é ocupado pela questão e sua resposta.
O usuário pode realizar quantas coletas forem necessárias para um mesmo formulário. Depois dos dados serem coletados, o usuário pode enviar essas informações para os servidores do
Maritaca e acessá-las na sua conta via interface web.
Capítulo 6. Funcionalidades do Sistema
30
Figura 6.4: Autenticação e tela principal do aplicativo móvel.
Figura 6.5: Exemplos de questões no aplicativo móvel.
6.2
Recursos do Formulário Digital
Os questionários podem ser criados utilizando vários tipos de recursos. A interface web do
Maritaca disponibiliza perguntas dos seguintes tipos: texto, seleção múltipla (checkbox), numeral, data, múltipla escolha (combobox e radiobox), foto, áudio, vídeo, GPS, código de barras,
controle deslizante (slider) e desenho. O Maritaca está em constante desenvolvimento e existem planos para adicionar mais tipos de perguntas. Uma grande vantagem do sistema é sua
arquitetura modular que facilita a adição de novas componentes. Por exemplo, todos os tipos
de questões estão agrupados em um pacote de classes independente, dessa forma, para criar um
novo tipo de questão, basta criar novas classes que representam o tipo de questão desejado. É
importante salientar que é necessário estender a classe abstrata Question que define como os
métodos devem ser implementados.
Cada questão do formulário digital do Maritaca possui propriedades importantes que deixam
o sistema mais robusto para o uso na CMD. Cada questão pode ter seu valor padrão inicial, um
Capítulo 6. Funcionalidades do Sistema
31
valor mínimo e um valor máximo definidos na etapa da criação do formulário. Também há a
possibilidade de tornar uma pergunta obrigatória ou mantê-la opcional. Outra funcionalidade
que merece destaque é a capacidade do desvio do fluxo normal da sequência das perguntas
através de algumas condicionais, tais como: igual, menor, maior, menor ou igual e maior ou
igual. Ou seja, é possível ir pra alguma questão específica do questionário a partir da questão
atual, obviamente que a mudança da sequência depende da resposta.
Uma propriedade útil das questões é o campo ajuda. Trata-se de um campo texto que complementa a descrição da questão e pode ser acessado a partir de um botão na região superior do
aplicativo móvel.
6.3
Compartilhamento de Informações
O nível de compartilhamento dos formulários e suas respostas podem ocorrer em três graus:
privado, público e compartilhado. No compartilhamento privado, o formulário só está acessível
ao seu criador (owner). No público, o formulário é acessível para todos. O nível compartilhado
de um formulário ocorre quando o seu criador convida outros usuários para acessá-lo. Esse
nível possui duas ramificações:
• Hierárquico: Os usuários convidados não podem acessar as respostas coletadas de outros
convidados. Apenas o criador do formulário consegue ver todas as respostas;
• Social: Ao contrário do item anterior, tanto os usuários convidados quanto o criador
conseguem acessar todas as respostas coletadas.
A Tabela 6.1 sintetizou os tipos de permissões de acesso (leitura e escrita dos dados coletados) para o criador do formulário e seus convidados, de acordo com o grau de compartilhamento.
Tabela 6.1: Políticas de compartilhamento de dados no Maritaca.
Formulário
Resposta
Leitura
Escrita
Leitura
Escrita
Privado
Criador
Criador
Criador
Criador
Comp. Hierárquico
Criador e Convidados
Criador
Criador
Criador e Convidados
Comp. Social
Criador e Convidados
Criador
Criador e Convidados
Criador e Convidados
Público
Todos
Criador
Todos
Criador
Capítulo 6. Funcionalidades do Sistema
6.4
32
Relatórios
A geração automática de relatórios é uma funcionalidade que está em desenvolvimento, porém
não pode deixar de ser mencionada. Ela permite que a partir das informações coletadas e das
perguntas selecionadas pelo usuário seja gerado um relatório contendo gráficos de pizza ou
barras e organizar os dados em forma de tabelas. Por enquanto os relatórios são gerados apenas
com questões de seleção múltipla como checkbox e radiobox. A Figura 6.6 exibe a tela de
criação de relatórios em que o relatório (coluna central) contém duas questões do formulário
(coluna da esquerda).
É possível criar e editar vários relatórios para um mesmo formulário. Para acessá-los, basta
abrir o menu de opções do formulário desejado, exibido na Figura 6.7, e clicar na opção Edit
Report ou View Report, na página principal do Maritaca.
Figura 6.6: Interface para elaboração de relatórios.
Figura 6.7: Menu de acesso aos relatórios.
C APÍTULO
7
Implantação do Maritaca
Este capítulo destaca os passos para a implantação do sistema e configuração do ambiente de
desenvolvimento.
7.1
Ambiente de Desenvolvimento
A preparação do ambiente de desenvolvimento consiste na instalação e configuração das ferramentas e bibliotecas utilizadas no desenvolvimento de um sistema. O sistema operacional
recomendado para o desenvolvimento do Maritaca é o Ubuntu versão 11.10. As ferramentas
usadas no desenvolvimento juntamente com suas páginas oficiais são listadas abaixo:
• JDK (Java Development Kit) versão 6: http://www.oracle.com/technetwork/
java/javase/downloads/index.html;
• Eclipse IDE para Java EE: http://www.eclipse.org/downloads/;
• Plugin maven para Eclipse: http://www.eclipse.org/m2e/
• Android SDK: http://developer.android.com/sdk/index.html;
• Plugin ADT: http://developer.android.com/tools/sdk/eclipse-adt.
html;
33
Capítulo 7. Implantação do Maritaca
34
• Cassandra http://cassandra.apache.org/download/;
• Tomcat 7 http://tomcat.apache.org/download-70.cgi;
• Apache Maven: http://maven.apache.org/;
• Apache Ant: http://ant.apache.org/;
• Git: http://git-scm.com/
• RabbitMQ: http://www.rabbitmq.com/;
Note que para o Eclipse poder ser executado, o JDK 6 precisa ser instalado primeiro.
7.2
Implantação no Servidor
Após todos os itens da seção anterior serem instalados e devidamente configurados, é necessário
fazer o download do código fonte do Maritaca que está disponível na página 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
Após a execução do comando, a pasta contendo o código fonte estará no diretório corrente.
O módulo servidor é divido em quatro projetos: business, persistence, web e webservices. O
módulo móvel possui um único projeto: o maritaca-mobile.
O arquivo de configuração configuration.properties é essencial para a implantação do projeto. Ele pode ser criado em qualquer diretório contanto que sua localização seja fixada por
meio da variável de ambiente MARITACA_CONFIG_PATH. Esse arquivo é exibido na Tabela
7.1.
Antes de iniciar o servidor é necessário configurar o Cassandra. Primeiro deve-se subir o
serviço no terminal executando o seguinte arquivo, localizado na pasta de instalação do Cassandra:
$ sudo ./bin/cassandra
Usando outro terminal é preciso criar o keyspace do Maritaca, executando os seguintes
comandos:
Capítulo 7. Implantação do Maritaca
35
Tabela 7.1: Arquivo de configuração configuration.properties.
Propriedade
maritaca_mobile_path
android_sdk_path
maritaca_uri_server
filesystem_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
$ ./bin/cassandra-cli -h localhost
create keyspace Maritaca;
exit;
Para configurar o RabbitMQ execute os seguintes comandos:
$ sudo rabbitmqctl add_user maritaca maritaca
$ sudo rabbitmqctl add_vhost Maritaca
$ sudo rabbitmqctl set_permissions -p Maritaca maritaca ".*" ".*" ".*"
Há um projeto chamado rabbit-consumer na pasta services. O projeto deve ser compilado
com o maven através do comando:
$ mvn clean package
Um arquivo JAR referente ao projeto será gerado. Deve-se executá-lo através do comando:
$ java -jar rabbit-consumer-1.0.jar
O servidor de aplicações Tomcat pode ser iniciado através de um script localizado na pasta
bin que fica no diretório onde foi instalado o Tomcat. Dentro desta pasta, basta executar o
comando:
$ ./catalina.sh run
Capítulo 7. Implantação do Maritaca
36
Após o servidor ser inicializado a interface web do Tomcat pode ser acessada por meio do
endereço http://localhost:8080.
O próximo passo é compilar o projeto servidor e gerar um arquivo WAR (Web application
ARchive) que representa a aplicação web do Maritaca a ser implantada no servidor. O projeto
é compilado com a ferramenta maven, executado no terminal e na pasta server do projeto, 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 módulo
servidor. É esse arquivo que deve ser implantado no servidor. O maven possui plugins extras
que se instalados permitem que logo após o projeto ser compilado, o arquivo WAR construído é
automaticamente implantado no servidor. Existem outras maneiras como utilizar a interface web
do servidor e fazer o upload do próprio arquivo WAR. Após a implantação o módulo servidor do
Maritaca pode ser acessado através do endereço http://localhost:8080/maritaca.
7.3
Aplicação Android
Se o plugin ADT e o Android SDK foram instalados corretamente, dois ícones devem aparecer
no Eclipse: o Android SDK Manager e o Android Virtual Device Manager. O primeiro se trata
de um gerenciador das API’s do Android assim como algumas ferramentas. O projeto Maritaca
pode ser compilado a partir da API 7, portanto se faz necessária a instalação de uma API igual
ou superior. O Android Virtual Device Manager é um gerenciador de dispositivos virtuais que
emulam um smartphone Android. Pode-se criar vários dispositivos virtuais, cada um com sua
respectiva versão do Android e atributos como memória principal e resolução de tela.
Se a versão do Ubuntu instalada é 64 bits, então a instalação da biblioteca ia32-libs se faz
necessária para trabalhar com o Android SDK.
O módulo móvel do Maritaca depende de outro projeto: o ActionBarSherlock (http:
//actionbarsherlock.com/). No projeto ele está nomeado como library e está no
mesmo diretório do maritaca-mobile. O código fonte do módulo móvel Android está dentro
da pasta maritaca-mobile. Para adicionar o projeto ao Eclipse é necessário importa-lo pelo
menu File -> Import ou clicando com o botão direito no Package Explorer -> Import conforme
mostra a Figura 7.1. Após esse passo, surge um menu com vários tipos de projetos. Deve-se
escolher um projeto do tipo Android como fonte. Lembre-se de importar tanto o library quanto
o maritaca-mobile.
Capítulo 7. Implantação do Maritaca
37
Figura 7.1: Modos de importar projetos no Eclipse.
Após importado, o projeto pode ser visualizado no Package Explorer. Todas as classes,
arquivos de layout, bibliotecas adicionais e arquivos de configuração podem ser acessados. Para
executar o projeto basta clicar com o botão direito no projeto e selecionar Run As -> Android
Application. O dispositivo virtual criado anteriormente será iniciado e a aplicação instalada e
executada.
C APÍTULO
8
Contribuições no Código
Este capítulo apresenta as principais contribuições, por mim realizadas, no código fonte do
sistema móvel do projeto Maritaca. Foram desenvolvidas três funcionalidades principais: a
implementação do tipo de questão slider, um serviço de notificação de novos dados enviados e
a tela de configuração ou settings. Esses três itens cobrem campos diferentes tanto da arquitetura
do Maritaca quanto da API do Android, abrangendo tópicos como a criação de telas por arquivos
XML, consultas e inserções de dados através do SQLite, uso do sistema de notificação e de
alarme do Android, implementação da classe Question, entre outros.
8.1
Question Slider
O Slider no Maritaca é a implementação da Seek Bar presente na API do Android. Com essa
componente é possível 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
Capítulo 8. Contribuições no Código
(a) Slider Maritaca.
39
(b) Seek Bar Android.
Figura 8.1: Customização da componente Seek Bar
8.1.1
Passos da Implementação
A classe abstrata Question, mostrada no Apêndice B, define quais métodos os tipos de questões
devem implementar. Essa classe é fundamental no contexto do sistema, pois todas as manipulações que a Engine faz para criar os objetos, que correspondem as questões no formulário,
são feitas com base nos seus métodos. Para desenvolver o Slider foi necessário implementar os
seguintes métodos abstratos:
public abstract ComponentType getComponentType();
Este método retorna o tipo do componente ou questão a ser implementada. ComponentType é um Enum, ou seja, uma classe estruturada de tal forma que seus dados sejam
imutáveis (Sierra e Bates, 2005). É nessa classe que estão definidos todos os tipos de
questões com um respectivo identificador, inclusive o slider.
public abstract Object getValue();
Retorna o valor adquirido pela questão. No caso do slider é retornado um valor numérico,
mas caso fosse um questão do tipo texto, este método retornaria uma string de caracteres.
public abstract View getLayout(ControllerActivity activity);
Este método retorna o Slider customizado. O slider é montado a partir da seek bar 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
usuário mude.
public abstract boolean validate();
A validação da questão é feita quando o usuário avança ou retrocede no formulário no
menu de coleta. Um tipo de validação é a verificação da obrigatoriedade da resposta, ou
seja, a resposta da questão não pode ser vazia. O slider implementa este tipo de validação.
public abstract void save(View answer);
A implementação deste método ocorre da mesma forma que o item anterior, porém o
método salvar é executado antes, pois no contexto do sistema é necessário salvar o valor
selecionado pelo usuário para poder executar a validação.
Capítulo 8. Contribuições no Código
8.2
40
Serviço de Notificações
Um serviço no Android, representado pela classe Service, é uma componente de aplicação que
tem como função realizar operações prolongadas que não interferem com o usuário ou prover
funcionalidades para outras aplicações. Os serviços não são processos ou threads adicionais, ou
seja, são executados no mesmo processo da aplicação a qual pertencem. A classe IntentService
estende Service e é usada para lidar com tarefas assíncronas, ou seja, ela cria threads para
processar o que foi requisitado e depois elimina a thread (Google Inc., 2012b).
O serviço de notificações é composto por uma IntentService que faz uma requisição HTTP
para o servidor acessando um web service que retorna uma resposta que contém a quantidade de
novas coletas enviadas ao servidor, a partir de uma data, por outros coletores para o formulário
em questão. Se houverem novas coletas a própria IntentService lança uma notificação, como
a ilustrada na Figura 8.2. Essa funcionalidade é útil quando existem vários coletores para um
mesmo formulário.
Figura 8.2: Notificação de novos dados coletados.
8.2.1
Passos da Implementação
Criação do Serviço
O serviço é representado pela classe NotificationService que estende IntentService. Essa classe
é responsável por criar a notificação e gerenciar a requisição e sua resposta HTTP. Caso a
resposta do web service retorne um inteiro maior que zero, uma notificação é gerada indicando
o número de novas coletas, caso contrário, uma notificação é gerada indicando que nenhuma
coleta foi enviada ao servidor.
O NotificationService é chamado assim que a tela de menu é construída. Quem faz a chamada é a classe AlarmManager que provê acesso a sistema de alarmes do Android e permite
agendar a execução do serviço, que é feita repetidamente e em intervalos de tempo definidos
Capítulo 8. Contribuições no Código
41
pelo usuário. A tela de configuração, melhor detalhado na Seção 8.3, inclui opções para ligar
ou desligar o serviço de notificação e determinar o intervalo de tempo que a sincronização com
o servido é realizada.
Tratamento da Requisição e Resposta
A requisição é feita criando um objeto que representa uma requisição HTTP e o enviando. A
criação da requisição envolve a passagem de parâmetros de dois parâmetros a partir da URL:
a identificação do formulário e a data da última sincronização. Depois que a requisição foi
enviada cabe ao servidor recebê-la e tratá-la. O servidor usa o RESTEasy (JBoss Community,
2013) que implementa a especificação JAX-RS (Oracle Corp., 2013a) e provê uma biblioteca
para web services RESTful, facilitando seu uso.
O servidor está configurado para filtrar as requisições feitas aos web services e encaminhá-las
para seu respectivo método de implementação. Este método faz uma busca no banco de dados
que retorna uma lista de formulários enviados ao servidor, por outros usuários, a partir da data
recebida como parâmetro. Com essa lista em mãos, basta retornar seu tamanho. O resultado
é encapsulado em um objeto que corresponde ao uma resposta HTTP e é enviada de volta ao
NotificationService. A Figura 8.3 representa a sequência dos eventos e chamadas do sistema de
notificações.
Figura 8.3: Fluxograma do sistema de notificações.
Capítulo 8. Contribuições no Código
8.3
42
Menu Settings
A partir do menu principal há um botão com opção de ir para tela de configurações ou Settings.
As opções de configuração nessa tela fazem referência a seção anterior, logo, ela contém um
botão no qual é possível ativar ou desativar a sincronização com o servidor do sistema de notificações. Caso esse botão for habilitado, a escolha do intervalo de tempo de sincronização
também será. A Figura 8.4 apresenta a tela com suas respectivas componentes.
Figura 8.4: Tela Settings.
8.3.1
Passos da Implementação
A criação de telas, ou interfaces de usuário, no Android ocorre pela representação 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 sincronização do sistema de
notificações;
• A Seek Bar, responsável por determinar o intervalo de sincronização em minutos. Note
que esta componente só estará habilitada de o botão do item anterior também estiver;
• O botão Save Settings que persiste as configurações no banco de dados local do dispositivo móvel.
Capítulo 8. Contribuições no Código
43
Para armazenar as preferências do usuário, foi necessário criar uma tabela no banco de dados
local. Cada linha desta tabela armazena se o Toggle Button está ativado ou não, o intervalo de
sincronização e o usuário a quem pertence essas opções.
A API do Android fornece algumas classes que facilitam a manipulação de tabelas no banco
de dados local SQLite. Para manipular os dados dessa tabela foram implementados métodos
para inserção, atualização e consulta desses dados. A inserção ocorre quando não existem dados
na tabela e o usuário pressiona o botão Save Settings. A atualização ocorre da mesma forma,
porém somente quando existem dados na tabela. As consultas são feitas na própria tela Settings,
no momento de sua criação, para carregar as componentes com os valores salvos anteriormente,
e também no AlarmManager para pegar o valor do intervalo de sincronização.
8.4
Problemas Reportados
Os problemas encontrados no sistema podem ser adicionados na página de notificação de bugs
no SourceForge do Maritaca (https://sourceforge.net/p/maritaca/bug/). Os
problemas encontrados e submetidos são listados a seguir:
• O aplicativo móvel não abre em versões do Android 4.0 ou superior. Esse problema
ocorre quando requisições HTTP são executadas na thread principal da aplicação, o que
pode acarretar em ANR (Application Not Responding) (Google Inc., 2012b). A página referente ao bug é https://sourceforge.net/p/maritaca/tickets/463/;
• Caso o coletor não tiver acesso à internet ele não consegue coletar dados. A Seção 9.3
descreve como este problema foi encontrado. A página referente ao bug é https://
sourceforge.net/p/maritaca/bug/53/;
• Quando uma questão do tipo Picture é enviada ao servidor com uma foto grande (2 MBytes) o a aplicação para de responder, gerando um aviso de ANR.
C APÍTULO
9
Estudo de Caso
A fim de avaliar o funcionamento do sistema em modo de produção, este capítulo apresenta os
resultados da CMD usando o Maritaca em um cenário real.
9.1
Cenário
A Universidade Federal de São Paulo campus São José do Campos iniciou suas atividades em
2007 com apenas um curso, cinquenta alunos e dez docentes. Com um evolução rápida, no
ano de 2012 possuía cerca de mil alunos e oitenta docentes distribuídos entre três cursos e três
turnos diferentes. Para atender esse público, o campus possui uma cantina e um restaurante
universitário (criado em 2011), sendo que o último possui parte do valor da refeição subsidiado
pela universidade. As refeições são oferecidas em dois horários, no almoço 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 cenário para coletar informações sobre a satisfação dos usuários
do restaurante universitário durante 15 dias.
44
Capítulo 9. Estudo de Caso
9.2
45
Formulário
As imagens da Seção 6.1 demonstram a construção da aplicação Bandejão, a mesma utilizada
nessa demonstração. O formulário digital é composto pelos seguintes itens:
• Qual o seu nome? Figura 9.1(a);
• Qual o seu curso? Figura 9.1(b);
• Qual a data da refeição? Figura 9.1(c);
• Qual sua satisfação? Figura 9.1(d);
• Foto da refeição. Figura 9.1(e).
(a) Pergunta não obrigatória do tipo (b) Pergunta obrigatória do tipo (c) Pergunta obrigatória do tipo
texto.
RadioButton com as opções BCC, data.
BCT ou BMC.
(d) Pergunta obrigatória do tipo Ra- (e) Questão não obrigatória do tipo
dioButton com as opções ótimo, Picture.
bom, regular, ruim.
Figura 9.1: Questões do formulário Bandejão.
Capítulo 9. Estudo de Caso
46
A representação desse formulário pelo sistema é feita por arquivos XML. O formulário
Bandejão está especificado em um arquivo XML mostrado no Apêndice A.
O formulário foi criado com a política de compartilhamento hierárquico, ou seja, o criador
tem acesso total para leitura e escrita tanto das respostas como do formulário e os convidados
tem acesso apenas a leitura do formulário e escrita das respostas. Neste cenário, três coletores
diferentes participaram da aquisição dos dados e cada um possuía seu respectivo dispositivo
Android. Os dispositivos, assim como suas versões do Android são listados abaixo.
• Samsung Galaxy SIII, Android versão 4.1.2 Jelly Bean;
• Samgung Galaxy Nexus, Android versão 4.2.2 Jelly Bean;
• Samsung Galaxy 5, Android versão 2.3.3 Gingerbread;
9.3
Resultados
Na aplicação Android e no gerenciador web de formulários é possível ver as respostas coletadas
para cada questionário na forma de tabelas, como mostra a Figura 9.3.
Atente ao fato que não é escopo deste trabalho dissertar sobre a qualidade ou opinião dos
alunos e docentes em relação ao restaurante universitário.
O sistema Maritaca de um modo geral respondeu bem aos comandos, sua interface é intuitiva e os coletores não tiveram problemas em usá-la. Um ponto controverso percebido pelos
coletores é que as componentes móvel e web impõe ao usuário sua autenticação de hora em
hora, ou seja, depois de sessenta minutos contados a partir da autenticação, o usuário é automaticamente desconectado do sistema. Esse método contribui para elevar a segurança porque
dificulta que um usuário não autorizado colete informações, porém em algumas situações como
o dispositivo não 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 formulário Bandejão pode ser visualizada na Figura 9.2,
que contém um gráfico gerado pelos dados da satisfação dos usuários do restaurante universitário da Unifesp. Este gráfico foi criado através da funcionalidade de geração automatizada de
relatórios do sistema web.
Foram realizadas no total trinta e seis coletas, sendo que dez delas possuem conteúdo multimídia. A Figura 9.3 mostra algumas das respostas do formulário Bandejão 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 resolução original.
Capítulo 9. Estudo de Caso
Figura 9.2: Relatório gerado a partir dos dados coletados no formulário Bandejão.
Figura 9.3: Respostas do formulário Bandejão incluindo arquivos de imagens.
47
C APÍTULO
10
Conclusões
Este capítulo apresenta as considerações finais deste Trabalho de Conclusão de Curso, as principais contribuições e os trabalhos futuros que poderão complementar o que foi realizado.
10.1
Considerações Finais
A automatização da Coleta Móvel de Dados é um processo positivo e a tendência de aumentar
sua adoção é alta por incorporar vantagens ambientais e econômicas. 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 braços
do projeto: o módulo 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 manutenção
de código. Sua arquitetura baseada na nuvem traz benefícios importantes como a alta escalabilidade e permite que o usuário acesse os serviços do sistema em qualquer lugar do mundo,
independente da plataforma usada, desde que tenha acesso à internet.
As funcionalidades desenvolvidas abordaram diferentes tópicos da arquitetura do Maritaca
assim como das bibliotecas do Android, fornecendo uma visão mais ampla e concreta de ambos. As principais implementações foram o slider, o sistema de notificações e a interface de
configuração, detalhadas no Capítulo 8.
48
Capítulo 10. Conclusões
10.2
49
Contribuições
Este Trabalho de Conclusão de Curso deixa como contribuição as experiências e lições aprendidas na participação no projeto open source Maritaca em um ambiente de desenvolvimento
distribuído. Além de colaborações no código fonte da componente móvel Android. Este trabalho também pode ser útil como manual e avaliação do sistema.
10.3
Trabalhos Futuros
O projeto Maritaca está numa versão estável, mas há muitos recursos e funcionalidades existentes que podem ser melhoradas e novas que podem ser criadas, já que o campo da Coleta Móvel
de Dados é bastante abrangente. Abaixo estão descritos dos objetivos futuros mais significativos:
• Colaborar no desenvolvimento de outras componentes do sistema, como o servidor e
bases de dados;
• Aumentar a abrangência do sistema tornando-o multiplataforma, criando aplicações para
Web, iOS e BlackBerryOS;
• Analisar a capacidade do sistema, semelhante ao que foi feito no Capítulo 9, porém inserindo quantidades maiores de informações usando todos os tipos de perguntas do formulário digital;
Referências Bibliográficas
A NATEL Brasil ultrapassa um celular por habitante, disponível em: http://goo.gl/
BRnJh (acessado em 28/03/2013), 2010.
A NATEL Telefonia móvel fecha 2012 com 261,78 milhões de linhas, disponível em: http:
//goo.gl/Xam8j (acessado em 29/01/2013), 2013.
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. 50–58, 2010.
B ORNSTEIN , D. Dalvik vm internals. In: Google I/O Developer Conference, 2008, p. 17–30.
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. 1071–1080 (SIGMOD ’11, ).
Disponível 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 .
Official doforms website, disponível 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. 1–12, 2007.
E CLIPSE F OUNDATION Eclipse, disponível em: http://www.eclipse.org (acessado
em 14/04/2012), 2012.
50
Referências Bibliográficas
51
E HRINGER , D. The dalvik virtual machine architecture. Techn. report (March 2010), 2010.
Disponível em http://goo.gl/v2eIy
E RIC F REEMAN , E LISABETH F REEMAN , K. S. B. B. Head first design patterns. O’Reilly
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. 115–150, 2002.
Disponível 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.
Disponível 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, disponível em: http://goo.gl/
1yfr6 (acessado em 29/01/2013), 2012.
G OOGLE I NC . Adt plugin for eclipse, disponível em: http://developer.android.
com/sdk/eclipse-adt.html (acessado em 03/06/2012), 2012a.
G OOGLE I NC . Android developers, disponível em: http://developer.android.
com/index.html (acessado em 06/02/2013), 2012b.
G OOGLE I NC . Official android website, disponível 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
Official hector website, disponível
hector-client.org (acessado em 29/03/2013), 2013.
em:
http://
JADKOWSKI , M. Best practices in mobile data collection, disponível em: www.doforms.
com/support/best-practices.pdf (acessado em 04/06/2012), 2012.
JB OSS C OMMUNITY Official resteasy website, disponível 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. 35–40, 2010.
M AKER , F. Android dalvik virtual machine, disponível em: http://goo.gl/7DvOD
(acessado em 20/02/2013), 2011.
MIT Official mit app inventor website, disponível em: http://appinventor.mit.
edu/ (acessado em 28/03/2013), 2013.
Referências Bibliográficas
52
N ETO , A RISTIDES V. P. Criando testes com junit, disponível em: http://goo.gl/jjDgR
(acessado em 10/06/2012), 2009.
N OKIA C ORP. Nokia data gathering in action, disponível em: https://projects.
developer.nokia.com/ndg/wiki/projects (acessado em 29/03/2013), 2013a.
N OKIA C ORP. Official nokia data gathering website, disponível em: https://projects.
developer.nokia.com/ndg/wiki (acessado em 28/03/2013), 2013b.
OAUTH C OMMUNITY Official oauth website, disponível em: http://oauth.net/2/
(acessado em 04/04/2013), 2013.
ODK C OMMUNITY
Official open data kit website, disponível em:
opendatakit.org/ (acessado em 28/03/2013), 2013.
http://
O PEN H ANDSET A LLIANCE Open handset alliance official website, disponível em: http:
//www.openhandsetalliance.com/ (acessado em 14/04/2012), 2012.
O PEN ID F OUNDATION Official openid website, disponível em: http://openid.net/
developers/ (acessado em 25/06/2012), 2012.
O RACLE C ORP. Official jax-rs website, disponível em: http://jax-rs-spec.java.
net/ (acessado em 04/04/2013), 2013a.
O RACLE C ORP.
Official jsf website, disponível 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. 15–21
(WS-REST ’11, ).
Disponível em http://doi.acm.org/10.1145/1967428.1967434
S IERRA , K.; BATES , B. Head first java. O’Reilly Media, Incorporated, 2005.
S IMPLE C OMMUNITY
Official simple website, disponível em:
sourceforge.net/ (acessado em 04/04/2013), 2013.
http://simple.
SQL ITE C OMMUNITY Official sqlite website, disponível 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.
Disponível em http://www.christof-strauch.de/nosqldbs.pdf
T HE A PACHE S OFTWARE F OUNDATION Official cassandra website, disponível em: http:
//cassandra.apache.org/ (acessado em 29/03/2013), 2013a.
Referências Bibliográficas
53
T HE A PACHE S OFTWARE F OUNDATION Official hadoop website, disponível em: http:
//hadoop.apache.org/ (acessado em 29/03/2013), 2013b.
T HE J Q UERY F OUNDATION Official jquery website, disponível em: http://jquery.
com/ (acessado em 29/03/2013), 2013.
VM WARE I NC . Official rabbitmq website, disponível em: http://www.rabbitmq.com/
(acessado em 04/04/2013), 2013.
W3C The syntax, vocabulary and apis of html5, disponível em: http://dev.w3.org/
html5/html-author/ (acessado em 31/03/2013), 2010.
A PÊNDICE
A
Especificação de Formulário no
Arquivo XML
O arquivo XML abaixo descreve a especificação do formulário digital Bandejão, que foi usado
no capítulo 9.
<?xml version="1.0" encoding="UTF-8"?>
<form>
<title>Bandejão</title>
<questions>
<text id="0" next="1" required="false" >
<label>Qual seu nome?</label>
<help></help>
<size>100</size>
<default></default>
</text>
<radio id="1" next="2" required="true" >
<label>Qual seu curso?</label>
<help></help>
<default></default>
<option value="0" checked="false">BCC</option>
<option value="1" checked="false">BMC</option>
<option value="2" checked="false">BCT</option>
</radio>
<date id="2" next="3" required="true" >
<label>Data da refeição.</label>
<help></help>
<default></default>
<format>mm/dd/yy</format>
54
Capítulo A. Especificação de Formulário no Arquivo XML
</date>
<radio id="3" next="4" required="true" >
<label>Qual sua satisfação?</label>
<help></help>
<default></default>
<option value="0" checked="false">Ótimo</option>
<option value="1" checked="false">Bom</option>
<option value="2" checked="false">Regular</option>
<option value="3" checked="false">Ruim</option>
</radio>
<picture id="4" next="-1" required="false" >
<label>Foto da Refeição</label>
<help></help>
</picture>
</questions>
</form>
55
A PÊNDICE
B
Classe Question
O arquivo Java abaixo representa a classe abstrata Question, peça importante do sistema móvel
do Maritaca. Note que algumas linhas de código foram ocultadas (imports, package, getters e
setters) porque não são necessárias para compreensão de sua implementação.
/* Imports and Package (Hidden)*/
public abstract class Question implements Serializable {
private static final long serialVersionUID = 1L;
@Attribute(required = true)
protected Integer id;
@Attribute(required = false)
protected Integer next;
@Attribute(required = false)
protected Integer previous;
@Element(required = false)
protected String help;
@Element(name = "default", required = false)
protected String _default;
@Attribute(required = false)
protected Boolean required;
56
Capítulo B. Classe Question
@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