UNIVERSIDADE TECNOLGICA FEDERAL DO PARAN

DEPARTAMENTO ACADMICO DE INFORMTICA

CURSO DE ESPECIALIZAO EM TECNOLOGIA JAVA E
DESENVOLVIMENTO PARA DISPOSITIVOS MVEIS

RODRIGO FAGUNDES EGGEA

APLICAO ANDROID UTILIZANDO SISTEMA DE LOCALIZAO

GEOGRFICA PARA DETERMINAO DE PONTOS TURSTICOS
NA CIDADE DE CURITIBA

MONOGRAFIA DE ESPECIALIZAO

CURITIBA
2013

RODRIGO FAGUNDES EGGEA

APLICAO ANDROID UTILIZANDO SISTEMA DE LOCALIZAO

GEOGRFICA PARA DETERMINAO DE PONTOS TURSTICOS
NA CIDADE DE CURITIBA

Monografia apresentada como requisito

parcial obteno do ttulo de
Especialista em Tecnologia Java e
Desenvolvimento
para
Dispositivos
Mveis, do Departamento Acadmico de
Informtica, da Universidade Tecnolgica
Federal do Paran.
Orientador: Prof. Paulo Santos Zeferino

CURITIBA
2013

RESUMO

O Brasil sediar a Copa do Mundo em 2014 e as Olmpiadas em 2016, sendo

previsto a visita de milhes de estrangeiros em diversas cidades do pas, inclusive
na cidade de Curitiba, que sediar jogos da Copa do Mundo. O aumento de turistas
na cidade promover o turismo regional e a visitao aos pontos tursticos da
cidade. A dificuldade na localizao dos pontos tursticos pode ser um problema
para os turistas, devido falta de informaes, sinalizaes e pela falta de
profissionais no setor hoteleiro, turstico e de servios para atender a demanda. O
uso de aplicaes para dispositivos mveis vai de encontro a esta necessidade,
permitindo o desenvolvimento de inmeras aplicaes tursticas. Neste contexto,
este trabalho apresenta o estudo e o desenvolvimento de uma aplicao para
dispositivos mveis com sistema operacional Android, que serve como um guia
virtual da cidade de Curitiba. Por meio do aplicativo o turista pode se localizar no
mapa, permite buscar rapidamente os pontos tursticos, ver o itinerrio da linha
turismo, seus pontos de parada e obter informaes detalhadas de cada ponto
turstico. Este aplicativo utiliza sistemas de localizao geogrfica, mapas,
comunicao de dados, comunicao cliente-servidor e banco de dados.

Palavras-chave: Pontos tursticos. Linha de turismo. Curitiba. Google Maps.

Android.

ABSTRACT

The next years Brazil will host the World Cup in 2014 and the Olympic Games in
2016, and is expected to visit millions of foreigners in several cities, including the city
of Curitiba, which will host matches of the World Cup. The increase of tourists in the
city will promote regional tourism and visitation to the city's sights. The difficulty in
locating the sights can be a problem for tourists due to lack of information, traffic
signs and lack of professionals in the hospitality industry, tourism and services tend
to demand. The use of mobile applications meets this need, allowing the
development of numerous tourism applications. In this context, this paper presents
the study and development of an application for mobile devices with Android
operating system, which will serve as a virtual guide of the city of Curitiba. The
application allow the tourist to locate your own position on the map, can quickly
locate the sights, see the tourism line route, the bus stops and detailed information of
each tourist spot. This application uses geolocation systems, maps, data
communication, client-server communication and database.

Keywords: Tourist Attraction. Tourism line. Curitiba. Google Maps. Android.

LISTA DE ILUSTRAES

Figura 1 - Os quatro componentes de um LBS ......................................................... 14

Figura 2 Participao no mercado mundial de sistemas operacionais para
dispositivos mveis no primeiro trimestre de 2013 .................................................... 16
Figura 3 Arquitetura Android .................................................................................. 17
Figura 4 Aplicao utilizando Google Maps API no Android .................................. 20
Figura 5 Interao entre os elementos da arquitetura de Web Services ................ 22
Figura 6 Estrutura da mensagem SOAP ................................................................ 23
Figura 7 Exemplo de informaes de livros armazenados em formato JSON ....... 24
Figura 8 Arquitetura Cliente Servidor ..................................................................... 25
Figura 9 Modelo Cliente-Cache-Servidor ............................................................... 25
Figura 10 Modelo Cliente-Servidor sem estado de conexo .................................. 26
Figura 11 Aplicativo de guia turstico de Manaus ................................................... 27
Figura 12 Aplicativo Curta Curitiba ...................................................................... 28
Figura 13 Aplicativo Mob.urb baixado do Google Play ........................................... 29
Figura 14 Modelo cliente-servidor .......................................................................... 32
Figura 15 Prottipo do aplicativo em Evolus Pencil................................................ 33
Figura 16 Diagrama de Caso de Uso ..................................................................... 34
Figura 17 Diagrama de Classes ............................................................................. 35
Figura 18 Diagrama de Sequencia de Login .......................................................... 36
Figura 19 Diagrama de Sequencia de acesso ao Banco de Dados ....................... 36
Figura 20 Utilizao do LagLng no Google Maps................................................... 37
Figura 21 Itinerrio da Linha de Turismo de Curitiba ............................................. 38
Figura 22 Edio dos cones com o programa GIMP ............................................. 39
Figura 23 Modelo do Banco de Dados ................................................................... 39
Figura 24 Implementao de um servio web RESTful .......................................... 41
Figura 25 Exemplo de converso de dados para JSON ........................................ 42
Figura 26 Resposta do servidor web no formato JSON ......................................... 42
Figura 27 Trecho do cdigo do servlet de autenticao ......................................... 43
Figura 28 Trecho do cdigo da Activity de autenticao ........................................ 45
Figura 29 Cdigo XML da Interface de Mapa ......................................................... 45
Figura 30 Trecho do cdigo da Activity do Mapa ................................................... 46
Figura 31 Trecho do cdigo que insere os marcadores no mapa .......................... 47
Figura 32 Cdigo XML do menu de configuraes ................................................ 47
Figura 33 Tela de abertura do aplicativo Curitour .................................................. 48
Figura 34 Tela de autenticao de usurio ............................................................ 49
Figura 35 Tela do aplicativo com todas camadas habilitadas ................................ 49
Figura 36 Balo de informao aps o marcador ser clicado................................. 50
Figura 37 Tela de informaes detalhadas do ponto turstico ................................ 50
Figura 38 Tela apresentando as opes do menu ................................................. 51

Figura 39 Tela de seleo de camadas ................................................................. 51

Figura 40 Mapa com o percurso da linha de turismo ............................................. 52
Figura 41 Lista de seleo de ponto turstico ......................................................... 52

LISTA DE SIGLAS

AJAX

Asynchronous Javascript and XML

API

Application Programming Interface

AVD

Android Virtual Device

CORBA

Common Object Request Broker Architetura

DAO

Data Access Object

DCOM

Distributed Component Object Model

GPS

Global Positioning System

HTTP

Hypertext Transfer Protocol

HTTPS

Hypertext Transfer Protocol Secure

JAX-RS

Java API for RESTful Services

JSON

JavaScript Object Notation

LBS

Location-Based Services

MIME

Multipurpose Internet Mail Extensions

OHA

Open Handset Alliance

PMC

Prefeitura Municipal de Curitiba

POJO

Plain Old Java Objects

REST

Representational State Transfer

RMI

Remote Method Invocation

RPC

Remote Procedure Call

SDK

Software Development Kit

SMS

Short Message Service

SOAP

Simple object Access Protocol

UML

Unified Modeling Language

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

VM

Virtual Machine

W3C

World Wide Web Consortium

WSDL

Web Service Description Language

WWW

World Wide Web

XML

eXtensible Markup Language

SUMRIO

1 INTRODUO .....................................................................................................10
1.1 OBJETIVO GERAL ...........................................................................................11
1.2 OBJETIVO ESPECFICO..................................................................................11
1.3 JUSTIFICATIVA ................................................................................................12
1.4 ESTRUTURA DO TRABALHO .........................................................................12
2 ESTUDO DAS TECNOLOGIAS ...........................................................................13
2.1 SERVIOS BASEADOS EM LOCALIZAO ..................................................13
2.1.1 Dispositivo Mvel (Mobile device) ...................................................................14
2.1.2 Provedor de Contedo (Content Provider) ......................................................14
2.1.3 Rede de Comunicao (Communication Network) .........................................15
2.1.4 Componente de localizao (Positioning technology).....................................15
2.2 PLATAFORMA ANDROID ................................................................................16
2.3 ARQUITETURA ANDROID ...............................................................................17
2.4 GOOGLE MAPS API.........................................................................................19
2.5 LOCALIZAO E MAPAS NO ANDROID ........................................................20
2.6 WEB SERVICES ...............................................................................................21
2.7 PROTOCOLO SOAP ........................................................................................22
2.8 PROTOCOLO REST.........................................................................................23
3 APLICATIVOS TURSTICOS BRASILEIROS ......................................................27
3.1 APLICATIVO REVIVA MANAUS ......................................................................27
3.2 APLICATIVO CURTA CURITIBA ......................................................................28
3.3 APLICATIVO MOB.URB ...................................................................................28
3.4 CONCLUSO DO CAPTULO ..........................................................................29
4 DESENVOLVIMENTO ..........................................................................................30
4.1 LEVANTAMENTO DOS REQUISITOS .............................................................30
4.2 DESCRIO DO PROTTIPO ........................................................................32
4.3 MODELAGEM ...................................................................................................33
4.3.1 Diagrama de Caso de Uso ..............................................................................34
4.3.2 Diagrama de Classes......................................................................................35
4.3.3 Diagrama de Sequncia .................................................................................36
4.3.4 Coordenadas Geogrficas dos marcadores ...................................................37
4.3.5 Desenvolvimento dos Marcadores ..................................................................38
4.4 IMPLEMENTAO ...........................................................................................39
4.4.1 Banco de Dados .............................................................................................39
4.4.2 Servidor ..........................................................................................................40
4.4.3 Aplicativo Android ...........................................................................................43
4.4.3.1 Biblioteca Google Maps API Android ..........................................................43
4.4.3.2 Activities ......................................................................................................44

4.4.4 Telas do aplicativo ..........................................................................................48

5 CONCLUSO .......................................................................................................53
6 TRABALHOS FUTUROS .....................................................................................54
7 REFERNCIAS ....................................................................................................55

10

1 INTRODUO

O Brasil nos prximos anos sediar grandes eventos, como a Copa do

Mundo em 2014 e as Olimpadas em 2016. Sediar megaeventos como a Copa o
Mundo e as Olimpadas representam muito mais que eventos esportivos, mas uma
grande oportunidade de negcios, que influenciam a socioeconomia dos lugares
(MORGAN; SUMMERS, 2008).
Uma pesquisa realizada pela Fundao Getlio Vargas, a pedido do
Ministrio do Turismo em 2009, estimou que 5,9 milhes de estrangeiros visitariam o
Brasil entre os anos de 2009 a 2014, sendo que, durante a realizao do torneio,
500 mil turistas so esperados e devem permanecer no pas, em mdia 15 dias,
gastando aproximadamente dez mil reais, totalizando uma receita de 6,27 bilhes de
reais (NEVES et al., 2011).
Em vista de todos esses eventos e o fato da cidade de Curitiba ter
conquistado o direito a ser uma das 12 cidades que ter a oportunidade de sediar os
jogos da Copa do Mundo de 2014, atrair milhares de turistas nos prximos anos. A
dificuldade na localizao dos principais pontos tursticos poder ser um problema
para os turistas que estaro visitando a cidade de Curitiba pela primeira vez, devido
falta de informaes, placas, sinalizaes e pela falta de profissionais com
conhecimento na cidade, seja no setor hoteleiro, turstico e de servios para atender
a demanda.
Os telefones celulares j contam com mais de 4 bilhes de usurios no
mundo e ganharam status de ferramenta indispensvel. Por outro lado, a venda de
smartphones tem superado a de laptops, o que indica que aqueles devem ganhar
espao como computador pessoal nos prximos anos (LECHETA, 2010).
A utilizao da tecnologia de redes de dados sem fio e de celulares
smartphones ser intenso durante os prximos anos, devido facilidade em tirar
fotos, gravar vdeos, realizar compartilhamento das informaes em redes sociais e
assistir os jogos em tempo real (EMBRATUR, 2010).

11

1.1 OBJETIVO GERAL

O objetivo geral o desenvolvimento de uma aplicao para dispositivos

mveis que servir como um guia turstico virtual para localizar facilmente a posio
atual do dispositivo e dos pontos tursticos da cidade de Curitiba.
O aplicativo mostrar o mapa da cidade com os principais pontos tursticos
da cidade como pera de Arame, Jardim Botnico, Passeio Pblico, entre outros de
forma simples, clara e objetiva. O turista ao clicar no ponto turstico receber
informaes relevantes sobre o local. Tambm ser possvel realizar uma busca
rpida de pontos tursticos atravs de uma lista e poder visualizar o itinerrio da
linha turismo e seus respectivos pontos de parada. Inicialmente o aplicativo estar
disponvel em portugus podendo ser estendido a outros idiomas.

1.2 OBJETIVO ESPECFICO

Analisar as tecnologias necessrias para desenvolver o aplicativo;

Estudar o estado da arte de aplicativos tursticos brasileiros;
Estudar a biblioteca do Google Maps para Android;
Analisar os requisitos do aplicativo;
Modelar o aplicativo para dispositivo mvel;
Modelar a base de dados;
Pesquisar e inserir as informaes na base de dados;
Desenvolver o servio web que realizar a comunicao com o banco de
dados e ser consumido pelo aplicativo Android;
Desenvolver a aplicao para dispositivos mveis com sistema operacional
Android como tablets e smartphones que possuam GPS e conexo de dados.

12

1.3 JUSTIFICATIVA

A justificativa deste trabalho aproveitar a demanda por produtos e servios

que ocorrer em todos os setores no Brasil nos prximos anos, devido ao aumento
do turismo, e desenvolver um aplicativo que auxilie os turistas a conhecerem melhor
a cidade, mesmo na ausncia de um guia turstico.
O trabalho tambm busca mostrar a importncia no desenvolvimento de
aplicativos regionais, focados a uma regio especfica, permitindo explorar e
valorizar os aspectos culturais da regio.

1.4 ESTRUTURA DO TRABALHO

Inicialmente no captulo 2 ser realizado um estudo do estado da arte das

tecnologias atualmente envolvidas no desenvolvimento de aplicativos para Android
baseados em localizao.
No captulo 3 so mostrados alguns aplicativos, semelhantes ao proposto
neste trabalho, voltados para o setor tursticos no Brasil e suas funcionalidades.
No captulo 4 realizada a descrio do prottipo do aplicativo, os requisitos
do sistema, sua modelagem e a estrutura do banco de dados. Aps essa etapa
descrito a sua implementao no lado servidor e no cliente Android.
Por fim, o captulo 5 apresenta a concluso geral do trabalho, contendo a
anlise da aplicabilidade do aplicativo, pontos positivos e negativos, bem como as
consideraes finais e sugestes de implementaes futuras.

13

2 ESTUDO DAS TECNOLOGIAS

Este captulo apresenta um estudo das tecnologias empregadas no

desenvolvimento de aplicativos mveis que utilizam servios baseados em
localizao (location based services), estudo da arquitetura Android, sua biblioteca
de localizao e mapas (Google Maps), estudo da arquitetura de servidores web e
dos protocolos de comunicao cliente-servidor SOAP e REST.

2.1 SERVIOS BASEADOS EM LOCALIZAO

A definio tpica de servios baseados em localizao so para servios de

informao, acessveis por dispositivos mveis atravs das redes de dados fazendo
uso da posio geogrfica do dispositivo.
Segundo Ferraro e Aktihanoglu (2011), esta definio est desatualizada na
atual gerao de dispositivos mveis e web services. Atualmente a interao do
usurio e a possibilidade de gerar contedo so fundamentais para os servios e
aplicaes. Uma melhor definio atual de servio baseado em localizao um
servio que:
O usurio capaz de determinar sua localizao;
As informaes fornecidas so espacialmente relacionadas com a localizao
do usurio;
oferecido ao usurio uma interao dinmica ou bidirecional com o
provedor de contedo.

Desta maneira o usurio pode responder s trs questes:

Onde estou?
O que posso fazer por perto?
O que acho sobre este lugar?
So quatro os componentes comuns a todas as aplicaes LBS: dispositivo
mvel, provedor de contedo, rede de dados e um componente de localizao,
conforme mostrado na Figura 1.

14

Figura 1 - Os quatro componentes de um LBS

Fonte: Ferraro e Aktihanoglu (2011)

2.1.1 Dispositivo Mvel (Mobile device)

Os smartphones tiveram uma importncia na rpida absoro de servios

LBS, dado seu tamanho de tela, geralmente grandes e a incluso quase que
universal de tecnologias de localizao (como GPS). O rpido crescimento dos
netbooks e dos tablets tambm fizeram os desenvolvedores comearem a pensar
em dispositivos mveis muito mais do que apenas telefones celulares.

2.1.2 Provedor de Contedo (Content Provider)

Um provedor de contedo uma entidade que cria ou detm o contedo que

pode ser fornecida aos dispositivos mveis, diretamente ou atravs de terceiros.
Um provedor LBS no armazena ou mantm todo o contedo e dados que
so acessados pelo usurio no dispositivo mvel. Um exemplo so os dados de
mapas, que normalmente so fornecidos por um provedor de mapas, como por
exemplo pela empresa NAVTEQ. Cada vez mais os dados so disponibilizados aos
usurios na forma de camadas de mapas, atravs de provedores de terceiros, que

15

normalmente podem ser ligados ou desligados pelo usurio (mostrando apenas os

postos de gasolina em um mapa, por exemplo).

2.1.3 Rede de Comunicao (Communication Network)

O desenvolvedor do aplicativo LBS no tem controle direto sobre a rede de

comunicao, mas pode gerenciar o trfego dos dados utilizado pelo aplicativo,
maximizando a velocidade de transferncia ou minimizando a latncia, bem como
limitando as taxas de dados para clientes pr-pagos.

2.1.4 Componente de localizao (Positioning technology)

O componente de localizao refere-se tecnologia que permite a

localizao do aparelho e tem a capacidade de repassar essa informao para a
aplicao. Esse componente est se tornando cada vez mais escondido, at mesmo
para os desenvolvedores dos aplicativos, mas ainda h um grau de escolha entre os
mtodos de localizao, que podem ser por triangulao, Cell ID, navegao por
satlite ou por Wireless Positioning System (WPS). Nos dispositivos que possuem
mais de uma tecnologia de localizao disponveis, a utilizao hbrida de
posicionamento vem se tornando cada vez mais utilizada para minimizar as
desvantagens do uso de uma nica tecnologia.
Est se tornando comum a capacidade de determinar a localizao
atravs de APIs ou componentes de software para pelo menos estabelecer uma
localizao aproximada. Isso cada vez mais utilizado por navegadores de celular
para, por exemplo, ser capaz de oferecer resultados de busca de imveis restritas
rea em que o dispositivo est localizado.

16

2.2 PLATAFORMA ANDROID

Atualmente h 1,5 bilhes de televises em todo o mundo, um bilho de

pessoas com acesso a Internet e quase 3 bilhes de pessoas possuem um telefone
celular, isso corresponde a mais ou menos metade da populao mundial, sendo
considerado um dos mais bem sucedidos produtos de consumo (OHA, 2013).
Android uma nova plataforma de desenvolvimento para aplicativos mveis
como smartphones baseados no sistema operacional Linux que possui uma
interface visual rica, GPS, diversas aplicaes pr-instaladas e um ambiente de
desenvolvimento bastante poderoso e que utiliza a linguagem de programao Java.
O Android foi desenvolvido pela Open Handset Alliance (OHA), liderada pelo Google
e empresas como HTC, LG, Motorola, Samsung, Sony Ericsson, Toshiba e muitas
outras, que tiveram por objetivo padronizar uma plataforma de cdigo aberto e livre
para celulares, para atender as necessidades do mercado atual (LECHETTA, 2010).
A plataforma Android atualmente o principal sistema operacional para
dispositivos mveis, seguido pelo iOS da Apple, conforme estudo de mercado
produzido pela empresa Canalys (CANALYS, 2013). Este estudo mostra que
durante o primeiro trimestre de 2013, a plataforma Android representa cerca de
59,5% dos smartphones vendidos em todo o mundo, a Apple, com o iOS, segue a
plataforma da Google com cerca de 19,3% do mercado e por fim a Microsoft com
18,1%, conforme a Figura 2.

Figura 2 Participao no mercado mundial de sistemas operacionais

para dispositivos mveis no primeiro trimestre de 2013
Fonte: Canalys (2013)

17

2.3 ARQUITETURA ANDROID

A arquitetura da plataforma Android dividida em vrias camadas:

Applications, Application Framework, Libraries, Android Runtime e Linux Kernel
(RABELLO, 2009). A Figura 3 apresenta cada uma dessas camadas.

Figura 3 Arquitetura Android

Fonte: Rabello (2009)

Na camada Applications, est localizada uma lista de aplicaes padres

como cliente de e-mail, programa de SMS, calendrio, mapas, navegador,
gerenciador de contatos entre outros, todos escritos na linguagem Java.
J na camada Application Framework esto os componentes que permitem
com que novas estruturas sejam utilizadas para futuras aplicaes, focando a
reutilizao de cdigo. Fazem parte dessa camada os seguintes componentes:

18

Conjunto de componentes grficos que pode ser reutilizados para construir

uma aplicao, bem como listas, grids, caixas de texto, botes e at um
navegador web;
Provedores de contedo que habilitam s aplicaes acessarem dados de
outras aplicaes ou compartilhar seus prprios contedos;
Gerenciar os recursos que prove acesso a recursos no-codificados como
strings, grficos, e arquivos de layout;
Gerenciador de notificaes que permite que todas as aplicaes exibam
mensagens de alerta personalizveis na barra de status;
Um Gerenciador de atividades que controlar o ciclo de vida das aplicaes,
liberando memria dos recursos que no estejam mais sendo utilizados.

A camada logo abaixo subdivida no grupo das bibliotecas (libraries) e o

ambiente de execuo (runtime) da plataforma Android, composto pelas bibliotecas
padro e pela mquina virtual denominada Dalvik. No primeiro grupo esto as
bibliotecas escritas em C/C++, que so compostas por uma coleo de bibliotecas
que so utilizadas pela plataforma Android. Estas bibliotecas so:
Biblioteca de sistema C: uma implementao da biblioteca C padro (libc),
otimizada para dispositivos que suportam a plataforma Linux (embbededlinux);
Bibliotecas de Mdias: as bibliotecas suportam execuo e gravao da
maioria dos formatos de udio e vdeo, bem como exibio de imagens,
incluindo MPEG4, H.264, MP3, AAC, AMR, JPG, e PNG;
Gerenciador de Superfcie: gerencia o acesso ao display do dispositivo e
camadas de grficos 2D e 3D de mltiplas aplicaes;
LibWebCore: uma moderna engine de navegador web que turbina tanto o
navegador da plataforma

Android e um outro navegador qualquer

desenvolvido;
SGL: uma engine de grficos 2D;
3D libraries: uma implementao baseada na especificao OpenGL ES 1.0,
a qual utiliza tanto acelerao de hardware 3D e um avanado e otimizado
software para renderizao de modelos tridimensionais;
FreeType: renderizao em formatos bitmaps e vetoriais de fontes;

19

SQLite: uma poderosa e leve engine de banco de dados relacional disponvel

para todas as aplicaes.

No que diz respeito ao ambiente de execuo, a plataforma composta pela

mquina virtual Dalvik. Toda e qualquer aplicao em Android roda dentro de seu
prprio processo, isto , no contexto da sua instncia de mquina virtual. Esta VM foi
escrita para que os dispositivos possam suportar mltiplas mquinas virtuais
eficientemente. A Dalvik executa arquivos no formato Dalvik Executable, com
extenso .dex. Um arquivo .dex nada mais do que uma espcie de bytecodes de
Java (arquivos compilados em arquivos .class) otimizados para a Android.
Na base, est localizado o kernel Linux, que para a Android est na verso
2.6, fornecendo servios do ncleo do sistema como segurana, gerenciamento de
memria, gerenciamento de processos, pilhas de redes, etc.

2.4 GOOGLE MAPS API

A verso beta do Google Maps foi lanado em fevereiro de 2005, com sua
interface inovadora, utilizando recursos do navegador nunca explorados. Esse novo
estilo de desenvolvimento web foi dado o nome de Ajax (A New Approach to Web
Applications). Google Maps se tornou no apenas uma revoluo nas aplicaes de
mapas, mas um modelo para todas as aplicaes web. Tim OReilly (fundador da
OReilly Media) chamou este novo modelo de Web 2.0, o que ajudou a definir a
diferena entre como as aplicaes costumavam ser e o novo modelo Google
Maps (adaptado de DAVIS, 2006).
Em junho de 2005 a Google lanou a primeira verso de suas APIs,
permitindo que os usurios pudessem desenvolver aplicaes com mapas. Em abril
de 2006 lanaram a verso 2 das APIs, com novos recursos como vrios nveis de
zoom, controles adicionais aos mapas e a possibilidade de criar vrias camadas com
imagens personalizadas aos mapas.
Atualmente a API do Google Maps est na verso 3 e foi desenvolvida a
partir a do zero, como um conjunto modular de bibliotecas JavaScript focadas em

20

melhorar a velocidade de carregamento, especialmente para renderizar mapas em

navegadores de dispositivos mveis (KATARIA, 2009).

2.5 LOCALIZAO E MAPAS NO ANDROID

Uma das funcionalidades do Android que chamam ateno a integrao

com o Google Maps e a possibilidade de desenvolver aplicaes de localizao com
GPS com poucas linhas de cdigo. possvel incluir esses recursos na aplicao
utilizando as classes do pacote android.location e o Google Maps Android API.
O componente principal do framework de localizao o LocationManager
system service, que prov as APIs para determinar a localizao e a direo do
dispositivo. Para utiliz-lo, necessrio solicitar uma instncia para o sistema,
chamando o getSystemService(Context.LOCATION_SERVICE) que retorna um
handle para uma nova instncia do LocationManager.
Com as APIs de Google Maps para Android, possvel adicionar mapas nas
aplicaes baseados nos dados do Google Maps, como mostra a Figura 4. A
principal classe da API o MapView, que automaticamente acessa os servidores do
Google Maps, baixa os dados, mostra os mapas e trata os eventos de toque no
mapa. Tambm possvel utilizar a API para adicionar marcadores, polgonos,
camadas e alterar a visualizao do usurio de uma rea especfica (MAPS, 2013).

Figura 4 Aplicao utilizando Google Maps API no Android

21

2.6 WEB SERVICES

Inicialmente as aplicaes eram centralizadas em ambientes de grande

porte, como os mainframes. As aplicaes distribudas surgiram com a evoluo das
redes de computadores e tem se mostrado uma importante tcnica para
desenvolvimento e integrao de sistemas (GOMES, 2010).
Segundo definio do W3C, Web Services um programa desenvolvido
para permitir a interao mquina-mquina em uma rede. Ele possui uma interface
descrita em um formato compreensvel pela mquina (especificamente o WSDL).
Outros sistemas interagem com o Web Service atravs de mensagens SOAP
(Simple Object Access Protocol), normalmente transportados usando HTTP.
O WSDL (Web Services Descrition Language) descrito no padro XML,
uma linguagem de marcao neutra, baseada em padres W3C, o que a torna
adequada para descrever as interfaces dos Web Services, permitindo sua utilizao
por diversas linguagens de programao. O WSDL define o contedo das
mensagens e tambm onde o servio est disponvel e quais os protocolos de
comunicao usados para utilizar o servio, ou seja, define tudo que necessrio
para o cliente consumir o servio (LIMA, 2012).
Segundo Lima (2012), os trs principais componentes da arquitetura de Web
Services so:
Provedor de Servios: Responsvel pela implementao e disponibilizao do
Web Service, em um formato padro compreensvel para qualquer aplicao
que precise utilizar esse servio e tambm publicar as caractersticas sobre o
servio em um registro central disponvel.
Consumidor de servios: Qualquer um que utilize um Web Service criado por
um provedor de servios chamado de consumidor de servios. O
mecanismo para ligao e funcionalidade do Web Service pode ser obtida
atravs de uma pesquisa sobre o registro publicado.
Registro dos servios: Um registro de servios a localizao central onde o
provedor de servios pode relacionar seus Web Services, e no qual um
consumidor de servios pode pesquis-los. O registro dos servios contm
informaes como detalhes de uma empresa, quais os servios que ela
fornece e a descrio tcnica de cada um deles.

22

Conforme a Figura 5, o provedor de servios define a descrio do servio

para o Web Service e publica esta para o consumidor de servios no registro de
servios. O consumidor de servios utiliza a descrio do servio publicada para se
ligar ao provedor de servios e invocar ou interagir com a implementao do Web
Service.

Figura 5 Interao entre os elementos da arquitetura de Web Services

Fonte: Lima (2012)

2.7 PROTOCOLO SOAP

O Simple Object Access Protocol (SOAP) um protocolo baseado em XML

para troca de informaes em um sistema distribudo e descentralizado. Apesar do
protocolo poder ser utilizado em qualquer protocolo de transporte, o foco inicial do
SOAP para realizao de RPC (Remote Procedure Call) transportados por HTTP.
Outros frameworks como CORBA, DCOM e Java RMI, permitem uma funcionalidade
semelhante ao do SOAP, mas como as mensagens SOAP so descritas em um
padro XML torna independente de plataforma e linguagem de programao
(TUTORIALSPOINT, 2013).
O SOAP consiste de trs partes:
Envelope: que descreve o que est na mensagem e como process-la;
Encoding Rules: Define regras de codificao de diversos tipos de dados
como integers, floats, double ou arrays;
RPC: Define conveno de representao de chamada remota de mtodos e
suas respostas.
As mensagens SOAP so documentos XML contendo os seguintes
elementos:

23

Envelope (obrigatrio): Define o incio e o fim da mensagem

Header (opcional): Contm atributos opcionais da mensagem utilizadas no
processamento da mensagem;
Body (obrigatrio): Contm os dados XML compreendendo a mensagem a ser
enviada;
Fault (opcional): Um elemento de falta que fornece informao sobre erros
que ocorreram durante o processamento da mensagem.
A Figura 6 apresenta um exemplo de mensagem SOAP.

Figura 6 Estrutura da mensagem SOAP

Fonte: TutorialsPoint (2013)

2.8 PROTOCOLO REST

O protocolo Representational State Transfer (REST) foi idealizado por Roy

Fielding no ano de 2000 em sua dissertao de doutorado, na busca pelas melhores
prticas nos estilos de arquiteturas existentes para compor um novo estilo, o qual
ficou conhecido por REST. Essa tcnica de engenharia de software foi desenvolvida
para sistemas hipermdia distribudos como a World Wide Web (RONDON, 2013).
O REST considera cada aplicao web como um conjunto de recursos, que
representam um estado particular de um aplicativo. Ao acessar um recurso
transferido o estado (contedo), podendo alterar seu estado.
As trs principais caractersticas do REST so:
Recursos: Os recursos individuais so identificados na requisio, como
descrevendo elas nas URIs,

24

Aes: possvel aplicar vrias aes sobre um recurso. So oito mtodos

disponveis pelo protocolo HTTP, sendo os mais utilizados o PUT (cria ou
atualiza o contedo do recurso), GET (busca o contedo do recurso),
DELETE (Apaga contedo do recurso).
Contedo: utilizado por alguns protocolos o MIME TYPES para identificar
que tipo de contedo esta sendo negociado. A identificao geralmente feita
no cabealho pelo campo cujo nome Content-type.
Todo recurso inclui a informao do formato referente ao contedo, ou seja,
quando por exemplo voc receber a informao da mensagem que o contedo
(content-type) se encontra no formato JSON (application/json) voc ter que
processar a informao neste formato. A Figura 7 mostra um exemplo de objeto de
dados codificado em JSON.

Figura 7 Exemplo de informaes de livros armazenados em formato JSON

Fonte: TutorialsPoint (2013)

Normalmente o formato dos arquivos utilizados pelos servios RESTful so

JSON, XML ou YAML (RECKZIEGEL, 2006).

25

O REST resultado das melhores prticas dos seguintes estilos:

Cliente / Servidor: O servidor disponibiliza um conjunto de servios e o cliente
faz uso desses servios;

Figura 8 Arquitetura Cliente Servidor

Fonte: Rondon (2013)

Sistema em Camadas: Cada camada conhece apenas a interface da camada

superior. As camadas intermedirias podem ser utilizadas para melhorar a
escalabilidade do sistema, permitindo o balanceamento de carga de servios,
atravs de mltiplas redes;
Cache: Arquitetura que evita desperdcio de banda com a utilizao de Proxy
HTTP, que armazena as pginas solicitadas pelo cliente.

Figura 9 Modelo Cliente-Cache-Servidor

Fonte: Rondon (2013)

26

Sem estado de conexo (Stateless): Nessa arquitetura o servidor no

armazena nenhuma informao do contexto. Toda informao necessria
para atender a uma requisio deve estar contida nela mesma, tornando o
servio mais simples, no precisando levar em considerao o contexto atual
para tomar decises.

Figura 10 Modelo Cliente-Servidor sem estado de conexo

Fonte: Rondon (2013)

27

3 APLICATIVOS TURSTICOS BRASILEIROS

Neste captulo ser abordado o estudo de alguns aplicativos para

dispositivos mveis, voltados para o setor turstico brasileiro, que j foram
desenvolvidos at o presente momento e que tambm tem como objetivo auxiliar o
turista localizao dos pontos de interesse em uma determinada regio.
3.1 APLICATIVO REVIVA MANAUS

O primeiro exemplo o aplicativo Reviva Manaus, desenvolvido pela

designer de interface digital Gisely Mendona, que tendo em vista o grande potencial
turstico de Manaus como cidade sede da Copa do Mundo de 2014, desenvolveu um
aplicativo que funciona como guia turstico para os principais pontos tursticos de
Manaus, devido ao problema da capital na transmisso de informaes tursticas e
falta de placas informativas bilngues. Segundo a designer, a maior dificuldade
enfrentada durante o desenvolvimento do aplicativo foi a coleta de informaes dos
pontos tursticos da cidade (MELO, 2013).

Figura 11 Aplicativo de guia turstico de Manaus

Fonte: Melo (2013)

28

3.2 APLICATIVO CURTA CURITIBA

O segundo exemplo o aplicativo Curta Curitiba, desenvolvido para tablets

e smartphones, foi criada em parceria do Instituto Municipal de Turismo, Curitiba
Convention & Visitors Bureau, Associao Brasileira de Bares e Restaurantes do
Paran (ABRASEL-PR) e Sebrae-PR. Segundo Juliana Vosnika, presidente do
Instituto Municipal de Turismo, o aplicativo traz informaes sobre atrativos
obrigatrios, servios, hospedagem, gastronomia e orientaes de locomoo na
cidade. Juliana afirma que "Ter uma marca um diferencial competitivo, uma
estratgia de marketing para divulgar as potencialidades do destino. Em 2011,
queremos fortalec-la e internacionaliz-la, j pensando na Copa do Mundo de 2014"
(PMC, 2013).

Figura 12 Aplicativo Curta Curitiba

Fonte: Prefeitura de Curitiba (2013).

3.3 APLICATIVO MOB.URB

Em Minas Gerais, a empresa SQUADRA, lanou no dia 23 de maio de 2013

o aplicativo gratuito para celular chamado de Mob.urb, que lista mais de 10 mil
atraes tursticas da capital mineira. O aplicativo est disponvel para os aparelhos
que operam no sistema Android e iOS (iPhone), nos idiomas ingls, portugus e

29

espanhol. O ponto focal do aplicativo um mapa turstico, similar ao que os turistas

adquirem em aeroportos e hotis, mas tambm permite a montagem de roteiro, com
datas, horrios e quais locais sero visitados (SQUADRA, 2013).

Figura 13 Aplicativo Mob.urb baixado do Google Play

3.4 CONCLUSO DO CAPTULO

Muitos aplicativos esto sendo desenvolvidos para auxiliar o grande volume

de turistas que visitaro o Brasil nos prximos anos, utilizando a tecnologia para
suprir essa deficincia em informaes e em pessoas do setor turstico em todas as
cidades brasileiras. possvel observar uma caracterstica comum destes
aplicativos, que o seu desenvolvimento para uma regio especfica (um estado ou
uma cidade). Provavelmente ainda sero desenvolvidos diversos aplicativos
tursticos, at mesmo para as mesmas regies, o que na verdade um aspecto
positivo, pois o usurio pode utilizar diversos aplicativos simultaneamente no
smartphone, cada um com suas finalidades e recursos especficos, permitindo ao
usurio a liberdade de escolha.

30

4 DESENVOLVIMENTO

Este captulo apresenta as diversas etapas do desenvolvimento de software

do aplicativo denominado Curitour, que serve como um guia turstico virtual para a
cidade de Curitiba. Inicialmente realizou-se o levantamento dos requisitos de
software, seguido pela prototipagem da tela do aplicativo, modelagem UML,
obteno das coordenadas geogrficas dos pontos tursticos e do itinerrio da linha
de turismo da cidade de Curitiba, criao dos cones dos pontos tursticos e
finalmente a implementao do servio web e do aplicativo para dispositivo mvel
Android. Ao final do captulo so apresentadas as telas do aplicativo.

4.1 LEVANTAMENTO DOS REQUISITOS

O gerenciamento de requisitos pr-requisito de grande importncia para o

sucesso do projeto e a produo de um software de qualidade. Todos os projetos,
independentes do seu tamanho, podem se beneficiar da ateno dada aos
requisitos. Os requisitos de um sistema definem os servios que o sistema deve
oferecer e as restries aplicveis sua operao (CARVALHO; TAVARES, 2002).
Os requisitos funcionais so requisitos que expressam funes ou servios
que um software deve ou pode ser capaz de executar ou fornecer. As funes ou
servios so geralmente processos que utilizam entradas para produzir sadas. Os
requisitos no funcionais so requisitos que declaram restries ou atributos de
qualidade no processo de desenvolvimento de software (CYSNEIROS, 2001).
Neste contexto, os requisitos funcionais (RF) do aplicativo Curitour so:

Cdigo
RF01

RF02

Descrio
O sistema dever possuir entrada de dados para autenticao
atravs de usurio e senha
Deve mostrar o mapa da cidade de Curitiba com as ruas e o nome
das ruas
O sistema dever possuir trs camadas no mapa, a camada que

RF03

mostra os pontos tursticos, camada que mostra o itinerrio da

linha turismo e a camada de pontos de parada da linha turismo

31

RF04

O usurio poder habilitar e desabilitar cada uma das camadas no

mapa
O usurio poder buscar rapidamente um ponto turstico atravs

RF05

de uma lista ordenada por ordem alfabtica com os nomes dos

pontos tursticos

RF06

RF07

RF08

O usurio poder obter informaes detalhadas ao clicar sobre o

cone do ponto turstico
O aplicativo dever permitir o controle do mapa, como mover,
aproximar e afastar o mapa com movimentos de toque na tela
O sistema dever mostrar a posio atual do dispositivo mvel no
mapa

Os requisitos no funcionais (RNF) so:

Cdigo

Descrio

RNF01

A aplicao dever ser simples e intuitiva para o usurio

RNF02

A aplicao dever responder rapidamente aos comandos na tela

O sistema dever informar o usurio que deve aguardar, atravs

RNF03

de cone animado ou mensagem na tela, durante operaes

demoradas

RNF04

A aplicao dever tratar erros inerentes ao sistema, como falha

na conexo de dados e na localizao geogrfica do dispositivo

RNF05

A aplicao deve ser funcional em smartphones e tablets

RNF06

O aplicativo ser executado em sistema operacional Android

RNF07

Campo de senha deve ser mascarado

32

4.2 DESCRIO DO PROTTIPO

O prottipo do aplicativo Curitour foi desenvolvido para funcionar em

smartphones e tablets com plataforma mnima Android 3.1 (Honeycomb), sendo
necessria uma conexo de dados com a Internet, para poder utilizar os mapas e
tambm para autenticar e receber os dados do servidor do aplicativo.
O modelo adotado para o desenvolvimento da aplicao se baseia no
modelo cliente-servidor, onde diversos clientes podem acessar simultaneamente o
servidor, que busca as informaes em um banco de dados, para obter dados
atualizados sobre os pontos tursticos, rota da linha de turismo e os pontos de
parada, permitindo uma maior flexibilidade na incluso e alterao dos dados
fornecidos ao usurio. A Figura 14 apresenta o modelo de aplicao cliente-servidor.

Figura 14 Modelo cliente-servidor

O aplicativo mostra o mapa da cidade de Curitiba e seus principais pontos

tursticos, atravs de cones que representam os pontos de interesse. Ao clicar no
ponto turstico exibido ao usurio mais informaes detalhadas sobre o local. O
usurio pode obter sua localizao atual no mapa atravs dos Servios de
localizao do Google, como Wi-Fi e redes mveis, e tambm atravs do GPS,
sendo recomendada a utilizao deste, pois permite uma melhor localizao. O
aplicativo ainda permite buscar um ponto turstico rapidamente atravs de uma lista,
que posiciona o mapa sobre o local desejado. Tambm possvel a exibio do
itinerrio da linha de turismo de Curitiba e seus pontos de parada. A utilizao das
novas funcionalidades do Google Maps API verso 2 para Android permite ao
usurio funcionalidades como inclinao, zoom e rotao do mapa.

33

Este aplicativo tem o objetivo de ser simples, interativo, fcil e ao mesmo

tempo til ao turista, que tenha interesse em conhecer melhor os pontos tursticos da
cidade de Curitiba sem a necessidade de um guia turstico. A Figura 15 exibe uma
tela prottipo do aplicativo desenvolvido no software Evolus Pencil.

Figura 15 Prottipo do aplicativo em Evolus Pencil

4.3 MODELAGEM

A modelagem do sistema faz parte do processo de desenvolvimento de

software, no contexto da Engenharia de Software. Utilizou-se na modelagem o
padro UML, por ser uma ferramenta que auxilia na modelagem de sistemas, do
mais simples aos mais complexos, mais adequado orientao a objetos e
proporciona um padro para a preparao de planos de arquitetura de projeto de
sistemas, incluindo aspectos conceituais, como processos de negcios e funes de
sistemas, alm de itens concretos, como as classes escritas em determinada
linguagem de programao, esquema de banco de dados e componentes de
softwares reutilizveis (MEDEIROS, 2004).

34

4.3.1 Diagrama de Caso de Uso

O Caso de Uso representa a interao do usurio com o sistema. A Figura

16 apresenta o Caso de Uso do prottipo do aplicativo Curitour, onde o usurio
inicialmente se autentica no servidor, e posteriormente possui trs opes de
interaes com o mapa.

Figura 16 Diagrama de Caso de Uso

O fluxo de eventos abaixo mostra a sequncia dos eventos do caso de uso

da Figura 16:
1.

Autentica usurio

2.

Se usurio autenticado

2.1

Mostra mapa de Curitiba com as camadas selecionadas

2.2

Se clicar no ponto turstico

2.2.1
2.3
2.3.1

Mostra informaes detalhadas do ponto turstico

Se clicar em configuraes
Mostra lista de seleo das camadas: pontos tursticos, itinerrio da
linha de turismo e pontos de paradas da linha de turismo

2.4
2.4.1

Se clicar em Busca
Mostra lista dos pontos turstico em ordem alfabtica para localizao
rpida no mapa

35

4.3.2 Diagrama de Classes

No diagrama de classes so apresentadas as classes utilizadas no

desenvolvimento do aplicativo, a estrutura de classes, com seus atributos e mtodos
e a relao entre as classes, conforme a Figura 17.

Figura 17 Diagrama de Classes

36

4.3.3 Diagrama de Sequncia

O diagrama de sequncia representa as interaes dos autores (usurio,

aplicativo e banco de dados), o envio de mensagens de solicitao e respostas de
retorno entre elas, em uma linha de tempo conforme mostra as Figuras 18 e 19.

Figura 18 Diagrama de Sequencia de Login

Figura 19 Diagrama de Sequencia de acesso ao Banco de Dados

37

4.3.4 Coordenadas Geogrficas dos marcadores

Para obter os dados de latitude e longitude dos pontos tursticos, foi utilizado
o Google Maps pelo Navegador com o recurso adicional Marcador do LatLng, que
pode ser habilitada atravs das opes de ferramentas do Google Labs, conforme a
Figura 20.

Figura 20 Utilizao do LagLng no Google Maps

As informaes sobre o percurso percorrido pela linha de nibus de turismo

de Curitiba e seus pontos de parada foram obtidos atravs do sistema de Itinerrios
do site da URBS, mostrado na Figura 21 (URBS, 2013).

38

Figura 21 Itinerrio da Linha de Turismo de Curitiba

Referncia: URBS (2013)

Todos os dados das coordenadas geogrficas dos pontos tursticos, pontos

de paradas do nibus da linha de turismo e itinerrio do nibus foram inseridos no
Banco de Dados em suas respectivas tabelas.

4.3.5 Desenvolvimento dos Marcadores

Os cones dos marcadores dos pontos tursticos utilizados no aplicativo

foram criados a partir de fotos reais e utilizado o software livre de edio de imagens
GIMP verso 2.8 (The GNU Image Manipulation Program) que permite recortar,
redimensionar e gerar imagens no formato PNG com efeito de transparncia, como
mostra a Figura 22. O efeito de transparncia no cone importante, pois resulta em
uma melhor aparncia ao ser apresentado no mapa para o usurio.

39

Figura 22 Edio dos cones com o programa GIMP

4.4 IMPLEMENTAO

4.4.1 Banco de Dados

As informaes coletadas dos pontos tursticos, percurso do itinerrio e as

paradas da linha de turismo foram armazenadas em uma base de dados Mysql, para
isto utilizou-se o Mysql Server verso 5.6.
Os dados foram organizados em quatro tabelas, conforme Figura 23.

Figura 23 Modelo do Banco de Dados

40

A tabela tb_usuarios armazena as informaes de autenticao dos

usurios. A tabela tb_pontosturisticos armazena as informaes sobre os pontos
tursticos, sendo que nos campos foto e o cone so armazenados o nome do
arquivo a ser buscado no servidor. A tabela tb_paradas armazena o nmero da
parada, nome e posio geogrfica das paradas da linha de turismo, e finalmente a
tb_itinerario armazena todos os pontos necessrios para desenhar o itinerrio da
linha de turismo no mapa.

4.4.2 Servidor

Para o desenvolvimento do web service, utilizou-se o ambiente de

desenvolvimento Eclipse Java EE Juno Release 2 e o servidor web Apache Tomcat
7.0. Para criar o servio Web RESTfull foi utilizado o framework

Jersey, que

cdigo-livre e permite separar os detalhes de baixo nvel da comunicao clienteservidor, sendo este uma referncia de implementao de JAX-RS, tornando fcil o
desenvolvimento de servios RESTfull com Java (ORACLE, 2013).
Optou-se por utilizar o formato JSON para realizar a troca de informaes
entre o cliente o servidor, por ser um protocolo mais simples, mais compacto que
XML e por j possuir suporte nativo no Android atravs do pacote org.json.
Para utilizar este framework necessrio criar no Eclipse um Dynamic Web
Project, copiar os arquivos de biblioteca para o diretrio /WebContent/WEB-INF/lib
da aplicao, e incluir no arquivo web.xml definies para redirecionar todas as
requisies REST para o servlet Jersey do pacote java do projeto, conforme mostra
a Figura 24. Tambm foi adicionado nas bibliotecas o pacote mysql-connector-java
para conexo com o banco de dados Mysql.

41

Figura 24 Implementao de um servio web RESTful

Os recursos so as pea-chave que compe um servio web RESTful e so

identificados por Identificadores globais, normalmente utilizando URIs. Os recursos
so manipulados atravs de requisies HTTP, atravs dos mtodos GET, POST,
PUT e DELETE (IBM, 2009). Em JAX-RS os recursos so implementados com uma
anotao @Path que compe um identificador. A anotao @Get informa que o
mtodo ser acionado por uma requisio HTTP GET. A anotao @Produces
informa o MIME type da resposta HTTP, no caso deste trabalho utiliza-se o tipo
JSON. A Figura 25 mostra o trecho do cdigo que realiza a pesquisa no o banco de
dados e converte o resultado em um JSON Array.

package com.curitour.rest.getdata;

/* URL: http://localhost:8080/com.curitour.rest/api/v1/getmarkers */
@Path("/v1/getmarkers")
public class GetMarkers {
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response returnAllPcParts() throws Exception {

PreparedStatement query = null;

Connection conn = null;
String returnString = null;
Response rb = null;

42

try {
// Conexo com o Banco de Dados
conn = ConnectionFactory.getConnection();
query = conn.prepareStatement("select * from tb_pontosturisticos");

// Executa a Query
ResultSet rs = query.executeQuery();

// Cria o objeto JSON Array

ToJSON converter = new ToJSON();
JSONArray json = new JSONArray();

// Converte o ResultSet em um JSON Array

json = converter.toJSONArray(rs);
query.close(); //close connection

// Envia resposta ao cliente

returnString = json.toString();
rb = Response.ok(returnString).build();
}

Figura 25 Exemplo de converso de dados para JSON

Na Figura 26 mostrado um exemplo de resposta do servidor no formato

JSON atravs do navegador.

Figura 26 Resposta do servidor web no formato JSON

A autenticao realizada no web server atravs de um servlet Java, que

verifica os parmetros user e password recebidos na requisio HTTP GET. Aps
esta etapa, o servlet acessa o banco de dados e verifica se o usurio e senha

43

existem e se correspondem com o valor correto, retornando uma mensagem de ok

confirmando a autenticao. A Figura 27 mostra o trecho do cdigo do servlet que
executa a verificao de usurio e senha.

Figura 27 Trecho do cdigo do servlet de autenticao

4.4.3 Aplicativo Android

Para o desenvolvimento do prottipo para Android, utilizou-se o SDK ADT

Bundle for Windows, que consiste de um pacote de software que contm uma
verso do Eclipse adaptada para desenvolvimento Android junto com o SDK
(Software Development Kit) do Android e o emulador AVD (Android Virtual Devices).

4.4.3.1 Biblioteca Google Maps API Android

Para desenvolver aplicativos Android utilizando Google Maps necessrio

utilizar obrigatoriamente a biblioteca do Google Maps API verso 2, pois a API
verso 1 foi oficialmente removida em 03 de dezembro de 2012, no sendo mais

44

possvel desenvolver novos projetos com a verso 1, porm os aplicativos j

desenvolvidos continuaro a funcionar nos dispositivos (MAPS, 2013).
Segundo o site do Google Developers (MAPS, 2013), para utilizar a
biblioteca do Google Maps verso 2 no Android necessrio executar algumas
etapas, descritas resumidamente abaixo:

1) Instalar o Google Play Services no Android SDK;

2) Criar uma chave de acesso aos servidores do Google Maps. Para obter a
chave necessrio registrar o projeto no site da Google API Console e
obter um certificado de assinatura para o seu aplicativo. A obteno da
chave gratuita e pode ser reutilizada em todas as aplicaes do
desenvolvedor, suportando ilimitado nmero de usurios;
3) Especificar as configuraes no arquivo AndroidManifest.xml;
4) Adicionar um mapa no aplicativo;
5) Publicar a aplicao.
Essa nova verso da biblioteca de mapas traz inmeros recursos adicionais,
mas em contrapartida no possua suporte ao emulador AVD (Android Virtual
Devices) at maio de 2013, sendo necessrio o desenvolvimento do aplicativo
diretamente em um dispositivo real. O dispositivo utilizado para o desenvolvimento
do Curitour foi um smartphone modelo Samsung Galaxy S2 I9100 com sistema
operacional Android verso 4.0.4.

4.4.3.2 Activities

No desenvolvimento de aplicaes Android uma das classes mais

importantes a classe Activity, responsvel por controlar os eventos da tela e definir
qual View ser responsvel por desenhar a interface grfica do usurio (LECHETA,
2010). No desenvolvimento do prottipo foram desenvolvidas algumas Activities,
descritas abaixo:
Activity de Abertura: Mostra uma imagem de abertura do aplicativo.
Activity de Autenticao: Mostra a tela para o usurio inserir usurio e senha
e um boto para efetuar a autenticao. Ao clicar no boto esta Activity verifica se os
campos esto preenchidos corretamente, e envia os dados para validao no

45

servidor. Utilizou-se da classe AsyncTask do Android,

pois permite executar

operaes em background e alterar os componentes da interface sem necessidade

de utilizao de threads ou handlers.
A Figura 28 mostra um trecho do cdigo que realiza a autenticao no
servidor, chamando o mtodo WebServiceHelper.autentica(), que realiza uma
conexo HTTP com o servlet de autenticao no web server, passando como
parmetros o usurio e senha do usurio.

Figura 28 Trecho do cdigo da Activity de autenticao

Activity de Mapa: Esta Activity possui o componente do Google Maps dentro

de um elemento fragment, onde ser exibido o mapa, como mostra o arquivo XML,
na Figura 29, com as configuraes desta View.

Figura 29 Cdigo XML da Interface de Mapa

46

No mtodo onCreate() desta activity executado uma AsyncTask que

chama a classe JsonDAO no seu mtodo doInBackground, conforme a Figura 30.

Figura 30 Trecho do cdigo da Activity do Mapa

A classe JsonDAO foi desenvolvida para realizar a conexo HTTP com o

servio web RESTful e converter os dados do formato JSON Array em um ArrayList
de Objetos de Java Antigo Simples (POJO) que armazenam localmente os dados
dos Pontos Tursticos, Itinerrio e Paradas do nibus. Uma vez obtido os dados do
servidor, estes so mostrados no mapa em sua localizao correta com seu cone
correspondente.
A Figura 31 mostra o trecho de cdigo do mtodo que insere os marcadores
dos pontos tursticos do mapa com seu cone personalizado.

47

Figura 31 Trecho do cdigo que insere os marcadores no mapa

Esta Activity possui um menu com duas opes, a de Configuraes e

Busca rpida.
Activity de Configuraes: Esta Activity estende a classe PreferenceActivity
para a criao de um menu de configuraes atravs de um arquivo XML, que
permite o usurio selecionar as camadas a serem mostradas no mapa: os pontos
tursticos, o itinerrio e/ou pontos de parada da linha de turismo. A classe
PreferenceActivity armazena as informaes de configuraes de forma persistente
e que podem ser acessadas por qualquer parte da aplicao atravs da classe
SharedPreferences. A Figura 32 mostra o arquivo XML do menu de configuraes.

Figura 32 Cdigo XML do menu de configuraes

48

Activity de Detalhes: Esta tela chamada pela Activity de mapa, quando o

usurio clica em mostrar detalhes do ponto turstico.
Activity de Busca: Esta Activity recebe a lista de pontos tursticos pelo nome,
organizados em ordem alfabtica, para localizar rapidamente a localizao no mapa
de um ponto turstico.

4.4.4 Telas do aplicativo

A primeira tela (Figura 33) mostra a imagem de abertura do aplicativo

Curitour.

Figura 33 Tela de abertura do aplicativo Curitour

49

A Figura 34 mostra a tela de autenticao do usurio.

Figura 34 Tela de autenticao de usurio

A tela principal a do mapa exibido na Figura 35, que mostra os pontos

tursticos da cidade de Curitiba, o itinerrio e as paradas da linha de turismo.

Figura 35 Tela do aplicativo com todas camadas habilitadas

50

Ao clicar em um ponto turstico, exibido seu nome conforme a Figura 36.

Figura 36 Balo de informao aps o marcador ser clicado

O usurio pode ento obter informaes detalhadas sobre o ponto turstico

clicando no balo, que trar uma nova janela com a foto e informaes mais
detalhadas sobre o ponto de interesse, conforme visto na Figura 37.

Figura 37 Tela de informaes detalhadas do ponto turstico

51

O menu permite entrar nas configuraes ou realizar uma busca rpida,

conforme Figura 38.

Figura 38 Tela apresentando as opes do menu

Nas configuraes o usurio pode selecionar as camadas a serem exibidas

no mapa conforme a Figura 39.

Figura 39 Tela de seleo de camadas

52

Se o usurio estiver interessado apenas em ver o itinerrio e os pontos de

parada o mapa ficar conforme a Figura 40.

Figura 40 Mapa com o percurso da linha de turismo

Selecionando a busca rpida ser exibido ao usurio uma lista com os

nomes dos pontos tursticos, e ao selecionar algum item na lista o mapa move-se
automaticamente para o ponto desejado, conforme a Figura 41.

Figura 41 Lista de seleo de ponto turstico

53

5 CONCLUSO

A cidade de Curitiba possui diversos pontos tursticos como parques, praas

e museus, possuindo tambm uma linha de nibus especial que circula nos
principais pontos, mas sem o acompanhamento de um guia turstico. O prottipo do
aplicativo Curitour prope suprir essa lacuna, servir como um guia turstico virtual,
atravs de um aplicativo que pode ser instalado em um smartphone ou tablet com
sistema operacional Android.
Diversos aplicativos vm sendo desenvolvidos para o setor turstico
brasileiro, para atender a demanda nacional de turistas, mas tambm visando
atender a demanda de turistas estrangeiros que visitaro o Brasil nos prximos
anos. Esses aplicativos ajudam os turistas a obterem as informaes corretas, como
localizao do ponto turstico, meios de acesso, horrios de funcionamento, sem a
necessidade de um agente de turismo, permitindo realizar seu prprio roteiro
turstico.
Durante o desenvolvimento surgiram algumas dificuldades, sendo uma delas
a adaptao do cdigo desenvolvido inicialmente com a biblioteca do Google Maps
para Android verso 1, que foi descontinuada, sendo substituda pela verso 2 que
incompatvel com a primeira.
O sistema desenvolvido neste trabalho mostra que possvel a utilizao de
um aplicativo para auxiliar os turistas a obterem sua localizao atual na cidade de
Curitiba, que permite buscar rapidamente os pontos tursticos, visualizar o itinerrio
e os pontos de parada da linha de turismo, permitindo ao usurio montar seu prprio
roteiro turstico sem a necessidade um guia na cidade de Curitiba.
Utilizou-se no desenvolvimento do aplicativo os conceitos aprendidos
durante o curso de especializao como web services, programao Java,
comunicao cliente-servidor, utilizao dos mapas da Google e localizao
geogrfica.

54

6 TRABALHOS FUTUROS

O prottipo do aplicativo se mostrou funcional, atendendo a todos os

requisitos propostos. Este aplicativo pode ser melhorado e adicionado diversos
recursos, como tambm pode ser uma base para o desenvolvimento de aplicativos
para outras cidades brasileiras.
Segue abaixo uma lista de sugestes de melhorias para o desenvolvimento
de trabalhos futuros:
Internacionalizao para outros idiomas;
Layout alternativo para aproveitar a tela maior de tablets;
Realizar integrao do aplicativo com redes sociais tais como Facebook e
Twitter;
Permitir que o usurio seja visvel a outros usurios no mapa;
Permitir comunicao entre usurios;
Permitir favoritar e dar nota aos pontos tursticos;
Incluso de novas camadas no mapa como bares, restaurantes, hotis, etc...
Permitir que a aplicao fale as informaes sobre o ponto turstico em vrios
idiomas;
Mostrar o tempo restante para chegada do prximo nibus no ponto de
parada da linha de turismo;
Utilizao dos mapas de forma off-line;
Validao do aplicativo com usurios.

55

7 REFERNCIAS

CANALYS. Smart mobile device shipments exceed 300 million in Q1 2013.

Disponvel em: <http://www.canalys.com/static/press_release/2013/canalys-pressrelease-090513-smart-mobile-device-shipments-exceed-300-million-q1-2013_0.pdf>.
Acesso em: 25 Maio 2013.

CARVALHO, Ana Elizabete; TAVARES, Helena Cristina. Viso geral sobre

requisitos. Disponvel em: <http://www4.serpro.gov.br/imprensa/publicacoes/tema1/tematec/2002/ttec60>. Acesso em: 12 Out. 2013.

CYSNEIROS, Luiz Marcio. Requisitos No Funcionais: Da Elicitao ao Modelo

Conceitual. PUC-Rio, 2001.

DAVIS, Scott. Google Maps API, V2: Adding Where To Your Applications.
Raleigh: The Pragmatic Bookshelf, 2006.

EMBRATUR. Eventos Internacionais no Brasil: Resultados 2003-2009, desafios

para 2020. Disponvel em:
<http://www.turismo.gov.br/export/sites/default/turismo/o_ministerio/publicacoes/dow
nloads_publicacoes/RELATORIO_EVENTOS_2003_2009.pdf>. Acesso em:
20 Maio 2013.

FERRARO, Richard; AKTIHANOGLU, Murat. Location-Aware Applications. Shelter

Island: Manning Publications, 2011.

GOMES, Daniel Adorno. Web Services SOAP em Java. [s.l.]: Novatec, 2010.

IBM. Build a RESTful Web service using Jersey and Apache Tomcat. Disponvel
em: <http://www.ibm.com/developerworks/library/wa-aj-tomcat/>. Acesso em:
20 Jul. 2013.

KATARIA, Mickey. Announcing Google Maps API v3. Geo Developers Blog.
Disponvel em: <http://googlegeodevelopers.blogspot.com.br/2009/05/announcinggoogle-maps-api-v3.html>. Acesso em: 26 Maio 2013.

LECHETA, Ricardo. Google Android: Aprenda a criar aplicaes para

dispositivos mveis com o Android SDK. 2. ed. So Paulo: Novatec, 2010.

56

LIMA, Jean Carlos Rosrio. WEB SERVICES ( SOAP X REST ). FATEC-SP, 2012.

MAPS, GOOGLE. Android Google Maps API v2. Disponvel em:

<https://developers.google.com/maps/>. Acesso em: 1 Jul. 2013.

MEDEIROS, Ernani Sales de. Desenvolvendo software com UML 2.0: definitivo.
So Paulo: Pearson Makron Books, 2004.

MELO, Tiago. Designer projeta aplicativo como guia de pontos tursticos, em

Manaus. Disponvel em:
<http://g1.globo.com/am/amazonas/noticia/2012/12/designer-projeta-aplicativocomo-guia-de-pontos-turisticos-em-manaus.html>. Acesso em: 10 Maio 2013.

MORGAN, Melissa Johnson; SUMMERS, Jane. Marketing Esportivo. Thomson Le.

So Paulo: [s.n.], 2008.

NEVES, Itamar Abib (UTP); SEMPREBOM, Elder (UFPR); LIMA, Andra de

Albuquerque (PUCPR). Copa 2014: expectativa e receptividade dos setores
hoteleiro, gastronmico e turstico na cidade de Curitiba. In: SIMPOI 2011. So
Paulo: SIMPOI, 2011, p. 16. Disponvel em:
<http://www.simpoi.fgvsp.br/arquivo/2011/artigos/E2011_T00180_PCN69256.pdf>.
Acesso em: 20 Jul. 2013.

OHA. Open Handset Alliance. Disponvel em:

<http://www.openhandsetalliance.com/android_overview.html>. Acesso em:
25 Maio 2013.

ORACLE. RESTful Web Services in Java. Disponvel em: <https://jersey.java.net/>.

Acesso em: 20 Jul. 2013.

PMC. Aplicativo Curta Curitiba auxilia visitantes. Disponvel em:

<http://www.curitiba.pr.gov.br/noticias/noticia.aspx?codigo=22402>. Acesso em:
15 Maio 2013.

RABELLO, R. R. Android: um novo paradigma de desenvolvimento mvel.

Disponvel em: <http://www.cesar.org.br/site/files/file/WM18_Android.pdf>. Acesso
em: 10 jul. 2013.

57

RECKZIEGEL, Mauricio. Entendendo os WebServices. Disponvel em:

<http://imasters.com.br/artigo/4245/web-services/entendendo-os-webservices/>.
Acesso em: 7 Maio 2013.

RONDON, Thiago. ARQUITETURA REST E O SERVIO WEB RESTFUL.

Disponvel em: <http://sao-paulo.pm.org/artigo/2010/RESTful>. Acesso em:
7 Maio 2013.

SQUADRA. Lanado em BH aplicativo de celular com mais de 10 mil atraes

tursticas. Disponvel em:
<http://www.squadra.com.br/noticias/MobUrb_noticia_O_Tempo.html>. Acesso em:
1 Jun. 2013.

TUTORIALSPOINT. SOAP. Disponvel em: <http://www.tutorialspoint.com/soap/>.

Acesso em: 7 Jun. 2013.

URBS. Ininerrios: Rede Integrada de Transporte. Disponvel em:

<http://www.urbs.curitiba.pr.gov.br/PORTAL/itinerarios>. Acesso em: 9 Jul. 2013.