UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

CAMPUS CURITIBA
ESPECIALIZAO EM TECNOLOGIA JAVA




JULIO CESAR GONALVES







USO DA PLATAFORMA ANDROID EM UM PROTTIPO DE
APLICATIVO COLETOR DE CONSUMO DE GS NATURAL



MONOGRAFIA DE ESPECIALIZAO









CURITIBA
2011


JULIO CESAR GONALVES





USO DA PLATAFORMA ANDROID EM UM PROTTIPO DE
APLICATIVO COLETOR DE CONSUMO DE GS NATURAL



Monografia de especializao apresentada ao
curso de Especializao em Tecnologia Java da
Universidade Tecnolgica Federal do Paran
como requisito parcial para a obteno do ttulo
de especialista.

Orientador: Prof. Nelson Hideo Kashima
Co-orientador: Prof. Dr. Joo Alberto Fabro














CURITIBA
2011


AGRADECIMENTOS


A todos que direta ou indiretamente auxiliaram ou prestaram o seu apoio na
realizao deste trabalho.


RESUMO


O mercado de gs natural no Brasil acena com uma tendncia de crescimento para
os prximos anos e o segmento residencial, at ento pouco explorado se
comparado aos segmentos tradicionais de distribuio de gs natural como veicular
e industrial, promete acompanhar esta tendncia conforme apontam as expectativas
de investimento das concessionrias distribuidoras de gs natural localizadas no sul
do pas. O crescimento do consumo de gs natural nas residncias, por sua vez,
dever levar as concessionrias a terem uma forma de coletar estes valores de
consumo de uma maneira prtica e precisa. Este projeto pretende apresentar um
prottipo de um aplicativo para auxlio no trabalho, de coleta de consumo de gs
natural nas residncias. Tal aplicativo foi desenvolvido para a plataforma Android que
est disponvel numa variedade de dispositivos mveis atuais como smartphones e
tablets, e tendo como uma de suas principais caractersticas ser de cdigo aberto e
gratuito.

Palavras-chave: Android. Mobilidade. Coletor de dados. Dispositivos Mveis.



ABSTRACT


The natural gas market in Brazil has a tendency to grow in the next years and the
residential segment, until then very little explored compared to the traditional
segments of natural gas distributing as vehicular and industrial. The growth of the
natural gas consumption in residences, by the way, will make the distribution
companies look for new ways to collect these consumption values in a practical and
precise manner. This project intends to introduce a prototype of an application to aid
the work of collecting the consumption of natural gas in residences. The application
was developed for the platform Android, that is available in a variety of modern
mobile devices such as smartphones and tablets, and having as one of its main
features to be a free and open source application.

Keywords: Android. Mobility. Data collector. Mobile devices.



LISTA DE ILUSTRAES

Figura 1: Fluxograma de procedimento de natureza contnua. ................................ 14
Figura 2: Ordem de leitura em um quadro de medidores. ....................................... 15
Figura 3: Arquitetura do Android. .............................................................................. 21
Figura 4: Os componentes de uma aplicao do Android. ....................................... 23
Figura 5: Ciclo de vida de uma aplicao no Android. ............................................ 25
Figura 6: Estudo inicial das principais telas do sistema. .......................................... 31
Figura 7: Tela de criao de um projeto no Eclipse. ................................................. 34
Figura 8: Estrutura de um projeto Android no Eclipse. ............................................. 35
Figura 9: Estrutura da tabela ROTEIROS. ............................................................... 36
Figura 10: Caso de uso do aplicativo de coleta de consumo. ...................................38
Figura 11: Diagrama de seqncia do aplicativo de coleta de consumo. ................ 40
Figura 12: Tela com o menu inicial da aplicao. .................................................... 41
Figura 13: Confirmao de importao e exportao: (A) e (B). .............................. 42
Figura 14: Telas de listagens e coleta de dados: (A), (B) e (C). ............................... 43
Figura 15: Diagrama de classes. .............................................................................. 44
Figura 16: Classes do projeto na IDE Eclipse. ......................................................... 45
Figura 17: Arquivos XML do projeto na IDE Eclipse. ................................................ 45
Figura 18: Extrato de cdigo de classe que estende Activity. .................................. 46
Figura 19: Extrato de cdigo de layout descrito em XML. ....................................... 46
Figura 20: Trecho de cdigo utilizando ListView adaptada. .................................... 47
Figura 21: Trecho de cdigo para POST que retorna XML. .................................... 49
Figura 22: Trecho de cdigo para parser do XML retornado. ................................... 49
Figura 23: Trecho de cdigo de importao de roteiros. .......................................... 50
Figura 24: Trecho de cdigo para envio de XML via POST. .................................... 50
Figura 25: Trecho do contedo de AndroidManifest.xml. ......................................... 51
Figura 26: Tabela ROTEIROS na base de dados remota. ....................................... 52
Figura 27: Emulador Android SDK utilizado para validao. .................................... 53
Figura 28: Dispositivo Galaxy 5 utilizado para validao. ........................................ 53
Figura 29: Tela informando o processo de importao. ........................................... 54
Figura 30: Seqncia para validao da funcionalidade de coleta: (A), (B) e (C). . 55
Figura 31: Validao dos alertas de inconsistncia. (A), (B) e (C). .......................... 55
Figura 32: Validao da funcionalidade de coleta do consumo: (A), (B) e (C) ......... 56
Figura 33: Validao da funcionalidade de exportao. ........................................... 57
Figura 34: Base de dados remota com consumo coletado. .................................... 57







LISTA DE QUADROS

Quadro 1: Classificao dos tipos de leitura. . ......................................................... 13
Quadro 2: Detalhamento do procedimento de natureza contnua. .......................... 15
Quadro 3: Principais plataformas para dispositivos mveis. .................................... 18
Quadro 4: Mtodos do ciclo de vida de uma aplicao. . ......................................... 25
Quadro 5: Tipos de layout. . ..................................................................................... 26
Quadro 6: Opes para persistncia de dados. . ..................................................... 28
Quadro 7: Dicionrio de dados da tabela roteiros. . ................................................. 37



LISTA DE ABREVIATURAS E SIGLAS

ADT: Android Development Tools
API: Application Programming Interface
AVD: Android Virtual Device
FK: Foreign Key
HTTP: Hypertext Transfer Protocol
IDE: Integrated Development Environment
JDK: Java Development Kit
MP: Medida Provisria
OHA: Open Handset Alliance
PDA: Personal Digital Assistants
PHP: Hypertext Preprocessor
PK: Primary Key
PPB: Processo Produtivo Bsico
RDBMS: Relational Database Management System
SD: Secure Digital
SDK: Software Development Kit
USB: Universal Serial Bus
VM: Virtual Machine
XML: eXtensible Markup Language


Sumrio
1 INTRODUO ...................................................................................................... 10
1.1 Contextualizao ............................................................................................ 10
1.2 Objetivos ........................................................................................................ 11
1.2.1 Geral ....................................................................................................... 11
1.2.2 Especficos .............................................................................................. 11
1.3 Justificativa ..................................................................................................... 11
1.4 Escopo e Delimitao do Trabalho ................................................................. 12
2 REVISO BIBLIOGRFICA .................................................................................. 13
2.1 O Processo de leitura de medidores de gs .................................................. 13
2.2 Dispositivos Mveis ........................................................................................ 16
2.3 Plataformas de Desenvolvimento ................................................................... 18
2.4 O Android ....................................................................................................... 19
2.4.1 A Plataforma Android ............................................................................... 20
2.4.2 Viso Geral da Arquitetura ...................................................................... 20
2.4.3 Viso Geral do SDK ................................................................................ 22
2.4.4 Android Runtime ..................................................................................... 22
2.4.5 Estrutura das Aplicaes Android ........................................................... 23
2.4.6 Ciclo de Vida ........................................................................................... 24
2.4.7 Interface com o Usurio .......................................................................... 26
2.4.7.1 Gerenciadores de Layout ..................................................................... 26
2.4.7.2 Componentes de Interface ................................................................... 27
2.4.8 Persistncia de Dados ............................................................................ 28
3 DESENVOLVIMENTO DO PROTTIPO .............................................................. 30
3.1 Requisitos ...................................................................................................... 30
3.2 Ambiente de Desenvolvimento ....................................................................... 32
3.2.1 AVD Android Virtual Devices ................................................................ 32
3.2.2 Criao e Estrutura do Projeto ................................................................ 33
3.3 Especificao da Base de Dados ................................................................... 36
3.4 Caso de Uso .................................................................................................. 38
3.5 Diagrama de Sequncia ................................................................................. 40
3.6 Interface ......................................................................................................... 41
3.7 Implementao ............................................................................................... 44
4 VALIDAO DO PROTTIPO .............................................................................. 52
5 CONCLUSO ........................................................................................................ 58
6 CONTRIBUIES E TRABALHOS FUTUROS .................................................... 60
REFERNCIAS BIBLIOGRFICAS .......................................................................... 61
10

1 INTRODUO

1.1 Contextualizao

O mercado de gs natural no Brasil, com as descobertas do pr-sal e a
expanso da malha de gasodutos, promete ser um mercado em forte expanso nos
prximos anos [1]. Empresas distribuidoras de gs natural tiveram em sua maioria
crescimento em 2010 tanto em volume de consumo quanto em captao de novos
clientes, e a expectativa de altos investimentos para os prximos anos conforme
demonstram as distribuidoras de gs dos estados do Paran [2], Santa Catarina [3] e Rio
Grande do Sul [4], s para ficarmos na regio sul do pas. Estas concessionrias
prometem investir em um mercado pouco explorado, se comparado com os mercados de
distribuio para indstrias e veculos, que o mercado de distribuio de gs natural
para residncias.
Porm, a expanso do consumo do mercado residencial poder trazer certa
dificuldade para as distribuidoras no que diz respeito ao levantamento do gs utilizado por
cada ponto de consumo residencial, j que hoje este levantamento em sua maioria
executado atravs da anotao manual em planilhas impressas, para posteriormente
serem digitados em sistemas apropriados.
Esta sistemtica torna-se inapropriada, pois tende a ocasionar problemas como
perda ou inconsistncia dos dados devido a erros humanos ou de transcrio de leituras,
tudo isto podendo levar ao atraso ou at mesmo erro na emisso de faturas, e por
consequncia atraso e dificuldade no faturamento.
Uma forma de solucionar este problema seria lanar mo da utilizao de
dispositivos mveis para armazenar as informaes de consumo registradas nos
medidores das unidades consumidoras.
A computao mvel permite a quem a utiliza estabelecer comunicao com
outros usurios e sistemas, bem como possibilita o gerenciamento do trabalho enquanto
se movimenta, e estas so caractersticas importantes para situaes na qual as
atividades se apresentam geograficamente dispersas como o caso do trabalho de coleta
de consumo em campo.

11

1.2 Objetivos
1.2.1 Geral

Apresentar um prottipo de aplicao para dispositivos mveis, que vise auxiliar o
trabalho de campo relacionado ao processo de anotao da leitura do consumo de gs
natural em cada unidade consumidora.

1.2.2 Especficos

Criar um mecanismo que carregue informaes de um repositrio de dados
armazenado remotamente, para o dispositivo mvel, contendo o roteiro de medies a ser
efetuado no trabalho de campo.
Criar um mecanismo para armazenamento no dispositivo mvel, das
informaes referentes ao consumo de gs identificado no trabalho de campo.
Criar um mecanismo para sincronizar as informaes de medio
armazenadas no dispositivo mvel com o repositrio de dados remoto.

1.3 Justificativa

Boa parte das distribuidoras de gs natural tem como modelo atual de coleta
de informao de medidores, a utilizao de planilhas impressas que recebem anotaes
manuais da pessoa que efetua a leitura. Posteriormente estas informaes so
transferidas atravs de digitao em um sistema especfico.
Tendo em vista que o mercado de consumo residencial tende a crescer, este
tipo de soluo acabar se tornando invivel, pois alm da morosidade e re-trabalho,
um processo no qual podem surgir falhas e inconsistncias entre os dados anotados e os
dados digitados.
Com o processo de automao da medio atravs da coleta dos dados via
dispositivo mvel, estas falhas tendem a ser minimizadas, alm do que proporciona uma
maior agilidade na forma de levantamento e disponibilidade dos dados de medio de
consumo para o processo de faturamento.

12

1.4 Escopo e Delimitao do Trabalho

No universo do desenvolvimento para dispositivos mveis existem diferentes
categorias de dispositivos como Smartphones, PDAs e Tablets.
Existe tambm uma variada disponibilidade de plataformas de desenvolvimento
para estes dispositivos, dentre as quais podemos citar Android, iOS, Symbiam, webOS
entre outras.
O fato do escopo deste projeto focar no desenvolvimento de um prottipo para
funcionar em um dispositivo especfico (Smartphone) baseado em uma plataforma
especfica (Android) constitui-se em uma das restries deste trabalho.
Outra restrio relacionada ao fato de que o prottipo resultante deste
trabalho no pretende ser um aplicativo de software completo, a pretenso que este
seja utilizado como um estudo de caso para projeto e melhorias subsequentes que sero
descritas como trabalhos futuros.


13

2 REVISO BIBLIOGRFICA

2.1 O Processo de leitura de medidores de gs

O processo de medio de consumo de gs natural corresponde a coletar e
disponibilizar os dados referentes ao registro de consumo e inspecionar visualmente o
local de instalao dos medidores procedendo com as devidas anotaes de
anormalidades.
O quadro 1 demonstra quais so os tipos de leitura existentes bem como o
que caracteriza cada tipo de leitura.

Tipo Descrio
Leitura Real Efetuada atravs da obteno dos nmeros inteiros indicados no
visor do medidor, na primeira coleta de dados, conforme calendrio
de leitura.
Leitura pela Mdia Definida quando no existe possibilidade de coleta da leitura real no
medidor. indicada pelos cdigos de impossibilidade de leitura.
Leitura em aberto Leitura no realizada no dia estipulado. Dever ser realizada na
nova data determinada pela empresa.
Releitura Segunda leitura efetuada aps a leitura real ou impossibilidade de
leitura devendo ser anterior ao prximo dia de medio previsto no
calendrio.
Validao da leitura a anlise crtica das leituras coletadas em campo que se
enquadram fora do perfil de consumo do usurio. Na validao so
analisados, por usurio: dados cadastrais, servios emitidos, perfil
de consumo, condies de acesso, de instalao do medidor,
cumprimento dos procedimentos de medio, possveis erros de
leitura, anormalidades e ocorrncias.
Quadro 1 Classificao dos Tipos de Leitura



14

O processo de leitura dividido em procedimentos de natureza contnua e pr-
determinada, conforme suas definies a seguir:

a) Procedimentos de natureza contnua so executados a partir de entrada ou
excluso de um cliente ou mediante ajustes dos recursos necessrios para a execuo da
medio a qualquer momento. Objetiva a criao do calendrio de leitura juntamente com
os ciclos de consumo, grupos, rota, roteiros e medidores, disponibilizando os dados
necessrios para a execuo da medio;

b) Procedimentos de natureza pr-determinada so aquelas realizadas em uma
data determinada com incio e trmino estipulados, visando obter os dados da medio.

A figura 1 demonstra o fluxograma dos procedimentos de natureza contnua que
tem o propsito de delinear o processo de estruturao do roteiro.



Figura 1: Fluxograma de Procedimento de Natureza Contnua





15

O quadro 2 exibe o detalhamento de cada etapa identificada no fluxo de
procedimento de natureza contnua.

Etapa Detalhamento do procedimento
Etapa
anterior
1
O calendrio de leituras deve ser estruturado em uma planilha
eletrnica ou sistema informatizado devido complexidade de
informaes de datas de leitura (dias teis) e dias de consumo (entre
27 e 33)
Incio
2
Os grupos de leitura em ordem crescente devem ficar prximos uns
dos outros, no mapa eletrnico.
1
3
A rota definida em funo da quantidade e proximidade ou da
quantidade, tempo de execuo e percurso total do roteiro.
2
4
O roteiro a ordem de leitura. Os medidores devem ser lidos de cima
para baixo, da esquerda para a direita. Em um mesmo nvel as
leituras devem ser efetuadas no sentido horrio (da esquerda para a
direita), conforme demonstra a figura 2.
3
Quadro 2 Detalhamento do Procedimento de Natureza Contnua.



Figura 2: Ordem de Leitura em um Quadro de Medidores.


16

2.2 Dispositivos Mveis

A constante e cada vez maior necessidade das pessoas contarem com o acesso a
informaes pessoais e corporativas, independente do momento ou local no qual se
encontra, fez com que a indstria de tecnologia computacional trabalhasse cada vez mais
no sentido de prover equipamentos que viessem de encontro a esta necessidade. Estes
equipamentos, classificados como dispositivos de computao mvel, j foram encarados
como simples agendas eletrnicas ou assistentes pessoais (PDA, Personal Digital
Assistants), porm, hoje j fazem parte do cotidiano da maioria das pessoas permitindo a
estas a possibilidade de deslocamento em conjunto com o seu ambiente computacional,
proporcionando assim uma forma rpida e eficiente de permanecer em contato constante
com suas fontes de informao.
Temos diversas categorias de dispositivos que podemos considerar de computao
mvel [5], os quais podem ser divididos nos seguintes grupos:
O primeiro grupo o dos laptops (notebooks e netbooks), que so dispositivos
portteis com capacidade semelhante aos computadores pessoais (desktops).
No segundo grupo encontram-se os aparelhos PDA, que podem possuir aplicativos
desenvolvidos por linguagens de alto nvel, capacidade de reproduzir recursos multimdia,
fornecer acesso a redes, etc. Apresentam um poder de processamento geralmente menor
do que os laptops, porem superior ao desempenho dos celulares.
Os celulares pertencem a um terceiro grupo de dispositivos que possuem poder de
processamento reduzido, porm com recursos que vo desde o acesso rede Bluetooh,
quanto ao suporte a executar aplicativos desenvolvidos em linguagem Java.
Num quarto grupo podemos classificar dois tipos que comeam a despontar no
mercado de dispositivos mveis, os smartphones que possuem os recursos do celular
incorporando muitos recursos dos aparelhos PDA, e os tablets que so dispositivos com
telas sensveis ao toque e com recursos e sistemas operacionais semelhantes aos
laptops.
A popularidade em conjunto com a disponibilidade de ofertas e planos de acesso
proporcionados pelas empresas de telefonia torna o celular o dispositivo mvel com
acesso a recursos de Internet mais utilizados hoje. Porm, com a entrada do mundo
corporativo cada vez mais demandando solues para computao mvel, os
smartphones aparecem tambm como grande opo.
Os tablets ainda se encontram em uma fase inicial de utilizao tanto pelo mercado
17

corporativo, quanto pela populao em geral, em muitos casos por conta do custo do
dispositivo que ainda bastante alto comparado a um celular ou at mesmo a um
smartphone de configurao popular.
Porm, a inteno do Governo Federal [20] de incluir neste ano os tablets no
Processo Produtivo Bsico (PPB), que possibilita a desonerao do equipamento atravs
da reduo de impostos sobre o produto, bem como a proposta de incluso dos mesmos
na MP do Bem [21] que d incentivos tributrios para fabricao e venda de
equipamentos eletrnicos visando incluso digital, poder fazer com que o custo destes
dispositivos caia consideravelmente, o tornando tambm um dispositivo mvel popular.
Diversas plataformas e linguagens de programao podem ser utilizadas para
criao e execuo de aplicativos para dispositivos mveis, dependendo do fabricante
pode haver at mais de uma linguagem disponvel para desenvolvimento no mesmo
dispositivo, de acordo com o suporte disponvel no hardware.
Alm disto, o desenvolvimento para dispositivos mveis ainda requer certa ateno
a aspectos relativos a limitaes destes dispositivos como, por exemplo, o tamanho
reduzido da tela, e recursos de memria e processamento reduzidos.
18


2.3 Plataformas de Desenvolvimento

So diversas as plataformas e linguagens disponveis para a criao de aplicativos
mveis cada qual com a sua peculiaridade. O quadro 3 exibe as principais plataformas na
atualidade.

Android Blackbarry iOS LiMo




Mantenedora Google / OHA RIM Apple LiMo Foudation
Kernel Linux BlackBerry OS Mac OSX Linux
Desenvolvimento
Java, C, C++,
JavaScript
JavaME,
BB API
Objective C C, C++
SDK Sim Sim Sim No
Cdigo Aberto Sim No No Para membros
Loja de Aplicativos Oficial Android Market App World App Store No disponvel
N de apps (aproximado) 206 mil 27 mil 333 mil ---
Fabricante de Aparelhos Diversos RIM Apple Diversos

MeeGo Symbian WebOS WinPhone



Mantenedora Nokia Nokia HP Microsoft
Kernel Linux EPOC Linux Windows
Desenvolvimento
Qt, C++ C++, Qt, Python
Ruby, .NET
C++,
JavaScript
C#
SDK Sim Sim Sim Sim
Cdigo Aberto Sim Sim Parcial No
Loja de Aplicativos Oficial OVI OVI Palm App Market Place
N de apps (aproximado) No disponvel 30 mil 6 mil 7 mil
Fabricante de Aparelhos Intel, Nokia Diversos, Nokia Palm/HP Diversos
Quadro 3 - Principais plataformas para dispositivos mveis (adaptado de [18])

Os sistemas operacionais mveis esto presentes na maioria dos dispositivos que
utilizamos no dia a dia, sejam eles aparelhos celulares, smartphones, tablets, GPS e at
mesmo nosso carro.

19

Atualmente as atenes esto muito voltadas para o Android, que segundo
pesquisas realizadas pelo instituto Nielsen [6], pela primeira vez superou o iPhone no
mercado americano na preferncia dos consumidores. O estudo mostra que 31% dos
americanos demonstraram interesse em dispositivos baseados em Android contra 30%
que sejam baseados no iOs, sendo que o BlackBerry ocupa a terceira posio com 22%
das escolhas. O estudo mostra ainda aspectos interessantes, como o WindowsPhone que
permanece estagnado desde o seu lanamento com 6% das intenes de utilizao e
tambm o Symbian, que outrora j foi lder de mercado, hoje no aparece nem com 1%
do interesse.
Esta tendncia de preferncia ao Android tambm j foi apontada pelo Instituto
Gaertner [7] no incio deste ano de 2011. Para o Instituo o Android - at o final de 2012 -
dominaria quase metade do mercado representando 49% dos dispositivos vendidos ao
redor do mundo.
Baseado nestas pesquisas possvel identificar o quanto promissor o mercado
de desenvolvimento de aplicativos para a plataforma Android, e este foi um dos motivos
da escolha desta plataforma para o desenvolvimento do prottipo que ser demonstrado
neste trabalho. Outros motivos no menos importantes foram:
- uma plataforma open source, baseada em um ncleo robusto como o Linux.
- O desenvolvimento baseado em Java que conta com uma grande comunidade
de desenvolvedores, e possui documentao de acesso livre.
- Est disponvel em uma vasta quantidade de marcas e modelos de dispositivos
mveis, com vrias opes de preos, podendo com um custo relativamente baixo
ter acesso a um dispositivo para teste real da aplicao, sem ficar dependente
apenas de emuladores.

2.4 O Android

O Android foi um projeto inicialmente desenvolvido por uma startup americana do
Vale do Silcio chamada Android Inc. Esta pequena empresa foi adquirida pelo Google no
ano de 2005, que por sua vez tratou de amadurecer o projeto e o tornou pblico em
meados de 2007 com o objetivo de apresentar a primeira plataforma open source de
desenvolvimento para dispositivos mveis. Atualmente o Android mantido por um grupo
denominado Open Handset Alliance (OHA), que formado por mais de 40 empresas das
20

quais figuram o prprio Google e outras de importncia nos ramos de telefonia
(Telefnica), fabricao de semicondutores (Intel) e fabricao de celulares (Motorola),
dentre outras.

2.4.1 A Plataforma Android

O Android uma plataforma para desenvolvimento de aplicativos voltados para
funcionar em dispositivos mveis baseados em um ncleo de Linux, sendo que as
aplicaes a serem geradas so escritas em linguagem Java. Estas aplicaes so
compiladas em bytecodes Dalvik e executadas em uma mquina virtual desenvolvida
especialmente para utilizao em dispositivos mveis denominada Mquina Virtual Dalvik.
Disponibiliza um kit de desenvolvimento denominado Android SDK que proporciona
as APIs e ferramentas necessrias para o desenvolvimento de aplicaes, tendo como
principais recursos:
Application framework que proporciona a reutilizao de componentes;
Dalvik virtual machine que otimizada para dispositivos mveis;
Um browser integrado baseado no webkit engine;
Grficos otimizados atravs de utilizao de bibliotecas 2D; e 3D baseada na
especificao OpenGL ES 1.0 (acelerao de hardware opcional).
SQLite para armazenamento de banco de dados estruturados;
Suporte multimdia para udio, vdeo e formatos de imagem (MPEG4, H.264,
MP3, AAC, AMR, JPG, PNG, GIF);
Ambiente para de desenvolvimento rico, apresentando emulador de dispositivo,
ferramentas de depurao, memria, desempenho e um plugin para o Eclipse
(ADT).
Os seguintes recursos tambm esto presentes, porm dependentes de hardware:
telefonia GSM, Bluetooth, EDGE, 3G, WiFi, cmera, GPS, compasso, e acelermetro.

2.4.2 Viso Geral da Arquitetura

Android uma plataforma que apresenta desde sistema operacional, at
middleware e aplicativos, conforme pode ser observado na figura 3. Sua arquitetura
21

dividida em diversas camadas as quais so: ncleo do sistema operacional, bibliotecas,
runtime, framework e aplicativos.


Figura 3 - Arquitetura do Android [15]

Na camada do ncleo (Linux Kernel), baseada em Linux, localiza-se o sistema
operacional da plataforma, responsvel por servios denominados de baixo nvel como
gerenciamento de processos, gerenciamento de memria, segurana, etc.
Na camada de bibliotecas (Libraries), ficam as APIs desenvolvidas em C/C++ e que
do suporte dentre outros recursos renderizao 3D (OpenGL ES), gerenciamento de
base de dados (SQLite) e suporte aos diversos formatos de vdeo e udio.
Na camada de runtime (Android Runtime), encontram-se componentes como as
core libraries, que disponibilizam a API Java necessria para a escrita do cdigo de
programao das aplicaes, bem como a Dalvik Virtual Machine, que a mquina virtual
que dar condies para que a aplicao Java desenvolvida possa ser executada.
Na camada de framework (Application Framework), esto localizadas as APIs que
sero utilizadas pelas aplicaes que executam sobre a plataforma do Android, como por
exemplo, os gerenciadores de telefonia, localizao e notificao.
Na camada restante, as de aplicativos (Applications), estaro representadas as
aplicaes que so executadas sobre a plataforma, sejam elas nativas como o caso da
22

calculadora, do gerenciador de contatos, do calendrio, etc., ou aplicaes desenvolvidas
por terceiros como o caso do prottipo que ser desenvolvido neste trabalho. Para a
camada de aplicativos, no existe diferena entre aplicaes nativas e aplicaes de
terceiros, todas so escritas com as mesmas APIs e executadas no mesmo runtime,
inclusive tendo a possibilidade da troca de uma aplicao nativa por outra que tenha a
mesma finalidade e seja desenvolvida por um terceiro ou pelo prprio usurio.

2.4.3 Viso Geral do SDK

O kit de desenvolvimento para Android (Android SDK) est disponvel para
Windows, Linux e MacOS, provendo ao desenvolvedor um conjunto rico de ferramentas
que inclui um depurador, bibliotecas, emulador de smartphone, documentao, cdigo de
exemplo e tutoriais.

2.4.4 Android Runtime

O mecanismo de runtime do Android baseado em dois grupos fundamentais que
so as suas bibliotecas centrais e sua mquina virtual criada para que cada dispositivo
mvel possa executar mltiplas VM.
Cada aplicao desenvolvida em Android executa em um nico processo o qual
uma instncia desta mquina virtual, executando arquivos no formato .dex (abreviao
de Dalvik Executable), formato otimizado para carregamento rpido e com consumo
mnimo de memria.
A VM Dalvik executa classes compiladas em linguagem Java, porm transformadas
no formato .dex, usando ainda o kernel do Linux para aumentar as suas funcionalidades
como o uso de threads e gesto de memria de baixo nvel.





23

2.4.5 Estrutura das Aplicaes Android

Aplicaes desenvolvidas em Android so baseadas em uma arquitetura de
componentes chave demonstrada pela figura 4, porm, no necessariamente uma
aplicao deve obrigatoriamente utilizar-se de todos estes componentes, no geral as
aplicaes so compostas por uma combinao destes.
Em conjunto com estes componentes existe um arquivo XML denominado
AndroidManifest.xml de existncia obrigatria, e no qual so feitas configuraes gerais
da aplicao e dos componentes utilizados por ela. Juntam-se a esta estrutura dois outros
itens importantes que fazem estes quatro componentes chave funcionarem que so as
Intents e as Views.


Figuras 4 Os componentes de uma aplicao Android [17]

Activities formam a base para o desenvolvimento visual de uma aplicao, sendo
o componente mais comum em uma aplicao. Uma activity quem realiza os
tratamentos dos eventos da tela e que define qual view ser desenhada na tela [9]. Para
uma aplicao que possua mltiplas telas, cada tela dever ser representada por uma
activity que implementada como uma subclasse de Activity.
Services so cdigos executados em segundo plano e que no apresentam uma
interface visual. Cada service executado na thread principal do processo que o criou,
no causando bloqueio ou interferncia em outros componentes. Cada servio uma
classe que herda de Service.
Broadcast Receivers so componentes receptores de ocorrncias de eventos do
sistema e que reagem a estes eventos. Cada receiver uma classe que herda de
BroadCastReceiver.
Content Providers so componentes que tornam um conjunto especfico de dados
24

da aplicao disponvel para outras aplicaes. Cada provider uma classe que herda de
ContentProvider e disponibiliza um conjunto padro de mtodos para que outras
aplicaes possam recuperar e armazenar dados do tipo que o provedor controla.
Intents so mensagens responsveis por ativar os componentes Service, Activity e
BroadcastReceiver de uma aplicao. Essas mensagens so utilizadas para facilitar a
ligao entre os componentes da aplicao ou de aplicaes diferentes, em tempo de
execuo.
Views so elementos utilizados para definir objetos grficos exibidos na tela, com o
objetivo de prover interao com o usurio. Exemplo destes elementos so botes, caixas
de dilogo, mapas entre outros.
AndroidManifest.xml o arquivo de manifesto escrito em XML, obrigatrio e nico
para a aplicao. Nele so descritos os componentes que fazem parte da aplicao,
definidos nomes para as activities, o modo de orientao da tela, bem como declaradas
permisses para acesso a recursos como o GPS ou Internet. Este arquivo lista tambm as
bibliotecas que a aplicao vai usar e qual activity principal ir iniciar a aplicao.

2.4.6 Ciclo de Vida

O ciclo de vida de uma aplicao no Android representado pelos seguintes
estados [9]: em execuo, temporariamente interrompida em segundo plano ou
completamente destruda.
Deve-se ter como entendimento o termo ciclo de vida como algo que tem incio,
meio e fim, sendo que a documentao do Android indica a existncia de trs subnveis
do ciclo de vida, que por sua vez ficam se repetindo durante a execuo de uma
aplicao, so eles:
Entire lifetime, que representa um ciclo de vida completo entre o incio e a
destruio da activity da aplicao.
Visible lifetime, no qual a activity da aplicao est iniciada podendo estar no topo
da pilha interagindo com o usurio, ou temporariamente parada em segundo plano.
Foreground lifetime, no qual a activity da aplicao est no topo da pilha e
interagindo com o usurio.


25

A figura 5 demonstra o ciclo de vida completo de uma activity da aplicao,
exibindo os estados possveis e a chamada de cada mtodo.

Figura 5 Ciclo de Vida de uma Aplicao no Android [16]

Cada um destes ciclos se inicia durante a chamada de um dos mtodos
controladores e termina quando algum outro mtodo chamado. O quadro 4 exibe as
descries de cada um destes mtodos.

Mtodo Descrio
onCreate( bundle ) Mtodo obrigatrio e invocado uma nica vez, neste momento cria-se a view
e invoca-se o mtodo setContentView(view) para que seja exibida a tela
representada pela view. Depois de finalizado, o mtodo onStart( ) chamado
para que se d incio ao ciclo de vida visvel da activity.
onRestart( ) Mtodo chamado quando a activity est ficando visvel ao usurio,
dependendo do estado da aplicao pode ser chamado depois do mtodo
onCreate( ) ou onRestart( ).
onStart( ) Mtodo chamado quando uma activity est parada temporariamente e em
processo de reincio, de forma automtica chama o mtodo onStart( ).
26

onResume( ) Mtodo chamado quando a activity comea a interagir com o usurio,
representa o estado de execuo da aplicao. chamado sempre depois do
mtodo onStart( ).
onPause( ) Mtodo chamado quando algum evento ocorrer com o dispositivo e que faa
com que a activity encontrada no topo da pilha tenha de ser temporariamente
interrompida. normalmente utilizado para gravar dados no salvos at o
momento, para que tudo possa ser recuperado, se necessrio, no mtodo
onResume( ).
onStop( ) Mtodo chamado quando a activity est sendo encerrada, e no est mais
visvel ao usurio. Se a activity for reiniciada, o mtodo onRestart( )
chamado ou no caso de ficar muito tempo parada o Android pode chamar
automaticamente o mtodo onDestroy( ) para remover completamente a
activity da pilha.
onDestroy( ) Mtodo que literalmente encerra a execuo de uma activity, sendo feita aps
sua execuo, remoo completa da aplicao da pilha e o encerramento
completo do processo.
Quadro 4 Mtodos do ciclo de vida de uma aplicao

2.4.7 Interface com o Usurio

A classe android.view.View a classe me de todos os componentes visuais e
suas subclasses iro compor uma interface com o usurio no Android. Estas subclasses
implementam o mtodo onDraw(Canvas), responsvel por desenhar os componentes na
tela. Estes componentes dividem-se em dois grupos, os widgets e os gerenciadores de
layout. O primeiro um componente simples que herda diretamente da classe View, como
exemplos temos as classes Button, ImageView e TextView, j os gerenciadores de layout
so subclasses de android.view.ViewGroup.


2.4.7.1 Gerenciadores de Layout

Um gerenciador de layout organiza a disposio dos componentes na tela, as
possibilidades de layout so classificadas nos seguintes tipos:

Tipo Descrio
AbsoluteLayout Permite posicionar os componentes, fornecendo as
coordenadas x e y.
27

FrameLayout Tipo mais comum e simples de layout, utilizado por
um componente que precisa preencher a tela
inteira.
LinearLayout Utilizado para organizar os componentes na vertical
ou horizontal.
TableLayout uma herana de LinearLayout e pode ser
utilizado para organizar os componentes em uma
tabela, com linhas e colunas.
RelativeLayout Permite posicionar um componente relativo a outro,
por exemplo, abaixo, acima ou ao lado de um
componente j existente.
Quadro 5 Tipos de layout

2.4.7.2 Componentes de Interface

Como em qualquer outra aplicao, no Android tambm necessrio trabalhar com
componentes para compor uma interface com o usurio. As interfaces de aplicaes
Android so constitudas de componentes grficos denominados widgets e que so
subclasses da classe View. Existe uma ampla variedade destes componentes disponveis
na plataforma Android, sendo que os bsicos so:

TextView - representa a primeira e mais simples das subclasses de View e
representa um texto ou rtulo na tela.
EditText - subclasse de TextView, utilizada para que o usurio possa digitar
informaes em um campo de texto.
Button e ImageButton - componentes utilizados para criar um boto na tela,
sendo que no caso de ImageButton pode-se usar uma imagem para desenhar o boto.
RadioButton componente que permite ao usurio selecionar apenas uma nica
opo de uma determinada lista.
CheckBox componente que permite ao usurio selecionar uma ou mais opes
de uma determinada lista.
ListView componente que permite exibir uma lista de contedos.

28

2.4.8 Persistncia de Dados

O Android fornece diversas opes para persistir dados [8] em uma aplicao, e a
escolha de qual opo seguir depende da caracterstica de cada aplicao com relao
aos dados. Deve-se levar em considerao se estes devem ser de acesso privado
aplicao, ou se podem ser acessados por outras aplicaes, ou por consequncia por
outros usurios, e tambm de quanto espao ser necessrio para manter os dados.
O quadro 6 mostra as opes para persistncia de dados:

Tipo Caracterstica
Internal Storage Armazenamento de dados privados na memria do dispositivo
External Storage Armazenamento de dados pblicos no carto de memria
Network Connection Armazena dados na web no seu servidor de rede.
Shared Preferences Armazenamento de dados primitivos provados em pares chave-valor
SQLite Databases Armazenamento de dados estruturados num banco de dados privado
Quadro 6 Opes para persistncia de dados.

Internal Storage representa o armazenamento diretamente na memria interna do
dispositivo, sendo que os dados armazenados desta forma por padro so privados
apenas aplicao que os gravou, portanto outras aplicaes no podero ter acesso a
eles. A remoo dos dados feita quando o usurio desinstala a aplicao.

External Storage pode ser utilizada nas ocasies em que o dispositivo suporta o
uso de memrias externas como um carto do tipo SD ou uma memria interna no
removvel. Os arquivos armazenados desta forma podero ser lidos por qualquer outra
aplicao ou dispositivo, podendo tambm ser modificados pelo usurio quando da
transferncia USB do dispositivo para outro computador.
Um cuidado que deve ser observado neste caso que arquivos armazenados
nesta forma podem ser perdidos se o usurio montar a mdia em um computador ou
remover o carto, no existindo medidas de segurana para salvaguardar este tipo de
perda, pois todas as aplicaes podem ler e escrever arquivos em memria externa e o
usurio pode remov-los.

29

Network Connection pode ser utilizada quando h uma rede disponvel para
armazenar os dados dos servios baseados em web, sendo que para usar este tipo de
operao deve-se utilizar classes localizadas nos pacotes java.net e android.net.

Utilizando Shared Preferences pode-se persistir dados atravs da utilizao de um
framework geral que permite salvar e recuperar pares de chaves-valor de tipos de dados
primitivos como booleans, floats, ints, longs, e strings, sendo que estes dados sero
persistentes entre sesses, mesmo que a aplicao seja encerrada.

SQLite Databases possibilita a persistncia de dados estruturados atravs de um
motor de banco de dados leve e simples. Cada aplicao pode criar um ou mais banco de
dados, sendo visveis apenas aplicao que os criou.




30

3 DESENVOLVIMENTO DO PROTTIPO

3.1 Requisitos

O prottipo da aplicao foi desenvolvido para funcionar em smartphones com
plataforma Android, sendo capaz de listar roteiro pr-cadastrado de imveis para medio
do consumo de gs. Ao ser selecionado um imvel devero ser listados todos os pontos
de consumo existentes no imvel.
Ao selecionar um ponto de consumo no imvel, dever ser apresentada a tela
para execuo da anotao do consumo, bem como informaes sobre o cliente e
aparelho medidor, os campos para insero de informaes devero ser o de valor atual
de consumo e de anomalia identificada durante a anotao (p.ex. cachorro solto
impedindo a medio, medidor avariado, etc.).
Aps efetuar a gravao do valor de consumo, a aplicao deve voltar tela
que lista os pontos de consumo, at que todos os pontos de consumo daquele imvel
tenham o valor de consumo informado, no tendo mais anotaes em aberto para o
imvel, o sistema deve voltar tela que lista o roteiro de imveis, para que se possa
selecionar novo imvel e iniciar a anotao de consumo dos pontos vinculados ao imvel.

A figura 6 representa um estudo inicial que demonstra a estrutura para as
principais telas do sistema que devero respectivamente:

1) exibir a relao de imveis de acordo com o roteiro;

2) exibir a relao de pontos de consumo baseados no imvel;

3) exibir os campos para anotao do consumo referente ao ponto.
31


Figura 6: Estudo inicial das principais telas do sistema.

Os roteiros pr-cadastrados devem ser carregados pela aplicao de um
repositrio de dados remoto j existente, da mesma forma, aps serem efetuadas as
gravaes de todos os valores de consumo das unidades consumidoras, o sistema deve
ser capaz de enviar estas informaes para o mesmo repositrio de dados remoto.

O sistema deve estar preparado para funcionar em dispositivos mveis
(smarthphones) com plataforma Android (verso 2.1 ou superior), permitindo que uma
equipe de posse destes dispositivos em trabalho de coleta de consumo em campo, possa
interagir com uma aplicao web remota que acessar uma base de dados ligada a um
sistema departamental, possibilitando efetuar tanto a carga dos roteiros quanto o envio
dos dados para este repositrio remoto.


32

3.2 Ambiente de Desenvolvimento

Para o desenvolvimento de aplicativos em Android necessrio que esteja
configurado um ambiente contendo a ltima verso do Java Development Kit (JDK)
juntamente com o Android SDK, tambm altamente recomendvel que se utilize uma
IDE para a codificao.
Para o prottipo desenvolvido neste trabalho, optou-se pela utilizao da IDE
Eclipse na sua verso 3.6 (codinome Helios), pois alm de ser a IDE mais indicada pelas
referncias oficiais [11], uma IDE de cdigo aberto e com a opo de extenso de suas
funcionalidades atravs da instalao de vrios plugins disponveis, dentre eles o ADT
que um plugin desenvolvido para estender as funcionalidades do Eclipse possibilitando
a criao de projetos voltados para o Android. Este plugin utiliza as bibliotecas
disponibilizadas pelo SDK, funcionando como uma ponte que une o Android SDK ao
Eclipse.
Detalhes de como fazer a instalao e configurao de um ambiente para
desenvolvimento em Android (IDE + ADT + SDK), podem ser obtidos na referncia oficial
do projeto Android [12].

3.2.1 AVD Android Virtual Devices

Estando instalado e configurado o ambiente (IDE + ADT + SDK), o momento
de adicionar um dispositivo virtual (AVD), para que se possa executar e testar a aplicao
desenvolvida. O AVD um dispositivo virtual do sistema operacional do Android que
simula um aparelho no qual voc poder executar e testar suas aplicaes, voc pode
criar vrios AVDs de acordo com o tipo de aparelho que voc deseja emular e verso da
plataforma Android na qual voc est desenvolvendo.
Um AVD basicamente composto de:
Um perfil de hardware (possui cmera, utiliza teclado, etc.).
Qual verso da plataforma Android a executar.
Emulador de carto SD.
rea de armazenamento na mquina de desenvolvimento.
Detalhes de como criar um AVD podem ser obtidos na referncia oficial [13].
33

3.2.2 Criao e Estrutura do Projeto

Com o ambiente de desenvolvimento configurado e a AVD criada, j possvel
criar o projeto da aplicao, e para tanto na IDE Eclipse deve-se seguir o caminho File ->
New -> Other, selecionar a opo Android -> Android Project e clicar no boto Next. A
figura 7 demonstra a tela de configurao do projeto no Eclipse, sendo que os principais
itens que devem ser observados so:

Build Target: Selecionar a verso da plataforma na qual ser desenvolvido o
aplicativo, desta forma a aplicao funcionar nesta verso ou em verses superiores.
Application Name: Especificar o nome do aplicativo, que ser exibido na lista
de aplicativos do dispositivo. O nome definido aqui tambm ser o que estar disponvel
na loja de aplicativos do Android caso o aplicativo venha ser publicado.
Package Name: Especificar o nome do pacote que conter as classes que
estendem de Activity. Caso a aplicao venha ser publicada na loja de aplicativos do
Android, ser necessrio voc ter certeza de que no haver outro denominado de forma
igual, para que esta situao seja evitada sugere-se que o pacote seja um nome de
domnio ou que seja composto pelo nome e sobrenome do desenvolvedor.
Min. SDK Version: Especificar qual o nmero da verso mnima compatvel
com a aplicao a ser desenvolvida, normalmente ser o nmero que acompanha a
verso do Android escolhida em Build Target.

34


Figura 7: Tela de configurao de um projeto no Eclipse.

Depois de confirmadas as configuraes o Eclipse cria o projeto com estrutura
semelhante exibida na figura 8, cada item desta estrutura tem um significado especial,
os principais itens so descritos a seguir:

src: pasta na qual fica a sua Activity principal definida durante a criao do
projeto, bem como todas as outras classes que devero compor o cdigo fonte da
aplicao.
35

gen: pasta na qual criada a classe R.java, que gerada automaticamente
pelo ADT e no deve ser alterada manualmente. Contm todas as referncias aos
recursos que representam a aplicao, tais como arquivos de XML, imagens, etc.
assets: pasta auxiliar que pode conter arquivos diversos como fontes
TrueType, javascripts, etc.
res: localizao dos recursos da aplicao como arquivos de imagem,
internacionalizao e layout.
drawable: pasta na qual ficam localizadas as imagens da aplicao, sendo
possvel categoriz-las em trs resolues distintas utilizando as sub-pastas: drawable-
ldpi, drawable-mdpi e drawable-hdpi.
layout: pasta na qual estaro localizados os arquivos XML que representam as
telas da aplicao.
values: pasta na qual ficam arquivos XML que guardam Strings que podem ser
usadas na aplicao, os valores que constam neste XML so guardados atravs de tags
com a seguinte estrutura <string name=nomeString>Contedo da String </string>.
AndroidManifest.xml: o arquivo de manifesto, nele constaro todas as
configuraes da aplicao e de cada Activity existente.
default.propierties: arquivo que contm configuraes do projeto e utilizado
para controle de reviso de cdigo. Assim como o R.java, no deve ser editado
manualmente.

Figura 8: Estrutura de um projeto Android no Eclipse.
36

3.3 Especificao da Base de Dados

O prottipo necessita de um banco de dados para armazenar as informaes
coletadas sobre o valor consumido de gs em cada ponto de consumo.
A figura 9 exibe a estrutura da tabela na qual sero armazenadas as
informaes referentes ao consumo, a chave primria est representada pela sigla PK
(primary key) e a chave estrangeira est identificada como a sigla FK (foreign key). Esta
tabela representa o armazenamento local dos dados de consumo coletados, uma
estrutura com no mnimo estes campos dever estar disponvel em uma fonte de dados
remota para que seja possvel fazer a importao dos dados referentes aos roteiros de
coleta, bem como a exportao dos dados de consumo coletados durante o trabalho de
campo.


Figura 9: Estrutura da tabela ROTEIROS.

Esta base de dados ser criada no dispositivo mvel usando o motor de banco
de dados denominado SQLite, que um recurso nativo encontrado na plataforma Android
para persistncia de dados estruturados.

SQLite [22] uma biblioteca C que implementa um banco de dados SQL
embutido, permitindo aos programas que a utilizam ter acesso a banco de dados SQL
sem executar um processo RDBMS separado.
37


SQLite no uma ferramenta de cliente usada para conectar com um grande
servidor de banco de dados, mas sim o prprio servidor, lendo e escrevendo diretamente
para e do arquivo do banco de dados no disco.

Algumas Caractersticas do SQLite:

- Software Livre e Multiplataforma.
- Mecanismo de armazenamento seguro com transaes ACID.
- No necessita de instalao, configurao ou administrao.
- Implementa a maioria das funcionalidades do SQL92.
- Cada base de dados criada armazenada em um nico arquivo.
- Suporta bases de dados acima de 2 terabytes.
- Sem dependncias externas.

O dicionrio de dados da tabela que armazenar os roteiros exibido no
quadro 7, ele informa a descrio de cada campo bem como o seu tipo de dado.

Atributo Descrio Tipo Tamanho
ID (PK) Cdigo da coleta Numrico 5
CIL (FK) Cdigo do cliente Numrico 5
Roteiro Descrio do roteiro Caractere 50
Imovel_ID Cdigo do imvel Numrico 5
Imovel Identificao do imvel Caractere 50
PontoConsumo Identificao do ponto de consumo (Cliente) Caractere 50
NumMedidor Nmero do medidor Numrico 4
FuncaoMedidor Funo do Medidor Caractere 50
MarcaMedidor Marca do medidor Caractere 50
ValorMedicao Valor de consumo coletado Numrico 5
Anomalia Desc. de anomalia ocorrida durante a coleta Caractere 50
DataColeta Data de registro da coleta Data -x-
Quadro 7: Dicionrio de dados da tabela ROTEIROS.
38

3.4 Caso de Uso

Um caso de uso representa a interao do atores com o sistema e pode ser
representado por uma descrio simples e em linguagem natural. Isso ajuda a identificar
os objetos e a compreender o que o sistema deve realizar [14].
A figura 10 demonstra o diagrama de caso de uso referente interao dos
atores com a aplicao executada no dispositivo mvel.

Figura 10: Caso de uso do aplicativo de coleta de consumo.

Na arquitetura so propostos seis casos de uso que representam
funcionalidades disponveis e interaes dos atores envolvidos com o sistema.
No primeiro caso denominado importar roteiros, o usurio ir interagir atravs
do sistema com um repositrio de dados externo ao dispositivo que conter os roteiros de
coleta de consumo, neste caso de uso os roteiros importados so armazenados no
repositrio de dados local do dispositivo para utilizao no trabalho da coleta de dados.
No segundo caso de uso denominado exportar roteiros, o usurio ir interagir
atravs do sistema com um repositrio de dados externo ao dispositivo com o objetivo de
39

enviar os dados coletados no trabalho de campo, as informaes de consumo que se
encontram armazenadas no dispositivo sero armazenadas neste repositrio de dados
remoto para utilizao de algum sistema departamental.
No terceiro caso de uso denominado coletar consumo, o usurio ir interagir
atravs do sistema com o repositrio de dados local do dispositivo, que possuir a lista de
roteiros importada previamente da base de dados remota, este caso de uso inclui outros
trs casos que so respectivamente:
Listar imveis, que ir interagir com o armazenamento local para exibir a lista
de imveis disponveis no roteiro, bem como o nmero de pontos de consumo disponveis
no imvel e que ainda no tiveram o seu consumo coletado.
Listar pontos de consumo, que ir interagir com o armazenamento local para
exibir a lista de pontos de consumo com informaes especficas do cliente, e que ainda
no tiveram a coleta de consumo efetuada.
Cadastrar consumo, que dever exibir o formulrio de coleta de dados para o
ponto de consumo selecionado, neste caso haver a interao com o armazenamento
local para persistir o valor de consumo anotado, visando futura exportao para o
repositrio de dados externo.



40

3.5 Diagrama de Sequncia
O diagrama de sequncia demonstra como so realizadas as interaes entre
objetos de forma sequencial [19].
No diagrama exibido na figura 11 possvel verificar a sequncia de interaes
encontradas no aplicativo de coleta de consumo.

Figura 11: Diagrama de sequncia do aplicativo de coleta de consumo.

41

3.6 Interface

O prottipo da aplicao composto por quatro telas sendo que cada uma
destas representa um componente atividade (Activity).
Estes componentes esto descritos no arquivo de manifesto
(AndroidManifest.xml), bem como constam no mesmo arquivo as permisses para garantir
ao prottipo o acesso Internet.
A primeira tela a ser exibida a tela que contm o menu inicial da aplicao
(figura 12), esta tela prov quatro botes de comando que serviro para:

Acionar a base de dados remota para importar a lista de roteiros com os pontos
de consumo.
Acessar os roteiros importados para dar incio coleta de dados.
Enviar para a base de dados remota os dados coletados.
Encerrar a aplicao voltando para o menu inicial do aparelho.


Figura 12: Tela com o menu inicial da aplicao.

42

Ao ser acionado o primeiro boto do menu inicial, uma mensagem de dilogo
(fig. 13A) ser exibida solicitando a confirmao da operao de importao de roteiros.
No caso de aceitao, o sistema tentar acessar a base de dados remota com
informaes de roteiros, isto retornar a lista de roteiros disponveis sendo que o roteiro
mais atual substituir o anterior caso este j exista na base de dados.
As informaes j existentes no dispositivo relacionadas a roteiros anteriores
sero perdidas caso ainda no tenha sido exportadas. No caso de negao de
confirmao o aplicativo retorna ao menu inicial.


Figura 13: Confirmao de importao e exportao: (A) e (B).

Ao ser selecionado o boto que indica a exportao de dados, a aplicao
apresenta outra caixa de dilogo (fig. 13B) e que tambm solicita a confirmao da
operao. Se confirmada, tentar acessar a base de dados remota, porm desta vez com
o objetivo de enviar os dados coletados e grav-los remotamente. O cancelamento da
operao faz a aplicao voltar tela que exibe o menu inicial.
O acionamento do boto que d o acesso ao roteiro ir exibir uma tela com a
43

listagem dos imveis que fazem parte daquele roteiro (fig. 14A), acompanhando cada
registro de imvel exibido o nmero de pontos de consumo que fazem parte daquele
imvel e que ainda no tiveram sua informao de consumo coletada.
A partir do momento que o consumo do ponto coletado, este nmero
decrementado, e vai diminuindo at que as informaes sejam coletadas para todos os
pontos, neste caso, o item que contem a descrio do imvel eliminado da tela.
A partir do momento que no existirem mais imveis listados na tela, indica que
todos os imveis constantes naquele roteiro tiveram seus pontos de consumo coletados.


Figura 14: Telas de listagens e coleta de dados: (A), (B) e (C).

Ao ser selecionado um item na lista de imveis do roteiro, a aplicao exibe
outra lista contendo os pontos de consumo do imvel selecionado (fig. 14B), os itens
desta lista vo deixando de ser exibidos a partir do momento que a coleta da informao
de consumo do ponto efetuada.
Ao ser selecionado um item na lista de pontos de consumo, a aplicao exibe o
formulrio de coleta de dados para aquele ponto (fig. 14C), com informaes sobre o
ponto selecionado, e dois campos para a informao da medio do consumo e, caso
observado, alguma anomalia encontrada no momento da coleta ou que no possibilitou a
coleta no respectivo ponto. Nesta tela, ao ser selecionado o boto de gravao o
processo de coleta de consumo efetuado, a aplicao volta ento a exibir a lista de
pontos de consumo j sem o item referente ao ponto anteriormente coletado.
44

3.7 Implementao

Na implementao do prottipo foi utilizada a linguagem Java que a
linguagem indicada para desenvolvimento de aplicaes na plataforma Android, a
estrutura do prottipo pode ser analisada segundo o digrama de classes exibido na figura
15.

Figura 15: Diagrama de classes

Para o desenvolvimento foi utilizada a IDE Eclipse juntamente com o plugin
ADT, a figura 16 exibe a estrutura do projeto no que se refere s classes implementadas.

45


Figura 16: Classes do projeto na IDE Eclipse

Apesar de a plataforma Android permitir que a codificao de interfaces de
forma procedural, permitindo codificar os elementos diretamente nas classes,
recomendada como uma boa prtica de programao a construo das interfaces de
forma declarativa utilizando descritores XML, pois proporcionam a separao dos
elementos de layout (componentes grficos de interface) do cdigo propriamente dito,
facilitando desta forma manutenes futuras da aplicao.
A figura 17 exibe a estrutura do projeto na IDE Eclipse com os arquivos XML
implementados para a definio das interfaces do prottipo.


Figura 17: Arquivos XML do projeto na IDE Eclipse

O projeto do prottipo composto por dez classes, as classe Main,
ListaImoveis, ListaPontosConsumo e AnotaConsumo herdam da classe Activity e definem
46

uma interface que consiste em uma visualizao que responde a eventos. Cada classe
est associada a um determinado arquivo descritor XML criado na pasta layout e que
define os componentes a serem exibidos na tela, cada componente identificado por um
id especfico que vinculado no cdigo da classe.
As figuras 18 e 19 exibem os extratos de cdigo da classe Main e do arquivo
de layout main.xml que vinculado a classe, demonstrando como este vnculo feito.

Figura 18: Extrato de cdigo de classe que estende Activity.


Figura 19: Extrato de cdigo de layout descrito em XML.

As classes ImovelBaseAdapter e PontoConsumoBaseAdapter herdam da
classe BaseAdapter e trabalham como um adaptador que ir interpretar a fonte de dados
e formatar da maneira que se deseja exibir a informao nos componentes de ListView,
47

estes so exibidos nas telas que listam os imveis (fig. 14A) e os pontos de consumo
disponveis (fig. 14B). Em ambos os casos as fontes de dados sero respectivamente
arrays de objetos das classes Imovel e PontoConsumo.

O componente ListView que ir exibir imveis ou pontos de consumo definido
no arquivo lista_reg.xml, porm aps ser vinculado na activity de exibio, adaptado
para o layout disponvel respectivamente em imveis.xml e pontos_consumo.xml,
conforme pode ser conferido na figura 20 que exibe um trecho de cdigo da classe
ListaImoveis.

Figura 20: Trecho de cdigo de ListaImoveis utilizando ListView adaptada.

A persistncia dos dados feita atravs da classe DatabaseHelper utilizando
uma base de dados relacional (SQLite) que armazenada localmente, esta classe herda
de SQLiteOpenHelper e a classe responsvel por criar a estrutura e popular a base com
os roteiros de coleta, retornar a seleo dos imveis e pontos de consumo existentes e
gravar os dados de consumo coletados.

Para popular a base de armazenamento local com os roteiros de coleta, foi
necessria a integrao do prottipo com um sistema web que acesse um repositrio de
dados remoto. Esta responsabilidade fica a cargo da classe XMLfunctions que ir fazer a
48

integrao entre as aplicaes utilizando somente as APIs e recursos nativos do Android,
sem a necessidade de utilizar componentes proprietrios ou de terceiros.
Com a inteno de demonstrar que a plataforma Android pode ser integrada
com linguagens e ambientes distintos, optou-se por fazer esta integrao de dados com
um sistema web rodando em PHP com acesso a uma base de dados MySQL.

O PHP: Hypertext Preprocessor (PHP) uma linguagem para criao de
scripts, licenciada como software livre e largamente utilizada para construo de sistemas
web. J o MySQL e um Sistema Gerenciador de Banco de Dados (SGBD) que utiliza a
linguagem SQL e assim como o PHP tambm licenciado como software livre, sendo
igualmente popular na soluo para armazenamento de dados em sistemas web.
Para realizar esta integrao com o script em PHP, a classe XMLfunctions
utiliza a classe DefaultHttpClient e HttpPost, que implementam a comunicao atravs do
protocolo HTTP via mtodo POST.

O Hypertext Transfer Protocol (HTTP) um protocolo de rede responsvel pela
transferncia de dados e pela comunicao entre cliente e servidor no ambiente da
Internet, o qual permite a transferncia de dados em hipermdia (texto, imagem e som).
Um de seus principais mtodos de transferncia o POST que permite que um cliente
envie mensagens ao servidor, o qual ir manipular os dados da forma desejada, sendo
que a informao includa no corpo do comando dando mais segurana entre a
requisio e a resposta.

Todo este processo implementado pela classe XMLfunctions nos mtodos
getXML() e postXML(). Para o caso da importao de roteiros que retornar um arquivo
XML com o contedo solicitado, ser necessrio ainda um procedimento de parser sobre
este retorno para que a aplicao possa ler o arquivo XML e navegar no seu contedo,
este procedimento fica a cargo do mtodo XMLfromString.

O cdigo exibido na figura 21 demonstra um trecho da implementao
necessria para enviar uma requisio POST para o script PHP que conecta a base de
dados remota, e retorna em formato XML os roteiros disponveis para coleta.

49


Figura 21: Trecho de cdigo para POST que retorna XML.

O cdigo exibido na figura 22 demonstra um trecho da implementao
necessria para o procedimento de parser, que carrega em um objeto Document o
contedo do XML formatado.


Figura 22: Trecho de cdigo para parser do XML retornado.

Isto necessrio para que a aplicao possa ler o arquivo XML e navegar no
seu contedo recuperando as informaes encontradas nos ns e armazenamento estas
informaes na base de dados do dispositivo.


O cdigo exibido na figura 23 demonstra um trecho da implementao do
mtodo da classe Main, que o responsvel por receber as informaes importadas no
formato XML, acionar o parser, e navegar pelas informaes encontradas em ns do XML
e que sero armazenadas na base de dados do dispositivo.

50


Figura 23: Trecho de cdigo de importao de roteiros.

O cdigo exibido na figura 24 demonstra um trecho da implementao
necessria para o envio via POST de um arquivo em formato XML para o script PHP,
neste arquivo constam s informaes de consumo coletadas.


Figura 24: Trecho de cdigo para envio de XML via POST.
Um aplicativo em Android se caracteriza por um conjunto de atividades
(Activities) que vo sendo adicionadas a uma pilha e disponibilizadas para navegao do
usurio. Esta atividades devem estar definidas em um arquivo de manifesto denominado
AndroidManifest.xml.
Neste arquivo tambm devero estar presentes todas as configuraes e
51

permisses necessrias para execuo das funcionalidades do aplicativo, no caso do
prottipo deve ser observada a permisso para acesso a Internet, caso contrrio os
procedimentos de integrao com a base de dados remota no funcionam, a figura 25
exibe o contedo do arquivo de manifesto AndroidManifest.xml.


Figura 25: Trecho do contedo de AndroidManifest.xml.

52

4 VALIDAO DO PROTTIPO

Para validao do prottipo foram utilizados dois scripts simples em PHP que
consultam e atualizam dados em uma base de dados MySQL remota. Tanto os scripts
quanto a base de dados foram hospedados num servidor externo ao ambiente no qual
estava sendo desenvolvida a aplicao.
Para tal, foi escolhido um servidor de hospedagem gratuito (awardspace.com),
que possibilitou rodar os scripts PHP e criar a base MySQL.

Antes de iniciar a validao das funcionalidades do prottipo, foi necessrio
carregar a base de dado remota com alguns dados de roteiros fictcios, conforme
demonstra a figura 26 (foram criados dez registros).

Figura 26: Tabela ROTEIROS na base de dados remota.

A aplicao foi validada primeiramente no emulador disponibilizado pelo
Android SDK (ver figura 27), porm o emulador tem limitaes comparadas execuo
em um dispositivo real como, por exemplo, simular o toque de tela. Ento, depois de
validadas todas as funcionalidades no emulador foram validadas as funcionalidades em
um dispositivo real.
Para tanto foi utilizado o aparelho fabricado pela empresa Samsung cujo
modelo denominado Galaxy 5 e que pode ser visto na figura 28.



53


Figura 27: Emulador Android SDK utilizado para validao.


Figura 28: Dispositivo Galaxy 5 utilizado para validao.


54

Depois de carregada a base remota, a primeira funcionalidade do prottipo
validada foi a de importao de roteiros, nesta funcionalidade feita a comunicao com
a base remota atravs da chamada ao script PHP, que por sua vez retorna o XML
contendo os roteiros de coleta. Esta funcionalidade foi validada a contento, de acordo com
o que exibe a figura 29 a aplicao informa ao usurio conforme vai carregando no
dispositivo os pontos de consumo.


Figura 29: Tela informando o processo de importao.

O prximo teste foi acessar os roteiros importados e efetuar um registro de
coleta de consumo, neste caso algumas consistncias deveriam ser testadas como a
certificao que apenas nmeros inteiros deveriam ser aceitos como valor de consumo e,
para o caso de impossibilidade de coleta, certificar que foi informada a anomalia que
causou a impossibilidade da coleta.
Novamente a validao foi a contento conforme demonstra a figura 30 (A e B),
ao ser acessada a lista de roteiros a soma da quantidade indicada para pontos de
consumo em cada imvel equivale ao nmero de registros criados na base de dados
remota (dez registros). Ao selecionar um imvel foram exibidos os pontos de consumo
55

daquele imvel, e quando selecionado o ponto de consumo foi exibido o formulrio de
coleta.

Figura 30: Seqncia para validao da funcionalidade de coleta: (A), (B) e (C).

Conforme demonstrado na figura 30(A), ao ser digitado no campo reservado ao
valor do consumo uma informao que no correspondia a um nmero inteiro, foi exibida
uma mensagem alertando a inconsistncia. Da mesma forma, na figura 31(B) e 31(C),
quando indicado um valor 0 (zero) para o valor do consumo correspondendo
impossibilidade de coleta e no informando qual foi a anomalia que gerou a
impossibilidade, foi tambm exibida uma mensagem alertando a inconsistncia das
informaes.

Figura 31: Validao dos alertas de inconsistncia. (A), (B) e (C).
56


Por fim, conforme demonstra a figura 32(A) e 32(B), ao ser inserido um valor
vlido para a informao de consumo, indicado que a operao de coleta foi efetuada,
voltando lista de pontos de consumo j sem o ponto anteriormente coletado. Ao voltar
lista de roteiros, a informao referente ao nmero de pontos de consumo por medir est
diminuda em uma unidade conforme demonstra a figura 32(C).

Figura 32: Validao da funcionalidade de coleta do consumo: (A), (B) e (C).

Encerrando as validaes da funcionalidade de coleta, foi verificada a
funcionalidade de exportar as coletas efetuadas para a base de dados remota, novamente
o funcionamento foi a contento conforme pode ser observado na figura 33 que exibe
comportamento da aplicao, bem como na figura 34 que exibe a lista de registros da
base de dados remota j com o valor de coleta atualizado.
57


Figura 33: Validao da funcionalidade de exportao.


Figura 34: Base de dados remota com consumo coletado.

Todas as funcionalidades da aplicao foram validadas diversas vezes sendo
que para todas foram retornados os comportamentos esperados. Apenas com uma
ressalva para as funcionalidades de importao e exportao, que em alguns casos
apresentaram demora no retorno da resposta.
Uma hiptese para este comportamento seria a caracterstica do servidor no
qual se encontrou instalada a parte implementada em PHP/MySQL, pois servidores de
hospedagem gratuita por muitas vezes podem apresentar instabilidade. Infelizmente no
foi possvel validar o prottipo acessando um servidor PHP/MySQL empresarial.
58

5 CONCLUSO

Em geral as concessionrias de distribuio de gs natural localizadas pelos
diversos estados do pas possuem metodologia de coleta de consumo pouco
automatizada, sendo em muitos casos utilizados mtodos pouco convencionais como
anotao do valor consumido em planilhas impressas para posterior digitao em sistema
apropriado.
Por outro lado observa-se que o mercado de distribuio de gs natural dever
apresentar um crescimento nos prximos anos, colocando o segmento de consumo
residencial, at ento pouco explorado, com um segmento de potencial crescimento.
Sendo assim, o aumento de pontos individuais devido expectativa relacionada ao
mercado residencial, dever levar a necessidade das concessionrias de encontrar
solues para incrementar o processo de coleta de consumo proporcionando um
levantamento de informaes de forma mais gil e consistente.
A partir desta motivao, este trabalho apresenta uma abordagem focada na
mobilidade e conectividade presente em dispositivos mveis como os smartphones,
propondo um prottipo de aplicao desenvolvido sob plataforma Android e verificando a
utilidade destes dispositivos como um agente principal na automao do processo de
coleta em campo de informaes referentes ao consumo de gs natural.
A escolha da plataforma Android foi motivada principalmente por ser um projeto
de cdigo aberto com disponibilidade de vasta documentao e cdigos de exemplo, bem
como de ferramentas gratuitas que auxiliam o desenvolvimento, aspectos que
seguramente facilitam e aceleram o processo de criao de aplicaes para dispositivos
mveis.
O prottipo desenvolvido nesse trabalho comprovou cumprir seus objetivos,
conforme as validaes realizadas, dentre os quais permitir a importao de informaes
de roteiros de uma base de dados remota, acessar os imveis encontrados nesta lista de
roteiros, acessar a lista de pontos de consumo de determinado imvel e possibilitar ao
usurio da aplicao fornecer informaes de consumo vlidas referentes ao ponto de
consumo escolhido. Persistir esses dados localmente ao dispositivo e envi-los
corretamente para a base de dados remota disponibilizando as informaes para sistemas
externos.
Por fim, obteve-se um prottipo funcional de uma aplicao voltada a coleta de
59

dados, utilizando-se de considervel variedade de conceitos e recursos referentes
plataforma de desenvolvimento Android, focando na interoperabilidade entre diferentes
aplicaes e possibilitando a integrao entre mobilidade e outros ambientes tradicionais
de sistemas.
Espera-se que este trabalho possa ser uma alternativa de pesquisa
interessante para concessionrias de distribuio de gs que ainda tenham seu processo
de coleta de informaes de consumo baseado em anotaes manuais atravs de
planilhas e que pretendam agregar o aspecto da mobilidade ao seu processo,
proporcionando uma forma mais gil e mais precisa no trabalho de levantamento de
informaes de consumo.


60

6 CONTRIBUIES E TRABALHOS FUTUROS

Foram exploradas neste trabalho diversas caractersticas da plataforma
Android, procurando contribuir com um contedo de leitura aos interessados em explorar
o desenvolvimento nesta plataforma, bem como aos que se interessam pelo
desenvolvimento para dispositivos mveis em geral.
Com a modelagem do prottipo esperasse contribuir para que empresas que
tenham o processo de coleta de consumo em seu negcio e pretendam agregar a
mobilidade ao seu processo, obtenham uma noo de como a plataforma Android pode
ajudar na concepo de uma soluo mvel para coleta de informaes.
Sendo a aplicao apresentada um prottipo, pode ainda possuir muitas
funcionalidades, algumas das quais descrevemos a seguir com o objetivo de serem
incorporadas em trabalhos futuros:
Controle atravs de acesso por login e senha.
Implementar funo que liste as coletas efetuadas com possibilidade, de
um nmero determinado de correes do valor coletado.
Baseado no histrico de consumo do cliente, validar a informao de
consumo anotada conforme a previso de consumo.
No caso de insero de valores no validados, contar quantas vezes o
valor do consumo foi redigitado, tentando eliminar coletas efetuadas
atravs do mtodo de tentativa e erro.
Medir o tempo transcorrido entre a seleo do imvel e a gravao do
valor de consumo de todos os seus pontos de consumo, bem como,
atravs de GPS (ou API de localizao), identificar e gravar a localizao
do leiturista no momento que este inicia o processo de coleta em
determinado imvel.
Utilizar criptografia na integrao de dados.
Listview ou autocompletar no campo para anotao de anomalias.
Possibilitar a anotao atravs de reconhecimento de voz, para os
dispositivos que permitam este recurso.
Adaptar imagens para poder utilizar a aplicao no layout horizontal.

61

REFERNCIAS BIBLIOGRFICAS

[1] LORENZI, Sabrina. Com mais gs, Petrobras avana no setor eltrico. Portal IG
Economia Empresas. Disponvel em:
http://economia.ig.com.br/empresas/industria/com+mais+gas+petrobras+avanca+no+setor
+eletrico/n1300082686367.html. Acesso em: 30 abr. 2011.

[2] Assesioria de Comunicao. Compagas fecha 2010 em alta e projeta investimentos
para 2011. Disponvel em:
http://www.compagas.com.br/index.php/web/noticias/sala_de_imprensa/noticias/2011/com
pagas_fecha_2010_em_alta_e_projeta_investimentos_para_2011. Acesso em: 30 abr.
2011.

[3] SCGS cresce em 2010 e planeja expanso at 2015. Disponvel em:
http://www.scgas.com.br/noticia/index/idse/396/id/5525?dt_ini=&dt_fim. Acesso em: 01
mai. 2011.

[4] KLEIN, Jefferson. Sulgs quer crescer em receita e nmero de clientes. Jornal do
Comrcio. Disponvel em:
http://www.sulgas.rs.gov.br/index.asp?SECAO=8&SUBSECAO=36&EDITORIA=1690.
Acesso em: 01 mai. 2011.

[5] Johnson, Thienne M. Java para dispositivos mveis. Desenvolvendo aplicaes
com J2ME. Editora Novatec. Novembro 2007.

[6] NIELSENWIRE. U.S. Smartphone Market: Whos the Most Wanted?
http://blog.nielsen.com/nielsenwire/?p=27418. Acesso em 15 mai 2011

[7] GAERTNER. Smartphone Operating System Market by Year-End 2012
http://www.gartner.com/it/page.jsp?id=1622614 Acesso em 18 mai 2011

[8] GOOGLE. Data Storage. Disponvel em:
http://developer.android.com/guide/topics/data/data-storage.html Acesso em: 30 mai.
2011.

62

[9] LECHETA, R. R. Google Android: Aprenda a criar aplicaes para dispositivos
mveis com o Android SDK. Novatec, 2 edio, 2010.

[10] DISTMO: App Store Overview. Disponvel em: http://www.distimo.com/appstores/.
Acesso em 01 jun. 2011.

[11] GOOGLE. System Requirements. Disponvel em:
http://developer.android.com/sdk/requirements.html Acesso em 04 jun. 2011.

[12] GOOGLE. Installing the SDK. Disponvel em:
http://developer.android.com/sdk/installing.html Acesso em 04 jun. 2011.

[13] GOOGLE. Managing AVDs with AVD Manager. Disponvel em:
http://developer.android.com/guide/developing/devices/managing-avds.html Acesso em
04 jun. 2011.

[14] SOMMERVILE, Ian. Engenharia de software. Pearson, 6 edio, 2003.

[15] GOOGLE. What is Android. Disponvel em:
http://developer.android.com/guide/basics/what-is-android.html Acesso em 04 jun. 2011.

[16] GOOGLE. Activity Reference. Disponvel em:
http://developer.android.com/reference/android/app/Activity.html. Acesso em 04 jun. 2011.

[17] TOSIN, Carlos. Conhecendo o Android. Disponvel em:
http://www.softblue.com.br/blog/home/postid/11/CONHECENDO+O+ANDROID Acesso
em 04 jun. 2011.

[18] FAEBER, N., HILZINGER, M. Sistemas Operacionais Mveis. Linux Magazine. So
Paulo: LNMB, n.75, p. 32-37, fev. 2011.

[19] MELO, Ana Cristina. Desenvolvendo aplicaes com UML. . Rio de Janeiro:
Brasport, 2002.

63

[20] IDGNOW. Desonerao pode reduzir preo do tablet. Disponvel em:
http://www.brasil.gov.br/noticias/arquivos/2011/04/05/desoneracao-pode-reduzir-preco-do-
tablet-brasileiro-em-mais-de-30. Acesso em 15 jul. 2011.

[21] IDGNOW. Governo decide incluir tablet na MP do Bem. Disponvel em:
http://idgnow.uol.com.br/computacao_pessoal/2011/05/14/governo-decide-incluir-tablet-na-
mp-do-bem-preco-deve-cair/. Acesso em 15 jul. 2011.

[22] SQLite. About SQLite. Disponvel em: http://www.sqlite.org/about.html. Acesso em 15
jul. 2011.