Você está na página 1de 73

Coleta Mvel de Dados em

dispositivos Android: um estudo


sobre a arquitetura do projeto
Maritaca
Leonardo Betto Sueoka

Coleta Mvel de Dados em dispositivos Android: um


estudo sobre a arquitetura do projeto Maritaca

Leonardo Betto Sueoka

Trabalho de concluso de curso apresentado ao


Instituto de Cincia e Tecnologia UNIFESP,
como parte das atividades para obteno do
ttulo de Bacharel em Cincia da Computao.

Orientador: Prof. Dr. Arlindo Flavio da Conceio

So Jos dos Campos SP


Maro, 2013

Coleta Mvel de Dados em dispositivos Android: um


estudo sobre a arquitetura do projeto Maritaca

Leonardo Betto Sueoka

Trabalho de concluso de curso apresentado ao


Instituto de Cincia e Tecnologia UNIFESP,
como parte das atividades para obteno do
ttulo de Bacharel em Cincia da Computao.

Orientador: Prof. Dr. Arlindo Flavio da Conceio

Banca Examinadora:

Prof. Dr. Arlindo Flavio da Conceio

Prof. Dr. Ezequiel Roberto Zorzal

Prof. Dr. Luiz Eduardo Galvo Martins

Aprovado em:

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

Agradecimentos

Agradeo minha famlia e meus amigos Mathias, Scott, Vivian, Konishi e Marcio, pois com
vocs minha vida universitria foi mais divertida.
A minha namorada Cssia Vieira de Oliveira pelas palavras de incentivo e por estar sempre
presente.
Ao membros da equipe Maritaca, sempre prestativos para ajudar.
Agradeo tambm ao meu orientador Arlindo Flavio da Conceio e a todos meus professores,
pois eles ajudaram a formar o que sou hoje.

Resumo

de dados um campo com muito espao para o uso de


dispositivos mveis, como os smartphones Android. O projeto
Maritaca tem como objetivo o desenvolvimento de uma infraestrutura para um sistema distribudo de coleta mvel de dados (CMD),
com base em formulrios digitais, na qual trs componentes se destacam:
a aplicao do dispositivo Android, os servios web para gerenciamento
dos formulrios e os repositrios de dados. Este trabalho est focado no
estudo da arquitetura do Maritaca e no desenvolvimento colaborativo da
componente Android. Este trabalho gerou como resultados a criao de
novas funcionalidades para a componente mvel Android, assim como a
avaliao e um caso de uso do sistema.

C oleta

Palavras-chave: TCC, Android, Coleta Mvel de Dados, Sistemas Distribudos.

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 Maritacas
architecture and collaborative development of Android component. This
work has produced results as the creation of new features for the Android
mobile component, as well as evaluation and a case of use of the system.

He

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

ii

Sumrio

Resumo

Abstract

ii

Lista de Figuras

vi

Lista de Tabelas

vii

Lista de Acrnimos

viii

Introduo
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Organizao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2
3

Android e a Mquina Virtual Dalvik


2.1 Histrico . . . . . . . . . . . .
2.1.1 Histrico das Verses . .
2.2 Arquitetura . . . . . . . . . . .
2.3 Fragmentao . . . . . . . . . .
2.4 A Mquina Virtual Dalvik . . .
2.4.1 Arquivos .dex . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

4
4
5
6
8
9
9

Trabalhos Relacionados Coleta Mvel de Dados


3.1 MIT App Inventor . . . . . . . . . . . . . . . .
3.2 Nokia Data Gathering (NDG) . . . . . . . . . .
3.3 Open Data Kit (ODK) . . . . . . . . . . . . . .
3.4 doForms . . . . . . . . . . . . . . . . . . . . .
3.5 Consideraes Finais . . . . . . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

12
12
13
13
14
14

Ferramentas e Ambiente de Desenvolvimento Distribudo


4.1 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
15
16

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

iii

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

4.3

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

16
16
16
17

Arquitetura do Maritaca
5.1 Viso Geral . . . . . . . . . . .
5.1.1 Servidor . . . . . . . . .
5.1.2 Repositrios de Dados .
5.2 Sistema Mvel . . . . . . . . .
5.2.1 MVC no Sistema Mvel
5.2.2 Engine . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

19
20
22
22
23
23
24

Funcionalidades do Sistema
6.1 Utilizao . . . . . . . . . . . . .
6.2 Recursos do Formulrio Digital . .
6.3 Compartilhamento de Informaes
6.4 Relatrios . . . . . . . . . . . . .

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

27
27
30
31
32

Implantao do Maritaca
7.1 Ambiente de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Implantao no Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Aplicao Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33
33
34
36

Contribuies no Cdigo
8.1 Question Slider . . . . . . . . . .
8.1.1 Passos da Implementao
8.2 Servio de Notificaes . . . . . .
8.2.1 Passos da Implementao
8.3 Menu Settings . . . . . . . . . . .
8.3.1 Passos da Implementao
8.4 Problemas Reportados . . . . . .

.
.
.
.
.
.
.

38
38
39
40
40
42
42
43

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

44
44
45
46

10 Concluses
10.1 Consideraes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48
48
49
49

Referncias Bibliogrficas

50

A Especificao de Formulrio no Arquivo XML

54

4.4
4.5
5

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

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

iv

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

B Classe Question

56

Lista de Figuras

2.1
2.2
2.3

Arquitetura do Sistema (Google Inc., 2012b). . . . . . . . . . . . . . . . . . .


Distribuio Atual de Verses - Maro de 2013 (Google Inc., 2012b). . . . . .
Comparativo entre arquivos .dex e .class (Ehringer, 2010). . . . . . . . . . . .

7
8
11

4.1

Pgina 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. . . . . . . . . . . . . . . . . . . .
Criao de formulrios. . . . . . . . . . . . . . .
Autenticao e tela principal do aplicativo mvel.
Exemplos de questes no aplicativo mvel. . . .
Interface para elaborao de relatrios. . . . . . .
Menu de acesso aos relatrios. . . . . . . . . . .

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.

28
28
29
30
30
32
32

7.1

Modos de importar projetos no Eclipse. . . . . . . . . . . . . . . . . . . . . .

37

8.1
8.2
8.3
8.4

Customizao da componente Seek Bar


Notificao de novos dados coletados. .
Fluxograma do sistema de notificaes.
Tela Settings. . . . . . . . . . . . . . .

.
.
.
.

39
40
41
42

9.1
9.2
9.3

Questes do formulrio Bandejo. . . . . . . . . . . . . . . . . . . . . . . . .


Relatrio gerado a partir dos dados coletados no formulrio Bandejo. . . . . .
Respostas do formulrio Bandejo incluindo arquivos de imagens. . . . . . . .

45
47
47

vi

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Lista de Tabelas

2.1

Comparao do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008). .

10

6.1

Polticas de compartilhamento de dados no Maritaca. . . . . . . . . . . . . . .

31

7.1

Arquivo de configurao configuration.properties. . . . . . . . . . . . . . . . .

35

vii

Lista de Acrnimos

AAC
ANR
API
BCC
BCT
BMC
CDMA
CMD
CRUD
CVS
DVCS
DVM
GFS
HDP
HTML
HTTP
IDE
JavaME
JavaSE
JDK
JPEG
JSF
JSR
JVM
Maritaca
MIT
MPEG
MVC
NDG
NFC
ODK
OHA

Advanced Audio Coding


Application Not Responding
Application Programming Interface
Bacharelado em Cincia da Computao
Bacharelado em Cincia e Tecnologia
Bacharelado em Matemtica Computacional
Code Division Multiple Access
Coleta Mvel de Dados
Create, Read, Update, Delete
Concurrent Version System
Distributed Version Control System
Dalvik Virtual Machine
Google File System
Health Device 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 APTULO

1
Introduo

Obter informaes de diferentes localidades, armazen-las e analis-las, na maioria das vezes


ainda so processos manuais. As informaes coletadas so muitas vezes transcritas para formulrios impressos e depois arquivadas, consumindo espao e recursos. A coleta de dados
praticada com formulrios impressos suscetvel a erros humanos, assim como qualquer procedimento manual, dessa forma, natural que a coleta de dados a partir de dispositivos mveis
se sobressaia como uma soluo vivel para automatizar esse processo.
Dispositivos mveis como celulares, tablets e smartphones so aparelhos cada vez mais presentes na vida das pessoas. De acordo com a Anatel, no ano de 2010 o Brasil havia ultrapassado
a marca de um celular por habitante, o que significa mais de 190 milhes de dispositivos mveis
em territrio nacional (Anatel, 2010). Com um aumento expressivo, o Brasil fechou o ano de
2012 com 261 milhes de linhas mveis (Anatel, 2013). Desse montante aproximadamente 27
milhes so os chamados smartphones (Google e MediaCT, 2012).
Um smartphone, ou celular inteligente, um pequeno computador com diversos instrumentos como sensores, cmeras, conectividade sem fio, GPS (Global Positioning System) e uma
tela sensvel ao toque. Apesar de muitos recursos, os smartphones possuem limitaes como
alimentao por bateria, memria principal e armazenamento em disco reduzidos. O Android
uma plataforma baseada no Linux desenvolvida especificamente para smartphones. O Android
um projeto open source, ou seja, possui o cdigo aberto, mantido pela Open Handset Alliance
(OHA) que formada por um grupo de grandes empresas, lideradas pela Google, interessadas
1

Captulo 1. Introduo

na evoluo dessa plataforma. De acordo com dados do final de 2012, 69,7% da parcela do
mercado pertence ao Android (Gartner Inc., 2013).
A adoo de dispositivos mveis inteligentes e o abandono do uso de formulrios impressos
na Coleta Mvel de Dados (CMD) pode gerar uma grande economia de material (pranchetas,
folhas de papis e tintas para impresso etc.), alm de importantes benefcios ambientais. Por
exemplo, o custo ambiental de uma folha de escritrio, considerando todo o processo desde
cultivo e retirada da rvore, produo de papel e eliminao de resduos, de 20,9 gramas
de emisso de dixido de carbono na atmosfera. E a cada 80 mil e 500 folhas de papis no
fabricadas uma rvore salva (Jadkowski, 2012).
Apenas a praticidade de utilizar smartphones para CMD aliada as suas vantagens econmicas e ambientais j justificariam sua implementao. Mas alm desses benefcios, eles possibilitam o uso de recursos multimdia como fotos, udio e vdeo. Tais recursos tornam muito mais
ricas tanto a interao dos usurios quanto a qualidade das informaes presentes nos formulrios digitais, pois a apresentao da informao ocorre de maneira multissensorial, estimulando
mais os sentidos humanos do que um texto comum.
O projeto Maritaca (MARitaca Is a Tool to creAte Cellular phone Applications) busca
suprir as necessidades de automatizar o processo de CMD provendo uma infraestrutura baseada
na nuvem para criao de aplicativos mveis para smartphones Android. Esses aplicativos
representam os formulrios digitais. O Maritaca proporciona uma interface web interativa para
a concepo do formulrio e o gerenciamento das informaes coletadas. O projeto possui trs
vertentes principais: a aplicao mvel Android, os servios web e os repositrios de dados.
O foco deste trabalho estudar a arquitetura do Maritaca com nfase na componente mvel
Android e colaborar com seu desenvolvimento.

1.1

Objetivos

O objetivo deste trabalho estudar a arquitetura da componente mvel Android do projeto


Maritaca, como ela interage com as outras componentes e colaborar com seu desenvolvimento
em um ambiente distribudo e open source. Tambm faz parte do escopo integrar a equipe
de desenvolvedores do projeto, assim como explorar as funcionalidades do sistema em uma
situao real. Pode-se listar os seguintes objetivos especficos:
Estudar, avaliar e testar, por meio de um estudo de caso, a arquitetura do projeto Maritaca;
Implementar os seguintes itens na componente Android:
Um tipo de questo do formulrio digital: o slider;

Captulo 1. Introduo

Um sistema de notificaes que informa ao usurio a quantidade de novas coletas


realizadas por outros usurios que compartilham o mesmo formulrio;
Uma interface na qual o usurio pode definir configuraes sobre o intervalo de
sincronizao com o servidor.
Para mais informaes sobre o projeto Maritaca acesse http://maritaca.unifesp.
br.

1.2

Organizao do Texto

Este trabalho est organizado em nove captulos. O Captulo 2 disserta sobre o histrico do
Android e esclarece os principais conceitos e caractersticas dessa plataforma e de sua mquina
virtual chamada Dalvik. O Captulo 3 compara o Maritaca com outros trabalhos com objetivos e funcionalidades similares. As ferramentas colaborativas utilizadas no desenvolvimento do
Maritaca so listadas e descritas no Captulo 4. O Captulo 5 apresenta a arquitetura aplicada no
desenvolvimento do sistema com foco no sistema mvel. O Captulo 6 expe as caractersticas
funcionais do sistema e pode ser usado como tutorial para sua utilizao. A implantao do
mdulo servidor e mvel descrita no Captulo 7. O Captulo 8 apresenta as principais contribuies para a componente mvel. O Captulo 9 apresenta um caso de uso do sistema e comenta
sobre o potencial da ferramenta e, por fim, o Captulo 10 discorre sobre as lies aprendidas,
consideraes finais e trabalhos futuros.

C APTULO

2
Android e a Mquina Virtual Dalvik

A plataforma Android (Google Inc., 2013) um sistema operacional para dispositivos celulares
com alto poder computacional, conhecidos como smartphones. A capacidade de processamento
melhorada a medida que a demanda por tal capacidade aumenta e esse crescimento tende a
aumentar ao longo dos anos. Usurios cada vez mais exigentes e aplicaes cada vez mais
complexas e sofisticadas surgiro. O objetivo dessa plataforma prover um sistema aberto, no
qual os desenvolvedores de aplicaes possam usar quaisquer recursos disponveis para cada
aparelho, inclusive os utilizados pelas aplicaes internas, aproveitando ao mximo o que eles
tm a oferecer.
Este captulo discorre sobre o histrico, arquitetura, desafios e a mquina virtual da plataforma Android.

2.1

Histrico

A Google adquiriu uma startup chamada Android Inc., em 2005, com o objetivo de entrar
no mercado de dispositivos mveis. Os principais nomes da Android Inc. eram Andy Rubin
(considerado o criador do Android), Rich Miner, Nick Sears, e Chris White (Hashimi et al.,
2009). Andy Rubin hoje vice-presidente de plataformas mveis da Google.
Em 2007, um grupo de empresas, liderado pela Google, chamado de Open Handset Alliance
foi criado para gerenciar e criar novas diretrizes para a plataforma Android. A OHA uma
4

Captulo 2. Android e a Mquina Virtual Dalvik

aliana comercial composta por muitas das maiores e bem sucedidas empresas do mundo. Seus
membros representam toda a cadeia comercial de dispositivos mveis, incluindo fabricantes de
chips, fabricantes de celulares, desenvolvedores de software e provedores de servio (Conder
e Darcey, 2012). Alm disso, objetivo da OHA garantir que o projeto tenha cdigo aberto e
assim reagir mais rapidamente e de forma inovadora as exigncias do mercado (Open Handset
Alliance, 2012).
Em novembro de 2007, foi divulgada uma verso pr-lanamento do Android SDK (Software Development Kit) e j em 2008 foi lanado o primeiro aparelho baseado na plataforma
Android, o T-Mobile G1. Poucos dias depois a verso 1.0 do Android SDK foi lanada e em
outubro de 2008 a Google tornou o cdigo fonte da plataforma Android aberto sob a licena
Apache (Hashimi et al., 2009). A partir desse momento, muitas fabricantes comearam a produzir dispositivos Android em 2009 e incio de 2010. A plataforma ganhou mercado rapidamente
e no final de 2010 o Android tornou-se lder de mercado, ganhando espao de plataformas competitivas como o BlackBerry da RIM, o iOS da Apple e o Windows Mobile (Conder e Darcey,
2012).

2.1.1

Histrico das Verses

Vrias verses do Android foram lanadas desde seu incio, agregando novos recursos e funcionalidades. Atualmente o Android encontra-se na verso 4.2 Jelly Bean. O histrico da evoluo das verses, assim como as principais mudanas e suas datas de lanamento so listadas
abaixo (Google Inc., 2012b):
1.1 - Fevereiro de 2009: Verso inicial;
1.5 (Cupcake) - Abril de 2009
Nova API, refinamentos da interface de usurio, melhorias de desempenho, atualizao
do Kernel do Linux para a verso 2.6.27.
1.6 (Donut) - Setembro de 2009
Nova API, aperfeioamento da interface de usurio, atualizao do Kernel do Linux para
a verso 2.6.29, suporte para resolues e densidades de telas, suporte para CDMA, API
para reconhecimento de gestos e uma engine de texto-para-fala.
2.0, 2.1 (clair) - Outubro de 2009
Nova API, aperfeioamento da interface de usurio, melhoria na renderizao de grficos,
bluetooth 2.1,

Captulo 2. Android e a Mquina Virtual Dalvik

2.2 (Froyo) - Maio de 2010


Nova API, aperfeioamento da interface de usurio, novo framework de mdia, novas
funcionalidades para o bluetooth, atualizao do Kernel do Linux para a verso 2.6.32.
2.3 (Gingerbread) - Dezembro de 2010
Nova API, aperfeioamento da interface de usurio, suporte para NFC (Near Field Communications), mudanas na Dalvik e atualizao do Kernel do Linux para a verso 2.6.35.
3.0, 3.1, 3.2 (Honeycomb) - Fevereiro de 2011
As melhorias das verses do Android Honeycomb so focadas em adaptaes para os
tablets. Nova API, aperfeioamento da interface de usurio.
4.0, 4.0.1, 4.0.3, 4.0.4 (Ice Cream Sandwich) - Outubro de 2011
Nova API, aperfeioamento da interface de usurio, novos recursos multimdia, novos
tipos de conectividade como o Wi-Fi Direct e Bluetooth Health Device Profile (HDP).
4.1, 4.2 (Jelly Bean) - Julho de 2012
Melhorias de segurana, otimizaes na Dalvik, evoluo do software da cmera e bluetooth, melhora no suporte ao NFC (Android Beam) e reproduo de udio com baixa
latncia.

2.2

Arquitetura

O Android composto por uma pilha de software que inclui um Sistema Operacional, Middleware e aplicaes chave (Google Inc., 2012b). A arquitetura do Android composta pelas
componentes mostradas na Figura 2.1.
Essa pilha composta por cinco camadas: Aplicaes, Framework para Aplicaes, Bibliotecas juntamente com a Android Runtime e Kernel do Linux. A camada de Aplicaes o
conjunto de todos os aplicativos instalados no dispositivo e que so escritos com uma sintaxe
similar ao do Java. Estes so todos os aplicativos nativos indispensveis (tais como navegador
de internet, cliente de correio eletrnico, aplicativo para gerenciar SMS, calendrio, contatos
etc.) e os aplicativos que o usurio pode instalar pela Google Play (Google Inc., 2012b).
Na camada Application Framework, esto todas as APIs disponibilizadas no SDK do Android para desenvolver aplicaes ricas utilizando os diversos recursos presentes nesse sistema
operacional, como:
Views: so usadas para construir a interface com o usurio (telas da aplicao);

Captulo 2. Android e a Mquina Virtual Dalvik

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


Content Providers: possibilitam que aplicaes troquem informaes entre si;
Resource Manager: permite acesso a arquivos externos como grficos, arquivos de layout
e de internacionalizao;
Notification Manager: prov a capacidade de gerar notificaes personalizadas na barra
de status;
Activity Manager: gerencia o ciclo de vida das aplicaes e o fluxo de navegao.
A camada de bibliotecas representa um conjunto de bibliotecas escritas em C e C++ que possuem funcionalidades especficas e muito usadas pela camada acima. Nessa camada encontram-se
bibliotecas para execuo de mdia altamente otimizadas para dispositivos com recursos limitados (Brahler, 2010), como codificadores e decodificadores para execuo e gravao de vdeo
(H264, MPEG4), udio (MP3, AAC, AMR) e imagens (JPEG, PNG). Inclui-se nessas bibliotecas o SQLite (SQLite Community, 2013), pacotes para renderizao 2D e 3D, entre outros (Google Inc., 2012b).
J a Runtime Android possui bibliotecas chaves do Java, alm da DVM (Dalvik Virtual
Machine) que ser mais detalhada na Seo 2.4 (Google Inc., 2012b).
Na camada de mais baixo nvel, h o Kernel Linux na verso 2.6 modificado para atuar
em aspectos fundamentais do sistema como gerenciamento do consumo de energia, memria,

Captulo 2. Android e a Mquina Virtual Dalvik

processos, rede e segurana. Alm de operar tambm como intermediria entre o hardware e as
outras camadas da pilha (Google Inc., 2012b).

2.3

Fragmentao

Um tema que gera muita discusso entre usurios e fabricantes do Android o problema de
fragmentao. O Android continua evoluindo rapidamente desde seu incio e, com isso, muitas
verses foram lanadas. Existem diversas verses deste sistema operacional instalados em diversos modelos de smartphones de diversas marcas, desde a antiga verso 1.5 lanada em abril
de 2009, tambm chamada de Cupcake, at recm-lanada verso 4.2, chamada de Jelly Bean.
A discusso se d pela incompatibilidade das verses que esto sendo efetivamente utilizadas pelos usurios, ou seja, existem dispositivos Android ativos em todas as suas verses. De
acordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as verses do
Android Gingerbread, 28,6% possuem as verses do Ice Cream Sanduich, 15,5% possuem as
verses mais recente do Jelly Bean e tambm 7,5% possuem verso 2.2 Froyo. De fato, h uma
fragmentao de verses no Android.
O grande problema da fragmentao que as verses antigas no desfrutam de todas as
novas funcionalidades das verses mais atuais, alm disso, os desenvolvedores de aplicativos
priorizam o suporte de seus produtos para as verses mais recentes. Ou seja, os usurios que
possuem smartphones com Android desatualizado no possuem acesso aos aplicativos que exigem as verses mais recentes instaladas. Por um lado existe o aspecto negativo, que a fragmentao, mas pelo outro h o aspecto positivo que a evoluo rpida e constante do sistema.

Figura 2.2: Distribuio Atual de Verses - Maro de 2013 (Google Inc., 2012b).

Captulo 2. Android e a Mquina Virtual Dalvik

Fabricantes vendem seus smartphones e tablets com determinadas verses do Android e fica
sob seu juzo a atualizao desses aparelhos quando so lanadas novas verses. Porm, desenvolver pacotes de atualizao gera despesas e geralmente apenas os aparelhos mais populares
os recebem. Note que o aparelho precisa ter poder de processamento suficiente para executar as
verses mais novas, ou seja, os aparelhos mais antigos dificilmente recebero atualizaes do
Android.

2.4

A Mquina Virtual Dalvik

Grande parte do sucesso de uma plataforma para smartphones se d pela sua capacidade de
cativar desenvolvedores de aplicativos dessa plataforma. A Google escolheu o Java para ser
a linguagem primria do Android pela grande comunidade de desenvolvedores e pela relativa
facilidade de utilizao. Apesar disso, a Dalvik no uma verdadeira plataforma Java. O Android usa uma implementao alternativa e mais limitada da biblioteca padro do Java, na qual
grande parte das bibliotecas principais do JavaSE esto presentes. Alguns dos motivos da Google decidir criar sua prpria mquina virtual no padronizada foram os problemas apresentados
pelo JavaMe, problemas burocrticos no licenciamento de novas funcionalidades do Java pelo
JSR (Java Specification Request), desempenho, segurana, entre outros (Maker, 2011).
O objetivo da plataforma Android abranger a maior quantidade possvel de dispositivos,
desde os mais antigos de baixa capacidade at os mais atuais de alta capacidade. Essa inteno
faz com que os dispositivos obsoletos imponham que a plataforma seja eficiente o suficiente
para que tais dispositivos sejam capazes de execut-la. A execuo do Android precisa suportar
condies como baixa capacidade de processamento, baixa capacidade da memria RAM, nenhum espao para swap, funcionamento bateria, diversos modelos de dispositivos e execuo
segura de aplicativos (Ehringer, 2010). Dados todos esses requisitos a DVM foi projetada para
usar o mnimo dos recursos do sistema.
Mltiplas instncias da Dalvik so executadas simultaneamente. Este fato ocorre porque
cada aplicao Android representa um processo sendo executado, o qual possui uma instncia
da DVM. Dessa maneira, os processos ficam bem isolados, criando uma forte barreira entre as
aplicaes (Maker, 2011).

2.4.1

Arquivos .dex

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

Captulo 2. Android e a Mquina Virtual Dalvik

10

.java possui uma classe pblica, uma classe esttica interna e trs classes annimas o resultado
da compilao sero 5 arquivos .class que sero lidos em tempo de execuo pela JVM (Ehringer, 2010). Apesar da linguagem de desenvolvimento do Android ser o Java, isso no acontece
da mesma forma nos dispositivos mveis.
Na plataforma Android os arquivos .class continuam sendo gerados, porm a ferramenta
chamada dx os converte para a extenso .dex (Dalvik Executable) e so esses arquivos que so
executados pela DVM. A funo da dx alm de converter otimizar o uso de memria e o
espao em disco, alocando vrios .class em apenas um .dx (Ehringer, 2010).
Os arquivos .dex otimizam espao de armazenamento contendo dados nicos, ou seja, no
h repetio de informaes. Por exemplo, se vrias classes fazem referncia a uma string
constante de caracteres, esse objeto existe apenas uma vez nos arquivos .dex e suas mltiplas
ocorrncias so apenas ponteiros para esse objeto (Brahler, 2010). As constantes como strings,
campos, variveis, classes, interfaces, e nomes de mtodos so armazenadas em pools de constantes. Um pool um conjunto de recursos inicializados e prontos para serem usados. Na
Figura 2.3 so exibidos os pools de constantes em azul. Temos que cada arquivo .class possui
seu prprio pool heterogneo de constantes que agrupa todas as constantes em um s lugar.
Em contrapartida, o arquivo .dex, que contm vrias classes, possui vrios pools de constantes
organizados e compartilhados (Ehringer, 2010).
Na Tabela 2.1 os arquivos .dex apenas com as otimizaes citadas no pargrafo anterior
possuem menor tamanho em bytes que os arquivos .jar comprimidos.
Tabela 2.1: Comparao do tamanho em bytes entre aquivos Jar e Dex (Bornstein, 2008).

Sem compresso
Compresso Jar
Arquivo Dex sem compresso

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%)

Captulo 2. Android e a Mquina Virtual Dalvik

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

11

C APTULO

3
Trabalhos Relacionados Coleta
Mvel de Dados

Existem projetos com objetivos e funcionalidades semelhantes ao do Maritaca e que tiverem


seu desenvolvimento iniciado em paralelo. Este captulo analisa esses projetos e os compara ao
Maritaca.

3.1

MIT App Inventor

O MIT App Inventor (MIT, 2013) era um projeto da Google que foi descontinuado em agosto
de 2011 e teve seu cdigo disponibilizado. O MIT (Massachusetts Institute of Technology)
com o apoio da Google criou um centro para estudo sobre tecnologias mveis, cujo objetivo
principal dar continuidade ao desenvolvimento do App Inventor para Android.
O App Inventor constri uma aplicao sem a necessidade do usurio ter conhecimento de
programao. O projeto consiste principalmente de duas aplicaes: o App Inventor Design
e o App Inventor Blocks Editor. Semelhante a tela de criao de formulrios do Maritaca, o
App Inventor Design possui uma interface intuitiva na qual os componentes so arrastveis e
o usurio os posiciona na tela da sua aplicao facilmente. O App Inventor Blocks Editor tem
a funo de associar eventos para cada componente adicionado. O App Inventor possui uma
12

Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados

13

interessante funcionalidade que permite ao usurio ver em seu dispositivo mvel a sua aplicao
sendo montada em tempo real, desde que o dispositivo esteja conectado em seu computador.
O AppInventor uma aplicao com um escopo generalista, voltado para usurios interessados em criar suas prprias aplicaes. J o Maritaca tem um escopo especfico: a Coleta Mvel
de Dados.

3.2

Nokia Data Gathering (NDG)

O Nokia Data Gathering (Nokia Corp., 2013b) um projeto de cdigo aberto desde 2010 e
tem como objetivo a automatizao da coleta mvel de dados. Funciona com a criao de
questionrios e o envio dos mesmos para os agentes de campo que acessam os formulrios
atravs de seus celulares por uma conexo sem fio. As respostas so enviadas central, que
as armazena. possvel exportar as informaes coletadas para formatos mais manejveis, tais
como planilhas.
O NDG utilizado na prtica em alguns projetos sociais. Em Manaus, no estado do Amazonas, juntamente com a Secretaria de Estado de Sade (SUSAM), o NDG foi usado para a coleta
de informaes pertinentes as famlias atingidas pela dengue, ajudando no combate doena.
Tanto o NDG quanto o Maritaca possuem escopos semelhantes. Uma diferena importante
que o NDG est disponvel apenas para a plataforma Java ME e Windows Phone, que possuem
parcelas reduzidas de mercado.

3.3

Open Data Kit (ODK)

O projeto ODK (ODK Community, 2013) possui cdigo aberto e composto por um conjunto
de ferramentas que auxiliam na criao e gerenciamento da coleta mvel de dados. Entre eles
esto: Build, Collect e Aggregate. A Build consiste de uma interface web que possibilita a criao de formulrios interativamente, inclusive com perguntas multimdia, como udio, vdeo e
imagens. A Collect uma aplicao para Android que realiza a coleta de dados nos dispositivos
mveis Android. A Aggregate gerencia as informaes coletadas atravs dos formulrios que
podem ser exportadas para formatos mais usuais, como planilhas. Outras ferramentas que so
desenvolvidas pelo ODK so o Form Uploader, Briefcase, Validate e o XLS2XFORM.
O Maritaca e o ODK possuem objetivos diferentes apesar de terem a CMD como escopo.
Enquanto o Maritaca oferece uma infraestrutura para a criao de formulrios e gereciamento
das informaes coletadas, o ODK basicamente um conjunto de APIs e padres que podem

Captulo 3. Trabalhos Relacionados Coleta Mvel de Dados

14

ser usados por outros projetos. Alguns dos projetos que usam o ODK so: FormHub, EpiSurveyor, Group Complete, KoBo Toolbox, ViewWorld, PhiCollectUm e o doForms, que ser
apresentado na prxima seo.

3.4

doForms

O doForms (doForms Inc., 2013) um projeto cuja proposta similar ao Maritaca, porm possui
cdigo proprietrio. O doForms baseado no projeto ODK, portanto ambos possuem grandes
semelhanas. A aplicao para dispositivos mveis multiplataforma permitindo dispositivos
iOS, Android e BlackBerry. possvel usar o sistema gratuitamente com algumas restries,
como cota mxima de dados de 200 MB e somente usar a aplicao mvel para um nico
dispositivo. Outra restrio que somente alguns tipos de questes podem ser usadas para
montar formulrios para usurios com contas gratuitas.
Da mesma forma que o NDG e o Maritaca, as respostas coletadas dos questionrios no
doForms so enviadas para um servidor. A partir disso, o usurio capaz de gerenciar esses
dados e enviar novos formulrios para os dispositivos dos agentes coletores.
As principais diferenas entre o doForms e o Maritaca que o primeiro se trata de uma
soluo paga e multiplataforma enquanto que o objeto de estudo deste trabalho apresenta uma
soluo aberta e exclusiva para a plataforma Android.

3.5

Consideraes Finais

Os trabalhos que mais se assemelham tanto no objetivo quanto nos servios disponibilizados
o doForms e o NDG. O doForms e o Maritaca apresentam contextos diferentes visto que
o Maritaca apresenta uma soluo aberta, enquanto que para usar o doForms com todas suas
funcionalidades necessrio custear uma taxa mensal. Apesar disso, o doForms apresenta uma
soluo multiplataforma para sua aplicao mvel, que um benefcio considervel. O NDG
aparenta ser a soluo mais madura dentre as citadas, pois possui registros de sua utilizao em
situaes significativas. Alm do caso citado na Seo 3.2, ele foi posto em prtica no Kenya e
na frica Oriental (Nokia Corp., 2013a). Como j explanado anteriormente uma desvantagem
notvel a aplicao mvel do NDG estar disponvel para plataformas pouco utilizadas.

C APTULO

4
Ferramentas e Ambiente de
Desenvolvimento Distribudo

Uma das grandes vantagens de se trabalhar em grupo a paralelizao das tarefas de um determinado projeto, pois teoricamente quanto mais mo de obra mais rpido o projeto concludo.
No entanto, no mbito de desenvolvimento de software existem algumas variveis que no
tornam essa afirmao to simples. So necessrias ferramentas para alinhar conhecimento,
documentar os cdigos fontes gerados, um repositrio online que todos tenham acesso, IDE de
desenvolvimento, controle de verso, entre outras ferramentas. As sees a seguir descrevem
as ferramentas utilizadas neste trabalho.

4.1

Eclipse

Eclipse uma IDE (Integrated Development Environment) de cdigo aberto e robusta para a plataforma Java, porm possui diversos plugins que adicionam funcionalidades para a codificao
em outras linguagens. No caso de desenvolvimento para Android, a linguagem de programao
padro possui sintaxe similar a da linguagem Java, mas so necessrias outras ferramentas e
bibliotecas da API para que seja possvel utilizar toda a capacidade do aparelho celular (Eclipse
Foundation, 2012).

15

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

4.2

16

JUnit

JUnit uma biblioteca de cdigo aberto criada por Kent Beck e Erich Gamma que visa facilitar
o processo de teste de cdigo.
O processo de teste de software parte indispensvel no desenvolvimento de qualquer aplicao porque ele que indica possveis falhas ou erros presentes no cdigo fonte. Ou seja,
a qualidade do software a ser produzido est fortemente ligada a cobertura dos testes (Neto,
Aristides V. P., 2009). O JUnit automatiza esse processo executando todos os testes escritos
pelo desenvolvedor e gerando, ao final, um relatrio intuitivo indicando quais testes passaram e
quais no passaram.

4.3

Android SDK

O Android SDK (Software Development Kit) prov as ferramentas e bibliotecas necessrias


para desenvolver, testar e depurar novas aplicaes (Google Inc., 2012b).

4.3.1

Plugin ADT

O plugin ADT (Android Development Tools) disponvel para o Eclipse, juntamente com o Android SDK d acesso ao usurio as bibliotecas de qualquer verso do Android liberada, facilitando o desenvolvimento de uma aplicao para uma verso especfica. Inclui tambm um
emulador do prprio sistema, assim possvel o desenvolvedor depurar suas aplicaes que
esto em fase de desenvolvimento, outra opo export-las para um arquivo .apk e instal-las
em um smartphone Android (Google Inc., 2012a).

4.4

Git

O Git sistema de controle de verso, ou VCS (Version Control System), utilizado neste trabalho
e tambm amplamente utilizado pelo mercado. Os VCSs funcionam armazenando um histrico
das modificaes que foram feitas em um conjunto de arquivos sendo possvel voltar da sua
verso atual para qualquer outra verso especfica nesse histrico. Alm do Git, existem outros
VCSs ainda muito utilizados atualmente como o CVS (Concurrent Version System) e o SVN
(Subversion).
Entre as principais funcionalidades do Git esto retomar arquivos para um estado especfico,
recuperar projetos inteiros para um estado especfico, comparar mudanas ao longo do tempo,

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

17

verificar e registrar as alteraes e quem foi o autor dessas mudanas, entre outras funcionalidades. Por ter toda essa flexibilidade, o Git muito popular desde os desenvolvedores de softwares
que trabalham sozinhos at as grandes corporaes (Chacon e Aljord, 2009).
O Git se enquadra no conceito de DVCS (Distributed Version Control System), que um
sistema de controle de verses distribudo. Cada desenvolvedor potencialmente tanto um hub
como um node, ou seja, todo desenvolvedor pode contribuir com seu cdigo para outros repositrios e manter um repositrio pblico no qual outros desenvolvedores podem basear seu
trabalho e comear a contribuir tambm. Essa flexibilidade do Git permite que vrias configuraes 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 cdigo aberto. Prov ferramentas para a gerncia do cdigo fonte, documentao, frum
de discusso e status do projeto. A pgina inicial do Maritaca no SourceForge mostrada na
Figura 4.1.
Atualmente, o projeto Maritaca est hospedado no SourceForge atravs do endereo https:
//sourceforge.net/projects/maritaca/ e seu cdigo fonte est disponvel para
download por meio de um repositrio Git. Ferramentas como o frum de discusso entre os
desenvolvedores muito utilizado e facilita a comunicao quando os envolvidos no projeto
no esto fisicamente no mesmo lugar. Assim como o wiki que a documentao de conceitos
j definidos, tutoriais, ambiente de desenvolvimento, entre outros.

Captulo 4. Ferramentas e Ambiente de Desenvolvimento Distribudo

Figura 4.1: Pgina inicial do Maritaca no SourceForge.

18

C APTULO

5
Arquitetura do Maritaca

O projeto Maritaca hospedado utilizando uma arquitetura de computao em nuvem, ou seja,


todo seu cdigo executado e os dados so armazenados remotamente em servidores disponveis para acesso pela Internet. Dessa maneira, as informaes geradas pelos usurios nos dispositivos mveis esto disponveis em quaisquer computador com acesso a grande rede, atravs
de um navegador (Armbrust et al., 2010). Esse tipo de soluo escalvel, ou seja, possvel
contratar ou liberar rapidamente mais servidores equilibrando a demanda de requisies e os
recursos disponveis do sistema, caso a quantidade de usurios do sistema aumente ou diminua
consideravelmente.
O Maritaca implementa um modelo de servio chamado de SaaS (Software as a Service),
que um modelo associado a aplicaes baseadas na computao em nuvem que disponibilizam seus servios ao usurio via um navegador web. O conceito deste modelo se traduz na
mudana de paradigma no mbito de comrcio e distribuio de software. No olhar de um
cliente, ao invs de comprar a licena de um software e instal-lo em seus computadores, ele
concorda em usar a aplicao que ser hospedada pela empresa que desenvolve e comercializa o
software, dando ao comprador flexibilidade para alternar fornecedores e evitar problemas com
manuteno (Dubey e Wagle, 2007).
A arquitetura do Maritaca composta por vrias componentes que possuem funes especficas e que interagem entre si. A Figura 5.1 mostra os principais elementos e suas interaes
com os usurios do sistema no ciclo de coleta e persistncia de informaes. Basicamente o
19

Captulo 5. Arquitetura do Maritaca

20

usurio cria o aplicativo que corresponde a um formulrio digital no sistema web do Maritaca e
o instala em um dispositivo mvel Android. O coletor usa a aplicao no seu dispositivo para
adquirir e enviar s informaes coletadas ao servidor do Maritaca. Os dados so salvos nos
repositrios de dados e esto disponveis para consulta ou download.
No decorrer deste captulo, sero vistas informaes sobre a arquitetura, tecnologias e metodologias usadas em todos os componentes da soluo.

Figura 5.1: Componentes do Maritaca.

5.1

Viso Geral

A arquitetura do projeto possui trs grandes pilares: sistema mvel, servidor web e as bases de
dados. A Figura 5.2 mostra de modo geral como essas componentes interagem.
A componente mobile devices representa os dispositivos mveis Android e onde este trabalho est concentrado. Trata-se de uma aplicao Android que tem como principal funcionalidade a execuo dos formulrios, que so especificados atravs de arquivos XML, gerados
no portal Maritaca. As requisies feitas da aplicao mvel para o servidor so encapsuladas
pelo framework OAuth (OAuth Community, 2013), usado para aumentar a segurana do sistema no que diz respeito a autenticao dos usurios. A componente mvel e suas interaes
sero descritas na Seo 5.2.
O desenho modular do maritaca define que as camadas de apresentao (Presentation Layer),
a camada de negcios (Business Layer), a camada de Web Services e a camada de acesso as bases de dados (Data Acess) sejam independentes e separadas. A modularidade reduz a complexidade de sistemas, facilita futuras manutenes, mudanas no cdigo e agiliza a implementao

Captulo 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 cdigo escrito para o servidor quanto o cdigo escrito para o dispositivo mvel so
cdigos Java. Mas em uma situao hipottica, o cdigo usado no servidor poderia ser escrito
em outra linguagem visto que a comunicao entre o dispositivo mvel e o servidor ocorre via
web services, o que dispensa o uso da mesma linguagem de programao. Note que se outra
linguagem de programao fosse usada, provavelmente algumas tecnologias empregadas no
sistema atual teriam de ser trocadas por outras compatveis com a linguagem escolhida.

Captulo 5. Arquitetura do Maritaca

5.1.1

22

Servidor

Os servios e funcionalidades web do sistema esto incorporados no servidor de aplicaes web


open source JBossAS (http://www.jboss.org/jbossas). Logo, o servidor agrupa as
camadas de apresentao, negcio, acesso ao banco de dados e web services.
Quando um usurio cria seu formulrio o sistema constri uma aplicao Android correspondente ao formulrio criado. O arquivo XML contendo as especificaes do formulrio
embutido dentro da aplicao. Dessa forma, cada aplicao criada corresponde a apenas um
formulrio. O usurio pode criar diversos formulrios e cada um ser uma aplicao diferente.
Os web services foram implementados usando o modelo REST (Representional State Transfer) atravs do framework RESTEasy (JBoss Community, 2013). O REST um modelo idealizado de como a internet deveria funcionar. Este modelo de interaes de aplicaes web se
tornou a base da arquitetura moderna da internet (Fielding e Taylor, 2002). Este estilo arquitetural uma abstrao do bsico do protocolo HTTP (Hypertext Transfer Protocol) e consiste
em conceitos ao invs de sintaxes e detalhes tcnicos (Schreier, 2011).
Todas as funcionalidades do sistema que envolvem envio e recebimento de mensagens de
correio eletrnico so implementadas pelo no sistema com o framework de cdigo aberto RabbitMQ (VMware Inc., 2013).
A camada de apresentao representa as telas que so apresentadas ao usurio. As pginas
de gerenciamento de formulrios foram desenvolvidas com tecnologias altamente utilizadas
e reconhecidas pelo mercado e pela comunidade de desenvolvedores como JSF (Java Server
Faces) (Oracle Corp., 2013b), Jquery (The jQuery Foundation, 2013) e HTML 5 (W3C, 2010).

5.1.2

Repositrios de Dados

So usados duas bases de dados com propsitos diferentes: o Cassandra (The Apache Software
Foundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b).
O Cassandra um sistema de banco de dados distribudo open source criado pela Apache
Software Foundation. Ele dito No-SQL, ou seja, no utiliza a predominante arquitetura relacional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciar
grandes quantidades de dados, provendo um servio com alta disponibilidade e sem pontos de
falha (Lakshman e Malik, 2010). utilizado por grandes empresas como Google, Facebook e
Amazon. O Cassandra usado no Maritaca para armazenar os dados estruturados em XML das
respostas dos formulrios.
O acesso ao banco de dados Cassandra se d pela API Hector (Hector Community, 2013).
Ela fornece bibliotecas de alto nvel para realizar diversos tipos de procedimentos na base de

Captulo 5. Arquitetura do Maritaca

23

dados que vo desde operaes bsicas de CRUD (Create, Read, Update, Delete) at controle
do pool de conexes.
O Hadoop tambm um projeto open source da Apache Software Foundation que inclui
implementaes de um sistema de arquivos distribudo, MapReduce baseado no GFS (Google
File System) e outros projetos de MapReduce (Borthakur et al., 2011). Neste projeto ele
usado para armazenar modelos de dados no estruturados, principalmente arquivos, como udio,
vdeo, imagens e executveis Android (arquivos com extenso apk).

5.2

Sistema Mvel

Depois de criar ou editar um formulrio a partir de um navegador web, o formulrio pode ser
preenchido no dispositivo mvel no qual os dados coletados sero armazenados temporariamente no banco de dados local.
O mdulo mvel no Maritaca corresponde ao aplicativo para Android e responsvel por
gerenciar e coletar as respostas dos questionrios.

5.2.1

MVC no Sistema Mvel

O Sistema Mvel do Maritaca segue o padro de projeto MVC (Model, View, Controller) que
largamente utilizado na indstria de software. Trata-se da separao clara de cada um de seus
componentes:
O Model o mdulo no qual se encontram as regras de negcio da aplicao juntamente
com suas entidades.
A View a tela de interface com o usurio. nessa componente que os dados so visualizados pelo usurio e onde ele interage com o sistema.
O Controller responsvel por intermediar os dois componentes anteriores. Ele basicamente pega os dados gerados da comunicao do usurio com a View e os entrega para o
Model processar, o mesmo ocorre no sentido inverso.
A grande vantagem desse padro de projeto tornar o sistema modular, sendo cada camada
independente da outra. Isso nos leva a facilidade de manuteno, por exemplo, se for necessria
uma mudana nos clculos de uma aplicao, o desenvolvedor precisa apenas alterar o Model.
Analogamente, se for necessria uma mudana de design na tela de visualizao, apenas l
que o desenvolvedor vai realizar a mudana (Eric Freeman, 2007).

Captulo 5. Arquitetura do Maritaca

24

No cenrio do sistema mvel, no Model que esto concentradas as regras de negcio,


ou seja, as implementaes do funcionamento de cada questo, validaes e comparaes. A
View composta pelas telas do sistema. No Android, as telas so definidas por arquivos XML
nos quais esto estabelecidos o posicionamento das componentes como texto, boto, checkbox,
entre outros. Quem implementa a ao desses componentes o Controller, que no contexto do
Android so suas Activities. A Figura 5.3 mostra como esses componentes se relacionam.

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

5.2.2 Engine
Toda a comunicao entre dispositivo mvel e servidor ocorre via web services e, sendo mais
especfico, quando essa comunicao envolve questionrios ou respostas de questionrios ela
transmite informaes que representam arquivos XML. Esses arquivos precisam ser lidos e
transformados em objetos Java que representam uma pergunta no questionrio. Ocorre o mesmo
no sentido inverso, um objeto Java que representa uma resposta transformado em um arquivo
XML e enviado ao servidor. As manipulaes dos arquivos XML so realizadas pela Engine.
Ou seja, a Engine responsvel por receber dados que descrevem um questionrio e retornar
objetos Java que so efetivamente as questes implementadas.
A Engine implementa o padro de projeto Interpreter. Este padro define que dado uma
linguagem, possvel determinar uma representao para ela por intermdio de um interpretador que usa essa representao para processar sentenas da linguagem (Gamma et al., 1994). O
conceito fundamental do Interpreter na Engine apresentar um conjunto hierrquico de classes que representa a especificao de um formulrio, que por sua vez representa a linguagem
a ser interpretada. O arquivo XML, ou a especificao de formulrios, a linguagem a ser
interpretada e a Engine o interpretador.

Captulo 5. Arquitetura do Maritaca

25

Cada tipo de questo do formulrio digital representada por uma hierarquia de classes, cuja
superclasse a classe Question. Essa superclasse possui atributos e mtodos que so comuns as
subclasses. Essa estrutura de classes pode ser vista na Figura 5.4. O responsvel por processar
o XML e gerar os objetos definidos pelas subclasses de Question o Parser.

Figura 5.4: Estrutura de Classes de Question.

Parser
A leitura de formulrios feita baseada em um conjunto de classes que representam o arquivo
XML. O formulrio em si representado pela classe Form, seus elementos so compostos pela
classe Questions e os atributos dos elementos so representados pelas classes Comparison e
Clause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework
Simple (Simple Community, 2013), que facilita a implementao e melhora a legibilidade do
cdigo. O Simple tambm auxilia na serializao dos arquivos XML de respostas dos formulrios.
O trabalho de manusear as entidades citadas acima responsabilidade das classes utilitrias
XMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes so referenciadas
na camada de negcio do sistema mvel.
As respostas dos formulrios so transmitidas da unidade mvel Android para o servidor
atravs de grandes strings de caracteres, encapsuladas em requisies HTTP, que representam
seus respectivos arquivos XML.
Comparison
Um formulrio com perguntas sequenciais nem sempre interessante para determinados conjuntos de perguntas. Essa funcionalidade passvel de ser implementada em um formulrio
digital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma pergunta anterior. Por exemplo, a pergunta: Voc ingere bebidas alcolicas? s dever aparecer

Captulo 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 formulrio de perguntas
e que pode ter as seguintes comparaes: igual, maior, maior ou igual, menor e menor ou igual.
Cada comparao representada por uma classe e todas elas estendem a classe abstrata Clause,
conforme mostra a Figura 5.5.

Figura 5.5: Estrutura de classes do Comparison.

C APTULO

6
Funcionalidades do Sistema

O Maritaca oferece ao usurio uma interface simples e intuitiva para a criao de formulrios,
gerao de aplicaes e coleta de dados. Basicamente, so necessrios trs passos para que um
ciclo de coleta de dados se complete:
1. Pelo navegador de internet, o usurio cria o questionrio. O sistema construir a aplicao
Android e o disponibilizar para download.
2. A aplicao instalada no dispositivo Android;
3. O usurio coleta as informaes e envia as respostas ao servidor.
Esse captulo detalha as funcionalidades que o sistema oferece e ao mesmo tempo um guia
para sua utilizao.

6.1

Utilizao

O endereo de acesso do Maritaca http://maritaca.unifesp.br. Para utilizar o


sistema, necessrio efetuar um cadastro simples e depois se logar, como mostra a Figura 6.1.
Caso o usurio j tenha uma conta de usurio da Google, Yahoo ou do Facebook possvel
utiliz-la atravs da tecnologia OpenID (OpenID Foundation, 2012).
27

Captulo 6. Funcionalidades do Sistema

28

Figura 6.1: Tela de login.


Aps a autenticao, o usurio levado para a pgina principal do sistema, onde so listados
todos os formulrios criados por ele e os compartilhados, conforme mostra a Figura 6.2. H um
menu com aba Groups na parte superior, o qual permite o gerenciamento de grupos de usurios.

Figura 6.2: Tela principal.

Captulo 6. Funcionalidades do Sistema

29

Ao clicar no boto New Form o usurio levado para a tela de criao de formulrios. O
painel da esquerda contm os tipos de pergunta que o usurio pode adicionar ao seu formulrio,
como uma pergunta em forma de texto, uma foto, um vdeo, uma data, localizao por GPS,
entre outras. As perguntas so componentes HTML 5 arrastveis (drag and drop), dessa forma
o usurio pode adicionar um desses itens simplesmente arrastando-o para o centro da tela. No
exemplo da Figura 6.3 o formulrio possui quatro perguntas.

Figura 6.3: Criao de formulrios.


Aps salvar o formulrio, a criao do aplicativo para Android comea automaticamente de
forma assncrona. Depois de criado, o usurio pode fazer o download do aplicativo e instal-lo
no seu dispositivo Android.
Aps a instalao, o aplicativo exige uma autenticao do usurio, da mesma forma que
quando acessado atravs do navegador. A interface principal mostrada na Figura 6.4 composta
por um menu que corresponde ao formulrio criado anteriormente. Para coletar informaes
deste formulrio basta selecionar a opo Collect.
As prximas sequncias de telas correspondem s perguntas criadas previamente na interface web do Maritaca. A Figura 6.5 ilustra as questes do formulrio criado anteriormente. As
telas de questionrio so divididas de forma que na regio superior fiquem localizados o ttulo
do formulrio, uma barra de progresso, um boto de ajuda e um boto de cancelar. O restante
da tela ocupado pela questo e sua resposta.
O usurio pode realizar quantas coletas forem necessrias para um mesmo formulrio. Depois dos dados serem coletados, o usurio pode enviar essas informaes para os servidores do
Maritaca e acess-las na sua conta via interface web.

Captulo 6. Funcionalidades do Sistema

30

Figura 6.4: Autenticao e tela principal do aplicativo mvel.

Figura 6.5: Exemplos de questes no aplicativo mvel.

6.2

Recursos do Formulrio Digital

Os questionrios podem ser criados utilizando vrios tipos de recursos. A interface web do
Maritaca disponibiliza perguntas dos seguintes tipos: texto, seleo mltipla (checkbox), numeral, data, mltipla escolha (combobox e radiobox), foto, udio, vdeo, GPS, cdigo de barras,
controle deslizante (slider) e desenho. O Maritaca est em constante desenvolvimento e existem planos para adicionar mais tipos de perguntas. Uma grande vantagem do sistema sua
arquitetura modular que facilita a adio de novas componentes. Por exemplo, todos os tipos
de questes esto agrupados em um pacote de classes independente, dessa forma, para criar um
novo tipo de questo, basta criar novas classes que representam o tipo de questo desejado.
importante salientar que necessrio estender a classe abstrata Question que define como os
mtodos devem ser implementados.
Cada questo do formulrio digital do Maritaca possui propriedades importantes que deixam
o sistema mais robusto para o uso na CMD. Cada questo pode ter seu valor padro inicial, um

Captulo 6. Funcionalidades do Sistema

31

valor mnimo e um valor mximo definidos na etapa da criao do formulrio. Tambm h a


possibilidade de tornar uma pergunta obrigatria ou mant-la opcional. Outra funcionalidade
que merece destaque a capacidade do desvio do fluxo normal da sequncia das perguntas
atravs de algumas condicionais, tais como: igual, menor, maior, menor ou igual e maior ou
igual. Ou seja, possvel ir pra alguma questo especfica do questionrio a partir da questo
atual, obviamente que a mudana da sequncia depende da resposta.
Uma propriedade til das questes o campo ajuda. Trata-se de um campo texto que complementa a descrio da questo e pode ser acessado a partir de um boto na regio superior do
aplicativo mvel.

6.3

Compartilhamento de Informaes

O nvel de compartilhamento dos formulrios e suas respostas podem ocorrer em trs graus:
privado, pblico e compartilhado. No compartilhamento privado, o formulrio s est acessvel
ao seu criador (owner). No pblico, o formulrio acessvel para todos. O nvel compartilhado
de um formulrio ocorre quando o seu criador convida outros usurios para acess-lo. Esse
nvel possui duas ramificaes:
Hierrquico: Os usurios convidados no podem acessar as respostas coletadas de outros
convidados. Apenas o criador do formulrio consegue ver todas as respostas;
Social: Ao contrrio do item anterior, tanto os usurios convidados quanto o criador
conseguem acessar todas as respostas coletadas.
A Tabela 6.1 sintetizou os tipos de permisses de acesso (leitura e escrita dos dados coletados) para o criador do formulrio e seus convidados, de acordo com o grau de compartilhamento.
Tabela 6.1: Polticas de compartilhamento de dados no Maritaca.

Formulrio
Resposta

Leitura
Escrita
Leitura
Escrita

Privado
Criador
Criador
Criador
Criador

Comp. Hierrquico
Criador e Convidados
Criador
Criador
Criador e Convidados

Comp. Social
Criador e Convidados
Criador
Criador e Convidados
Criador e Convidados

Pblico
Todos
Criador
Todos
Criador

Captulo 6. Funcionalidades do Sistema

6.4

32

Relatrios

A gerao automtica de relatrios uma funcionalidade que est em desenvolvimento, porm


no pode deixar de ser mencionada. Ela permite que a partir das informaes coletadas e das
perguntas selecionadas pelo usurio seja gerado um relatrio contendo grficos de pizza ou
barras e organizar os dados em forma de tabelas. Por enquanto os relatrios so gerados apenas
com questes de seleo mltipla como checkbox e radiobox. A Figura 6.6 exibe a tela de
criao de relatrios em que o relatrio (coluna central) contm duas questes do formulrio
(coluna da esquerda).
possvel criar e editar vrios relatrios para um mesmo formulrio. Para acess-los, basta
abrir o menu de opes do formulrio desejado, exibido na Figura 6.7, e clicar na opo Edit
Report ou View Report, na pgina principal do Maritaca.

Figura 6.6: Interface para elaborao de relatrios.

Figura 6.7: Menu de acesso aos relatrios.

C APTULO

7
Implantao do Maritaca

Este captulo destaca os passos para a implantao do sistema e configurao do ambiente de


desenvolvimento.

7.1

Ambiente de Desenvolvimento

A preparao do ambiente de desenvolvimento consiste na instalao e configurao das ferramentas e bibliotecas utilizadas no desenvolvimento de um sistema. O sistema operacional
recomendado para o desenvolvimento do Maritaca o Ubuntu verso 11.10. As ferramentas
usadas no desenvolvimento juntamente com suas pginas oficiais so listadas abaixo:
JDK (Java Development Kit) verso 6: http://www.oracle.com/technetwork/
java/javase/downloads/index.html;
Eclipse IDE para Java EE: http://www.eclipse.org/downloads/;
Plugin maven para Eclipse: http://www.eclipse.org/m2e/
Android SDK: http://developer.android.com/sdk/index.html;
Plugin ADT: http://developer.android.com/tools/sdk/eclipse-adt.
html;
33

Captulo 7. Implantao do Maritaca

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

Implantao no Servidor

Aps todos os itens da seo anterior serem instalados e devidamente configurados, necessrio
fazer o download do cdigo fonte do Maritaca que est disponvel na pgina do Maritaca no
SourceForge. O seguinte comando deve ser executado no terminal do Linux:
$ git clone git://git.code.sf.net/p/maritaca/code maritaca-code
Aps a execuo do comando, a pasta contendo o cdigo fonte estar no diretrio corrente.
O mdulo servidor divido em quatro projetos: business, persistence, web e webservices. O
mdulo mvel possui um nico projeto: o maritaca-mobile.
O arquivo de configurao configuration.properties essencial para a implantao do projeto. Ele pode ser criado em qualquer diretrio contanto que sua localizao seja fixada por
meio da varivel de ambiente MARITACA_CONFIG_PATH. Esse arquivo exibido na Tabela
7.1.
Antes de iniciar o servidor necessrio configurar o Cassandra. Primeiro deve-se subir o
servio no terminal executando o seguinte arquivo, localizado na pasta de instalao do Cassandra:
$ sudo ./bin/cassandra
Usando outro terminal preciso criar o keyspace do Maritaca, executando os seguintes
comandos:

Captulo 7. Implantao do Maritaca

35

Tabela 7.1: Arquivo de configurao 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 atravs do comando:
$ mvn clean package
Um arquivo JAR referente ao projeto ser gerado. Deve-se execut-lo atravs do comando:
$ java -jar rabbit-consumer-1.0.jar
O servidor de aplicaes Tomcat pode ser iniciado atravs de um script localizado na pasta
bin que fica no diretrio onde foi instalado o Tomcat. Dentro desta pasta, basta executar o
comando:
$ ./catalina.sh run

Captulo 7. Implantao do Maritaca

36

Aps o servidor ser inicializado a interface web do Tomcat pode ser acessada por meio do
endereo http://localhost:8080.
O prximo passo compilar o projeto servidor e gerar um arquivo WAR (Web application
ARchive) que representa a aplicao web do Maritaca a ser implantada no servidor. O projeto
compilado com a ferramenta maven, executado no terminal e na pasta server do projeto, por
meio do comando abaixo:
$ mvn clean install -Dmaven.test.skip=true
O arquivo WAR pode ser encontrado dentro da pasta target do projeto web no mdulo
servidor. esse arquivo que deve ser implantado no servidor. O maven possui plugins extras
que se instalados permitem que logo aps o projeto ser compilado, o arquivo WAR construdo
automaticamente implantado no servidor. Existem outras maneiras como utilizar a interface web
do servidor e fazer o upload do prprio arquivo WAR. Aps a implantao o mdulo servidor do
Maritaca pode ser acessado atravs do endereo http://localhost:8080/maritaca.

7.3

Aplicao Android

Se o plugin ADT e o Android SDK foram instalados corretamente, dois cones devem aparecer
no Eclipse: o Android SDK Manager e o Android Virtual Device Manager. O primeiro se trata
de um gerenciador das APIs do Android assim como algumas ferramentas. O projeto Maritaca
pode ser compilado a partir da API 7, portanto se faz necessria a instalao de uma API igual
ou superior. O Android Virtual Device Manager um gerenciador de dispositivos virtuais que
emulam um smartphone Android. Pode-se criar vrios dispositivos virtuais, cada um com sua
respectiva verso do Android e atributos como memria principal e resoluo de tela.
Se a verso do Ubuntu instalada 64 bits, ento a instalao da biblioteca ia32-libs se faz
necessria para trabalhar com o Android SDK.
O mdulo mvel do Maritaca depende de outro projeto: o ActionBarSherlock (http:
//actionbarsherlock.com/). No projeto ele est nomeado como library e est no
mesmo diretrio do maritaca-mobile. O cdigo fonte do mdulo mvel Android est dentro
da pasta maritaca-mobile. Para adicionar o projeto ao Eclipse necessrio importa-lo pelo
menu File -> Import ou clicando com o boto direito no Package Explorer -> Import conforme
mostra a Figura 7.1. Aps esse passo, surge um menu com vrios tipos de projetos. Deve-se
escolher um projeto do tipo Android como fonte. Lembre-se de importar tanto o library quanto
o maritaca-mobile.

Captulo 7. Implantao do Maritaca

37

Figura 7.1: Modos de importar projetos no Eclipse.


Aps importado, o projeto pode ser visualizado no Package Explorer. Todas as classes,
arquivos de layout, bibliotecas adicionais e arquivos de configurao podem ser acessados. Para
executar o projeto basta clicar com o boto direito no projeto e selecionar Run As -> Android
Application. O dispositivo virtual criado anteriormente ser iniciado e a aplicao instalada e
executada.

C APTULO

8
Contribuies no Cdigo

Este captulo apresenta as principais contribuies, por mim realizadas, no cdigo fonte do
sistema mvel do projeto Maritaca. Foram desenvolvidas trs funcionalidades principais: a
implementao do tipo de questo slider, um servio de notificao de novos dados enviados e
a tela de configurao ou settings. Esses trs itens cobrem campos diferentes tanto da arquitetura
do Maritaca quanto da API do Android, abrangendo tpicos como a criao de telas por arquivos
XML, consultas e inseres de dados atravs do SQLite, uso do sistema de notificao e de
alarme do Android, implementao da classe Question, entre outros.

8.1

Question Slider

O Slider no Maritaca a implementao da Seek Bar presente na API do Android. Com essa
componente possvel selecionar um valor em um intervalo (geralmente de zero a cem) movendo horizontalmente o indicador da barra. O menor valor est no limite da esquerda assim
como o maior est no limite da direta. A Figura 8.1(b) mostra a Seek Bar da API do Android e
a Figura 8.1(a) mostra o Slider do Maritaca.

38

Captulo 8. Contribuies no Cdigo

(a) Slider Maritaca.

39

(b) Seek Bar Android.

Figura 8.1: Customizao da componente Seek Bar

8.1.1

Passos da Implementao

A classe abstrata Question, mostrada no Apndice B, define quais mtodos os tipos de questes
devem implementar. Essa classe fundamental no contexto do sistema, pois todas as manipulaes que a Engine faz para criar os objetos, que correspondem as questes no formulrio,
so feitas com base nos seus mtodos. Para desenvolver o Slider foi necessrio implementar os
seguintes mtodos abstratos:
public abstract ComponentType getComponentType();
Este mtodo retorna o tipo do componente ou questo a ser implementada. ComponentType um Enum, ou seja, uma classe estruturada de tal forma que seus dados sejam
imutveis (Sierra e Bates, 2005). nessa classe que esto definidos todos os tipos de
questes com um respectivo identificador, inclusive o slider.
public abstract Object getValue();
Retorna o valor adquirido pela questo. No caso do slider retornado um valor numrico,
mas caso fosse um questo do tipo texto, este mtodo retornaria uma string de caracteres.
public abstract View getLayout(ControllerActivity activity);
Este mtodo retorna o Slider customizado. O slider montado a partir da seek bar juntamente com seu esquema de posicionamento da componente na tela. Com o slider foi
criada uma componente de texto que mostra o valor atual do slider e o atualiza caso o
usurio mude.
public abstract boolean validate();
A validao da questo feita quando o usurio avana ou retrocede no formulrio no
menu de coleta. Um tipo de validao a verificao da obrigatoriedade da resposta, ou
seja, a resposta da questo no pode ser vazia. O slider implementa este tipo de validao.
public abstract void save(View answer);
A implementao deste mtodo ocorre da mesma forma que o item anterior, porm o
mtodo salvar executado antes, pois no contexto do sistema necessrio salvar o valor
selecionado pelo usurio para poder executar a validao.

Captulo 8. Contribuies no Cdigo

8.2

40

Servio de Notificaes

Um servio no Android, representado pela classe Service, uma componente de aplicao que
tem como funo realizar operaes prolongadas que no interferem com o usurio ou prover
funcionalidades para outras aplicaes. Os servios no so processos ou threads adicionais, ou
seja, so executados no mesmo processo da aplicao a qual pertencem. A classe IntentService
estende Service e usada para lidar com tarefas assncronas, ou seja, ela cria threads para
processar o que foi requisitado e depois elimina a thread (Google Inc., 2012b).
O servio de notificaes composto por uma IntentService que faz uma requisio HTTP
para o servidor acessando um web service que retorna uma resposta que contm a quantidade de
novas coletas enviadas ao servidor, a partir de uma data, por outros coletores para o formulrio
em questo. Se houverem novas coletas a prpria IntentService lana uma notificao, como
a ilustrada na Figura 8.2. Essa funcionalidade til quando existem vrios coletores para um
mesmo formulrio.

Figura 8.2: Notificao de novos dados coletados.

8.2.1

Passos da Implementao

Criao do Servio
O servio representado pela classe NotificationService que estende IntentService. Essa classe
responsvel por criar a notificao e gerenciar a requisio e sua resposta HTTP. Caso a
resposta do web service retorne um inteiro maior que zero, uma notificao gerada indicando
o nmero de novas coletas, caso contrrio, uma notificao gerada indicando que nenhuma
coleta foi enviada ao servidor.
O NotificationService chamado assim que a tela de menu construda. Quem faz a chamada a classe AlarmManager que prov acesso a sistema de alarmes do Android e permite
agendar a execuo do servio, que feita repetidamente e em intervalos de tempo definidos

Captulo 8. Contribuies no Cdigo

41

pelo usurio. A tela de configurao, melhor detalhado na Seo 8.3, inclui opes para ligar
ou desligar o servio de notificao e determinar o intervalo de tempo que a sincronizao com
o servido realizada.
Tratamento da Requisio e Resposta
A requisio feita criando um objeto que representa uma requisio HTTP e o enviando. A
criao da requisio envolve a passagem de parmetros de dois parmetros a partir da URL:
a identificao do formulrio e a data da ltima sincronizao. Depois que a requisio foi
enviada cabe ao servidor receb-la e trat-la. O servidor usa o RESTEasy (JBoss Community,
2013) que implementa a especificao JAX-RS (Oracle Corp., 2013a) e prov uma biblioteca
para web services RESTful, facilitando seu uso.
O servidor est configurado para filtrar as requisies feitas aos web services e encaminh-las
para seu respectivo mtodo de implementao. Este mtodo faz uma busca no banco de dados
que retorna uma lista de formulrios enviados ao servidor, por outros usurios, a partir da data
recebida como parmetro. Com essa lista em mos, basta retornar seu tamanho. O resultado
encapsulado em um objeto que corresponde ao uma resposta HTTP e enviada de volta ao
NotificationService. A Figura 8.3 representa a sequncia dos eventos e chamadas do sistema de
notificaes.

Figura 8.3: Fluxograma do sistema de notificaes.

Captulo 8. Contribuies no Cdigo

8.3

42

Menu Settings

A partir do menu principal h um boto com opo de ir para tela de configuraes ou Settings.
As opes de configurao nessa tela fazem referncia a seo anterior, logo, ela contm um
boto no qual possvel ativar ou desativar a sincronizao com o servidor do sistema de notificaes. Caso esse boto for habilitado, a escolha do intervalo de tempo de sincronizao
tambm ser. A Figura 8.4 apresenta a tela com suas respectivas componentes.

Figura 8.4: Tela Settings.

8.3.1

Passos da Implementao

A criao de telas, ou interfaces de usurio, no Android ocorre pela representao de seus


componentes com seus respectivos atributos por um arquivo XML. No arquivo que representa
a interface da Figura 8.4 existem alguns componentes a serem destacados:
O Toggle Button, que alterna entre ativada e desativada a sincronizao do sistema de
notificaes;
A Seek Bar, responsvel por determinar o intervalo de sincronizao em minutos. Note
que esta componente s estar habilitada de o boto do item anterior tambm estiver;
O boto Save Settings que persiste as configuraes no banco de dados local do dispositivo mvel.

Captulo 8. Contribuies no Cdigo

43

Para armazenar as preferncias do usurio, foi necessrio criar uma tabela no banco de dados
local. Cada linha desta tabela armazena se o Toggle Button est ativado ou no, o intervalo de
sincronizao e o usurio a quem pertence essas opes.
A API do Android fornece algumas classes que facilitam a manipulao de tabelas no banco
de dados local SQLite. Para manipular os dados dessa tabela foram implementados mtodos
para insero, atualizao e consulta desses dados. A insero ocorre quando no existem dados
na tabela e o usurio pressiona o boto Save Settings. A atualizao ocorre da mesma forma,
porm somente quando existem dados na tabela. As consultas so feitas na prpria tela Settings,
no momento de sua criao, para carregar as componentes com os valores salvos anteriormente,
e tambm no AlarmManager para pegar o valor do intervalo de sincronizao.

8.4

Problemas Reportados

Os problemas encontrados no sistema podem ser adicionados na pgina de notificao de bugs


no SourceForge do Maritaca (https://sourceforge.net/p/maritaca/bug/). Os
problemas encontrados e submetidos so listados a seguir:
O aplicativo mvel no abre em verses do Android 4.0 ou superior. Esse problema
ocorre quando requisies HTTP so executadas na thread principal da aplicao, o que
pode acarretar em ANR (Application Not Responding) (Google Inc., 2012b). A pgina referente ao bug https://sourceforge.net/p/maritaca/tickets/463/;
Caso o coletor no tiver acesso internet ele no consegue coletar dados. A Seo 9.3
descreve como este problema foi encontrado. A pgina referente ao bug https://
sourceforge.net/p/maritaca/bug/53/;
Quando uma questo do tipo Picture enviada ao servidor com uma foto grande (2 MBytes) o a aplicao para de responder, gerando um aviso de ANR.

C APTULO

9
Estudo de Caso

A fim de avaliar o funcionamento do sistema em modo de produo, este captulo apresenta os


resultados da CMD usando o Maritaca em um cenrio real.

9.1

Cenrio

A Universidade Federal de So Paulo campus So Jos do Campos iniciou suas atividades em


2007 com apenas um curso, cinquenta alunos e dez docentes. Com um evoluo rpida, no
ano de 2012 possua cerca de mil alunos e oitenta docentes distribudos entre trs cursos e trs
turnos diferentes. Para atender esse pblico, o campus possui uma cantina e um restaurante
universitrio (criado em 2011), sendo que o ltimo possui parte do valor da refeio subsidiado
pela universidade. As refeies so oferecidas em dois horrios, no almoo a partir das doze
horas at s catorze horas e no jantar a partir das dezoito horas at s vinte horas.
O Maritaca foi usado nesse cenrio para coletar informaes sobre a satisfao dos usurios
do restaurante universitrio durante 15 dias.

44

Captulo 9. Estudo de Caso

9.2

45

Formulrio

As imagens da Seo 6.1 demonstram a construo da aplicao Bandejo, a mesma utilizada


nessa demonstrao. O formulrio digital composto pelos seguintes itens:
Qual o seu nome? Figura 9.1(a);
Qual o seu curso? Figura 9.1(b);
Qual a data da refeio? Figura 9.1(c);
Qual sua satisfao? Figura 9.1(d);
Foto da refeio. Figura 9.1(e).

(a) Pergunta no obrigatria do tipo (b) Pergunta obrigatria do tipo (c) Pergunta obrigatria do tipo
texto.
RadioButton com as opes BCC, data.
BCT ou BMC.

(d) Pergunta obrigatria do tipo Ra- (e) Questo no obrigatria do tipo


dioButton com as opes timo, Picture.
bom, regular, ruim.

Figura 9.1: Questes do formulrio Bandejo.

Captulo 9. Estudo de Caso

46

A representao desse formulrio pelo sistema feita por arquivos XML. O formulrio
Bandejo est especificado em um arquivo XML mostrado no Apndice A.
O formulrio foi criado com a poltica de compartilhamento hierrquico, ou seja, o criador
tem acesso total para leitura e escrita tanto das respostas como do formulrio e os convidados
tem acesso apenas a leitura do formulrio e escrita das respostas. Neste cenrio, trs coletores
diferentes participaram da aquisio dos dados e cada um possua seu respectivo dispositivo
Android. Os dispositivos, assim como suas verses do Android so listados abaixo.
Samsung Galaxy SIII, Android verso 4.1.2 Jelly Bean;
Samgung Galaxy Nexus, Android verso 4.2.2 Jelly Bean;
Samsung Galaxy 5, Android verso 2.3.3 Gingerbread;

9.3

Resultados

Na aplicao Android e no gerenciador web de formulrios possvel ver as respostas coletadas


para cada questionrio na forma de tabelas, como mostra a Figura 9.3.
Atente ao fato que no escopo deste trabalho dissertar sobre a qualidade ou opinio dos
alunos e docentes em relao ao restaurante universitrio.
O sistema Maritaca de um modo geral respondeu bem aos comandos, sua interface intuitiva e os coletores no tiveram problemas em us-la. Um ponto controverso percebido pelos
coletores que as componentes mvel e web impe ao usurio sua autenticao de hora em
hora, ou seja, depois de sessenta minutos contados a partir da autenticao, o usurio automaticamente desconectado do sistema. Esse mtodo contribui para elevar a segurana porque
dificulta que um usurio no autorizado colete informaes, porm em algumas situaes como
o dispositivo no conseguir acessar a internet por estar em uma rea sem cobertura pode obstruir
o coletor de usar o sistema.
O resultado da coleta de dados do formulrio Bandejo pode ser visualizada na Figura 9.2,
que contm um grfico gerado pelos dados da satisfao dos usurios do restaurante universitrio da Unifesp. Este grfico foi criado atravs da funcionalidade de gerao automatizada de
relatrios do sistema web.
Foram realizadas no total trinta e seis coletas, sendo que dez delas possuem contedo multimdia. A Figura 9.3 mostra algumas das respostas do formulrio Bandejo retiradas da interface
web do Maritaca. O sistema mostra os dados coletados em formato tabular e ao clicar nas imagens na coluna mais direita, outra janela surge mostrando a imagem na sua resoluo original.

Captulo 9. Estudo de Caso

Figura 9.2: Relatrio gerado a partir dos dados coletados no formulrio Bandejo.

Figura 9.3: Respostas do formulrio Bandejo incluindo arquivos de imagens.

47

C APTULO

10
Concluses

Este captulo apresenta as consideraes finais deste Trabalho de Concluso de Curso, as principais contribuies e os trabalhos futuros que podero complementar o que foi realizado.

10.1

Consideraes Finais

A automatizao da Coleta Mvel de Dados um processo positivo e a tendncia de aumentar


sua adoo alta por incorporar vantagens ambientais e econmicas. O Maritaca um dos projetos que implementam este procedimento e foi o objeto de estudo deste trabalho. Os objetivos
principais foram estudar sua arquitetura e colaborar com o desenvolvimento em um dos braos
do projeto: o mdulo Android.
A desenho modular do Maritaca um conceito bem estabelecido e muito usado pelo mercado de desenvolvimento de software. Traz vantagens claras de reusabilidade e manuteno
de cdigo. Sua arquitetura baseada na nuvem traz benefcios importantes como a alta escalabilidade e permite que o usurio acesse os servios do sistema em qualquer lugar do mundo,
independente da plataforma usada, desde que tenha acesso internet.
As funcionalidades desenvolvidas abordaram diferentes tpicos da arquitetura do Maritaca
assim como das bibliotecas do Android, fornecendo uma viso mais ampla e concreta de ambos. As principais implementaes foram o slider, o sistema de notificaes e a interface de
configurao, detalhadas no Captulo 8.
48

Captulo 10. Concluses

10.2

49

Contribuies

Este Trabalho de Concluso de Curso deixa como contribuio as experincias e lies aprendidas na participao no projeto open source Maritaca em um ambiente de desenvolvimento
distribudo. Alm de colaboraes no cdigo fonte da componente mvel Android. Este trabalho tambm pode ser til como manual e avaliao do sistema.

10.3

Trabalhos Futuros

O projeto Maritaca est numa verso estvel, mas h muitos recursos e funcionalidades existentes que podem ser melhoradas e novas que podem ser criadas, j que o campo da Coleta Mvel
de Dados bastante abrangente. Abaixo esto descritos dos objetivos futuros mais significativos:
Colaborar no desenvolvimento de outras componentes do sistema, como o servidor e
bases de dados;
Aumentar a abrangncia do sistema tornando-o multiplataforma, criando aplicaes para
Web, iOS e BlackBerryOS;
Analisar a capacidade do sistema, semelhante ao que foi feito no Captulo 9, porm inserindo quantidades maiores de informaes usando todos os tipos de perguntas do formulrio digital;

Referncias Bibliogrficas

A NATEL Brasil ultrapassa um celular por habitante, disponvel em: http://goo.gl/


BRnJh (acessado em 28/03/2013), 2010.
A NATEL Telefonia mvel fecha 2012 com 261,78 milhes de linhas, disponvel em: http:
//goo.gl/Xam8j (acessado em 29/01/2013), 2013.
A RMBRUST, M.; F OX , A.; G RIFFITH , R.; J OSEPH , A.; K ATZ , R.; KONWINSKI , A.; L EE ,
G.; PATTERSON , D.; R ABKIN , A.; S TOICA , I.; et al. A view of cloud computing. Communications of the ACM, v. 53, n. 4, p. 5058, 2010.
B ORNSTEIN , D. Dalvik vm internals. In: Google I/O Developer Conference, 2008, p. 1730.
B ORTHAKUR , D.; G RAY, J.; S ARMA , J. S.; M UTHUKKARUPPAN , K.; S PIEGELBERG , N.;
K UANG , H.; R ANGANATHAN , K.; M OLKOV, D.; M ENON , A.; R ASH , S.; S CHMIDT, R.;
A IYER , A. Apache hadoop goes realtime at facebook. In: Proceedings of the 2011 ACM
SIGMOD International Conference on Management of data, SIGMOD 11, New York, NY,
USA: ACM, 2011, p. 10711080 (SIGMOD 11, ).
Disponvel em http://doi.acm.org/10.1145/1989323.1989438
B RAHLER , S. Analysis of the android architecture. Karlsruhe institute for technology, 2010.
C HACON , S.; A LJORD , P. Pro git. Springer-verlag New York Inc, 2009.
C ONDER , S.; DARCEY, L. Android wireless application development: Android essentials,
v. 1. Addison-Wesley Professional, 2012.
DO F ORMS I NC .

Official doforms website, disponvel em: http://www.doforms.com/


(acessado em 28/03/2013), 2013.

D UBEY, A.; WAGLE , D. Delivering software as a service. The McKinsey Quarterly, v. 6,


p. 112, 2007.
E CLIPSE F OUNDATION Eclipse, disponvel em: http://www.eclipse.org (acessado
em 14/04/2012), 2012.
50

Referncias Bibliogrficas

51

E HRINGER , D. The dalvik virtual machine architecture. Techn. report (March 2010), 2010.
Disponvel em http://goo.gl/v2eIy
E RIC F REEMAN , E LISABETH F REEMAN , K. S. B. B. Head first design patterns. OReilly
Media, 2007.
F IELDING , R. T.; TAYLOR , R. N. Principled design of the modern web architecture. ACM
Trans. Internet Technol., v. 2, n. 2, p. 115150, 2002.
Disponvel em http://doi.acm.org/10.1145/514183.514185
G AMMA , E.; H ELM , R.; J OHNSON , R.; V LISSIDES , J. Design patterns: Elements of reusable
object-oriented software. Pearson Education, 1994.
Disponvel em http://books.google.com.br/books?id=6oHuKQe3TjQC
G ARTNER I NC . Gartner says worldwide mobile phone sales declined 1.7 percent in 2012.
http://goo.gl/Nxi8K (acessado em 28/03/2013), 2013.
G OOGLE ; M EDIACT, I. Nosso planeta mobile: Brasil, disponvel em: http://goo.gl/
1yfr6 (acessado em 29/01/2013), 2012.
G OOGLE I NC . Adt plugin for eclipse, disponvel em: http://developer.android.
com/sdk/eclipse-adt.html (acessado em 03/06/2012), 2012a.
G OOGLE I NC . Android developers, disponvel em: http://developer.android.
com/index.html (acessado em 06/02/2013), 2012b.
G OOGLE I NC . Official android website, disponvel em: http://www.android.com/
(acessado em 28/03/2013), 2013.
H ASHIMI , S. Y.; KOMATINENI , S.; G OYAL , V. Pro android. Apress New York, 2009.
H ECTOR C OMMUNITY
Official hector website, disponvel
hector-client.org (acessado em 29/03/2013), 2013.

em:

http://

JADKOWSKI , M. Best practices in mobile data collection, disponvel em: www.doforms.


com/support/best-practices.pdf (acessado em 04/06/2012), 2012.
JB OSS C OMMUNITY Official resteasy website, disponvel em: http://www.jboss.
org/resteasy/ (acessado em 04/04/2013), 2013.
L AKSHMAN , A.; M ALIK , P. Cassandra: a decentralized structured storage system. SIGOPS
Oper. Syst. Rev., v. 44, n. 2, p. 3540, 2010.
M AKER , F. Android dalvik virtual machine, disponvel em: http://goo.gl/7DvOD
(acessado em 20/02/2013), 2011.
MIT Official mit app inventor website, disponvel em: http://appinventor.mit.
edu/ (acessado em 28/03/2013), 2013.

Referncias Bibliogrficas

52

N ETO , A RISTIDES V. P. Criando testes com junit, disponvel em: http://goo.gl/jjDgR


(acessado em 10/06/2012), 2009.
N OKIA C ORP. Nokia data gathering in action, disponvel em: https://projects.
developer.nokia.com/ndg/wiki/projects (acessado em 29/03/2013), 2013a.
N OKIA C ORP. Official nokia data gathering website, disponvel em: https://projects.
developer.nokia.com/ndg/wiki (acessado em 28/03/2013), 2013b.
OAUTH C OMMUNITY Official oauth website, disponvel em: http://oauth.net/2/
(acessado em 04/04/2013), 2013.
ODK C OMMUNITY
Official open data kit website, disponvel em:
opendatakit.org/ (acessado em 28/03/2013), 2013.

http://

O PEN H ANDSET A LLIANCE Open handset alliance official website, disponvel em: http:
//www.openhandsetalliance.com/ (acessado em 14/04/2012), 2012.
O PEN ID F OUNDATION Official openid website, disponvel em: http://openid.net/
developers/ (acessado em 25/06/2012), 2012.
O RACLE C ORP. Official jax-rs website, disponvel em: http://jax-rs-spec.java.
net/ (acessado em 04/04/2013), 2013a.
O RACLE C ORP.
Official jsf website, disponvel em: http://www.oracle.com/
technetwork/java/javaee/javaserverfaces-139869.html (acessado em
31/03/2013), 2013b.
P RESSMAN , R. Engenharia de software. McGraw-Hill, 2006.
S CHREIER , S. Modeling restful applications. In: Proceedings of the Second International
Workshop on RESTful Design, WS-REST 11, New York, NY, USA: ACM, 2011, p. 1521
(WS-REST 11, ).
Disponvel em http://doi.acm.org/10.1145/1967428.1967434
S IERRA , K.; BATES , B. Head first java. OReilly Media, Incorporated, 2005.
S IMPLE C OMMUNITY
Official simple website, disponvel em:
sourceforge.net/ (acessado em 04/04/2013), 2013.

http://simple.

SQL ITE C OMMUNITY Official sqlite website, disponvel em: http://www.sqlite.


org/ (acessado em 04/04/2013), 2013.
S TRAUCH , C.; S ITES , U.-L. S.; K RIHA , W. Nosql databases. 2011.
Disponvel em http://www.christof-strauch.de/nosqldbs.pdf
T HE A PACHE S OFTWARE F OUNDATION Official cassandra website, disponvel em: http:
//cassandra.apache.org/ (acessado em 29/03/2013), 2013a.

Referncias Bibliogrficas

53

T HE A PACHE S OFTWARE F OUNDATION Official hadoop website, disponvel em: http:


//hadoop.apache.org/ (acessado em 29/03/2013), 2013b.
T HE J Q UERY F OUNDATION Official jquery website, disponvel em: http://jquery.
com/ (acessado em 29/03/2013), 2013.
VM WARE I NC . Official rabbitmq website, disponvel em: http://www.rabbitmq.com/
(acessado em 04/04/2013), 2013.
W3C The syntax, vocabulary and apis of html5, disponvel em: http://dev.w3.org/
html5/html-author/ (acessado em 31/03/2013), 2010.

A PNDICE

A
Especificao de Formulrio no
Arquivo XML

O arquivo XML abaixo descreve a especificao do formulrio digital Bandejo, que foi usado
no captulo 9.
<?xml version="1.0" encoding="UTF-8"?>
<form>
<title>Bandejo</title>
<questions>
<text id="0" next="1" required="false" >
<label>Qual seu nome?</label>
<help></help>
<size>100</size>
<default></default>
</text>
<radio id="1" next="2" required="true" >
<label>Qual seu curso?</label>
<help></help>
<default></default>
<option value="0" checked="false">BCC</option>
<option value="1" checked="false">BMC</option>
<option value="2" checked="false">BCT</option>
</radio>
<date id="2" next="3" required="true" >
<label>Data da refeio.</label>
<help></help>
<default></default>
<format>mm/dd/yy</format>

54

Captulo A. Especificao de Formulrio no Arquivo XML


</date>
<radio id="3" next="4" required="true" >
<label>Qual sua satisfao?</label>
<help></help>
<default></default>
<option value="0" checked="false">timo</option>
<option value="1" checked="false">Bom</option>
<option value="2" checked="false">Regular</option>
<option value="3" checked="false">Ruim</option>
</radio>
<picture id="4" next="-1" required="false" >
<label>Foto da Refeio</label>
<help></help>
</picture>
</questions>
</form>

55

A PNDICE

B
Classe Question

O arquivo Java abaixo representa a classe abstrata Question, pea importante do sistema mvel
do Maritaca. Note que algumas linhas de cdigo foram ocultadas (imports, package, getters e
setters) porque no so necessrias para compreenso de sua implementao.
/* Imports and Package (Hidden)*/
public abstract class Question implements Serializable {
private static final long serialVersionUID = 1L;
@Attribute(required = true)
protected Integer id;
@Attribute(required = false)
protected Integer next;
@Attribute(required = false)
protected Integer previous;
@Element(required = false)
protected String help;
@Element(name = "default", required = false)
protected String _default;
@Attribute(required = false)
protected Boolean required;

56

Captulo B. Classe Question


@Element
protected String label;
protected Object value;
@ElementListUnion({
@ElementList(entry = "equal", inline = true,
type = Equal.class, required = false),
@ElementList(entry = "less", inline = true,
type = Less.class, required = false),
@ElementList(entry = "greater", inline = true,
type = Greater.class, required = false),
@ElementList(entry = "lessequal", inline = true,
type = LessEqual.class, required = false),
@ElementList(entry = "greaterequal", inline = true,
type = GreaterEqual.class, required = false) })
protected List<Comparison> comparisons;
/* Abstract methods */
public abstract ComponentType getComponentType();
public abstract Object getValue();
public abstract View getLayout(ControllerActivity activity);
public abstract boolean validate();
public abstract void save(View answer);
/* Getters and Setter (Hidden)*/
}

57