Beruflich Dokumente
Kultur Dokumente
Banca Examinadora:
Aprovado em:
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
C oleta
Abstract
He
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
6
8
9
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
14
14
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
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
7
8
11
4.1
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
37
8.1
8.2
8.3
8.4
.
.
.
.
39
40
41
42
9.1
9.2
9.3
45
47
47
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Lista de Tabelas
2.1
10
6.1
31
7.1
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
viii
PNG
REST
SaaS
SDK
SMS
SQL
VCS
XML
WAR
ix
C APTULO
1
Introduo
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
Captulo 1. Introduo
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
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
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,
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);
processos, rede e segurana. Alm de operar tambm como intermediria entre o hardware e as
outras camadas da pilha (Google Inc., 2012b).
2.3
Fragmentao
Um tema que gera muita discusso entre usurios e fabricantes do Android o problema de
fragmentao. O Android continua evoluindo rapidamente desde seu incio e, com isso, muitas
verses foram lanadas. Existem diversas verses deste sistema operacional instalados em diversos modelos de smartphones de diversas marcas, desde a antiga verso 1.5 lanada em abril
de 2009, tambm chamada de Cupcake, at recm-lanada verso 4.2, chamada de Jelly Bean.
A discusso se d pela incompatibilidade das verses que esto sendo efetivamente utilizadas pelos usurios, ou seja, existem dispositivos Android ativos em todas as suas verses. De
acordo com a Figura 2.2, aproximadamente 44% dos dispositivos ativos possuem as verses do
Android Gingerbread, 28,6% possuem as verses do Ice Cream Sanduich, 15,5% possuem as
verses mais recente do Jelly Bean e tambm 7,5% possuem verso 2.2 Froyo. De fato, h uma
fragmentao de verses no Android.
O grande problema da fragmentao que as verses antigas no desfrutam de todas as
novas funcionalidades das verses mais atuais, alm disso, os desenvolvedores de aplicativos
priorizam o suporte de seus produtos para as verses mais recentes. Ou seja, os usurios que
possuem smartphones com Android desatualizado no possuem acesso aos aplicativos que exigem as verses mais recentes instaladas. Por um lado existe o aspecto negativo, que a fragmentao, mas pelo outro h o aspecto positivo que a evoluo rpida e constante do sistema.
Figura 2.2: Distribuio Atual de Verses - Maro de 2013 (Google Inc., 2012b).
Fabricantes vendem seus smartphones e tablets com determinadas verses do Android e 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
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
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%)
11
C APTULO
3
Trabalhos Relacionados Coleta
Mvel de Dados
3.1
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
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
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
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
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
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
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,
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.
18
C APTULO
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.
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
21
5.1.1
22
Servidor
5.1.2
Repositrios de Dados
So usados duas bases de dados com propsitos diferentes: o Cassandra (The Apache Software
Foundation, 2013a) e o Hadoop (The Apache Software Foundation, 2013b).
O Cassandra um sistema de banco de dados distribudo open source criado pela Apache
Software Foundation. Ele dito No-SQL, ou seja, no utiliza a predominante arquitetura relacional para banco de dados (Strauch et al., 2011). O Cassandra foi desenvolvido para gerenciar
grandes quantidades de dados, provendo um servio com alta disponibilidade e sem pontos de
falha (Lakshman e Malik, 2010). utilizado por grandes empresas como Google, Facebook e
Amazon. O Cassandra usado no Maritaca para armazenar os dados estruturados em XML das
respostas dos formulrios.
O acesso ao banco de dados Cassandra se d pela API Hector (Hector Community, 2013).
Ela fornece bibliotecas de alto nvel para realizar diversos tipos de procedimentos na base de
23
dados que vo desde operaes bsicas de CRUD (Create, Read, Update, Delete) at controle
do pool de conexes.
O Hadoop tambm um projeto open source da Apache Software Foundation que inclui
implementaes de um sistema de arquivos distribudo, MapReduce baseado no GFS (Google
File System) e outros projetos de MapReduce (Borthakur et al., 2011). Neste projeto ele
usado para armazenar modelos de dados no estruturados, principalmente arquivos, como udio,
vdeo, imagens e executveis Android (arquivos com extenso apk).
5.2
Sistema Mvel
Depois de criar ou editar um formulrio a partir de um navegador web, o formulrio pode ser
preenchido no dispositivo mvel no qual os dados coletados sero armazenados temporariamente no banco de dados local.
O mdulo mvel no Maritaca corresponde ao aplicativo para Android e responsvel por
gerenciar e coletar as respostas dos questionrios.
5.2.1
O Sistema Mvel do Maritaca segue o padro de projeto MVC (Model, View, Controller) que
largamente utilizado na indstria de software. Trata-se da separao clara de cada um de seus
componentes:
O Model o mdulo no qual se encontram as regras de negcio da aplicao juntamente
com suas entidades.
A View a tela de interface com o usurio. nessa componente que os dados so visualizados pelo usurio e onde ele interage com o sistema.
O Controller responsvel por intermediar os dois componentes anteriores. Ele basicamente pega os dados gerados da comunicao do usurio com a View e os entrega para o
Model processar, o mesmo ocorre no sentido inverso.
A grande vantagem desse padro de projeto tornar o sistema modular, sendo cada camada
independente da outra. Isso nos leva a facilidade de manuteno, por exemplo, se for necessria
uma mudana nos clculos de uma aplicao, o desenvolvedor precisa apenas alterar o Model.
Analogamente, se for necessria uma mudana de design na tela de visualizao, apenas l
que o desenvolvedor vai realizar a mudana (Eric Freeman, 2007).
24
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.
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.
Parser
A leitura de formulrios feita baseada em um conjunto de classes que representam o arquivo
XML. O formulrio em si representado pela classe Form, seus elementos so compostos pela
classe Questions e os atributos dos elementos so representados pelas classes Comparison e
Clause. A modelagem dessas classes foi feita utilizando annotations, providas pelo framework
Simple (Simple Community, 2013), que facilita a implementao e melhora a legibilidade do
cdigo. O Simple tambm auxilia na serializao dos arquivos XML de respostas dos formulrios.
O trabalho de manusear as entidades citadas acima responsabilidade das classes utilitrias
XMLFormParser, XMLAnswerParser e XMLAnswerListParser. Essas classes so referenciadas
na camada de negcio do sistema mvel.
As respostas dos formulrios so transmitidas da unidade mvel Android para o servidor
atravs de grandes strings de caracteres, encapsuladas em requisies HTTP, que representam
seus respectivos arquivos XML.
Comparison
Um formulrio com perguntas sequenciais nem sempre interessante para determinados conjuntos de perguntas. Essa funcionalidade passvel de ser implementada em um formulrio
digital e consiste de apresentar uma ou mais perguntas dependendo da resposta de uma pergunta anterior. Por exemplo, a pergunta: Voc ingere bebidas alcolicas? s dever aparecer
26
se a pergunta anterior: Qual a sua idade?, obter uma resposta dizendo que o interrogado tem
mais de 18 anos.
Essa funcionalidade est representada por um atributo no XML do formulrio de perguntas
e que pode ter as seguintes comparaes: igual, maior, maior ou igual, menor e menor ou igual.
Cada comparao representada por uma classe e todas elas estendem a classe abstrata Clause,
conforme mostra a Figura 5.5.
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
28
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.
30
6.2
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
31
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
6.4
32
Relatrios
C APTULO
7
Implantao do Maritaca
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
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:
35
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
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.
37
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
39
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.
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.
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
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.
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.
8.3.1
Passos da Implementao
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
C APTULO
9
Estudo de Caso
9.1
Cenrio
44
9.2
45
Formulrio
(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.
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
Figura 9.2: Relatrio gerado a partir dos dados coletados no formulrio Bandejo.
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
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
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://
Referncias Bibliogrficas
52
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.
Referncias Bibliogrficas
53
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
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
57