PONTIFCIA UNIVERSIDADE CATLICA DO RIO DE JANEIRO

Desenvolvimento de Aplicativo para Smartphone com a Plataforma Android

Rafael J. Werneck de A. Martins

PROJETO FINAL DE GRADUAO

CENTRO TCNICO CIENTFICO - CTC DEPARTAMENTO DE INFORMTICA Curso de Graduao em Engenharia de Computao

Rio de Janeiro, Dezembro de 2009

Rafael J. Werneck de A. Martins

Desenvolvimento de Aplicativo para Smartphone com a Plataforma Android

Projeto final apresentado ao Curso Engenharia de Computao como requisito parcial para a obteno do ttulo de Engenheiro de Computao.

Orientador: Prof. Bruno Feij

Rio de Janeiro Dezembro de 2009.

Agradeo aos meus pais e irmo, pelo incentivo e dedicao, e ao meu orientador, Prof. Bruno Feij, pelo apoio e conhecimento transmitido.

Resumo
Martins, Rafael. Feij, Bruno. Desenvolvimento de Aplicativo para Smartphone com a Plataforma Android. Rio de Janeiro, 2009. 50. Relatrio Final de Projeto Final de Graduao Departamento de Informtica. Pontifcia Universidade Catlica do Rio de Janeiro. O presente trabalho destaca as principais qualidades da plataforma Android e como suas caractersticas podem ser exploradas no desenvolvimento de aplicativos para smartphones equipados com ela. So explicados no texto alguns detalhes da plataforma como sua arquitetura, componentes fundamentais de suas aplicaes, interface com o usurio, recursos, internacionalizao, armazenamento de informaes, mapas, localizao e como publicar uma aplicao. Faz parte do trabalho ainda, um aplicativo real para Android, cuja implementao est detalhada, que exibe rotas, capturadas atravs de GPS, em um mapa, utilizando a API do Google Maps.

Palavras-chave Android, Google, GPS, mapa, smartphone.

Abstract
Martins, Rafael. Feijo, Bruno. Application Development for Smartphones with Android. Rio de Janeiro, 2009. 50. Final Report of Graduation Project Departamento de Informtica. Pontifcia Universidade Catlica do Rio de Janeiro. This work highlights the main features of the Android platform and how they can be used to develop applications for Android smartphones. In the text there are some details of the platform, like architecture, key components of an application, user interface, resources, internationalization, data storage, maps, location and how to publish an application. The work also includes a real application whose implementation is detailed. The application shows routes on top of a map and was created using GPS and the Google Maps API.

Keywords Android, Google, GPS, map, smartphone.

Sumrio
1. Introduo ....................................................................................................... 1 1.1 O surgimento do Android ........................................................................... 1 1.2 Objetivos deste trabalho ............................................................................ 2 2. Estado da arte ................................................................................................. 4 3. Sobre a plataforma Android ............................................................................. 5 3.1 Arquitetura ................................................................................................. 5 3.2 Conceitos fundamentais das aplicaes .................................................... 6 3.3 Interface com o usurio ............................................................................. 8 3.4 Recursos e internacionalizao ............................................................... 11 3.5 Armazenamento de informaes ............................................................. 11 3.6 Mapas e localizao ................................................................................ 12 3.7 Publicando uma aplicao ....................................................................... 13 3.8 Consideraes importantes ..................................................................... 13 4. Experincias com o Android .......................................................................... 15 4.1 Atividades realizadas ............................................................................... 15 4.2 Avaliaes e recomendaes .................................................................. 16 5. Projeto e especificao do sistema ............................................................... 21 6. Implementao e avaliao ........................................................................... 24 6.1 Como a aplicao foi implementada ........................................................ 24 6.2 Testes realizados .................................................................................... 33 7. Consideraes finais ..................................................................................... 36 Referncias Bibliogrficas ................................................................................. 37 Apndices ......................................................................................................... 39 A1: Cronograma ............................................................................................ 40 A2: Banco de dados (modelo e comandos SQL) ........................................... 41 A3: Texto da tela de ajuda ............................................................................. 42 A4: Lista de todos os arquivos da aplicao .................................................. 43 A5: Especificaes do dispositivo real utilizado para testes........................... 44

Lista de Figuras
Figura 1: Logotipo do Android ............................................................................. 1 Figura 2: Smartphone HTC T-Mobile G1 ............................................................. 2 Figura 3: Arquitetura da plataforma Android ........................................................ 5 Figura 4: Ciclo de vida de uma atividade ............................................................. 8 Figura 5: rvore de objetos View e ViewGroup ................................................... 9 Figura 6: Menu de opes, submenu e menu de contexto ................................ 10 Figura 7: Notificao - Toast, barra de estado e dilogo ................................... 10 Figura 8: Dilogo ANR ...................................................................................... 14 Figura 9: Aplicativo Notepad, criado para testes ............................................... 17 Figura 10: Jogo Sokoban, criado para testes .................................................... 18 Figura 11: Aplicativo no dispositivo real............................................................. 20 Figura 12: Diagrama de estados do monitoramento .......................................... 21 Figura 13: Esquema do banco de dados ........................................................... 22 Figura 14: Tela inicial nos tamanhos HVGA (retrato e paisagem) e QVGA ....... 25 Figura 15: Menu de opes modificado dinamicamente .................................... 25 Figura 16: Tela que exibe a rota atual (carregando e ativa) ............................... 26 Figura 17: Notificao na barra de estado (GPS disponvel) ............................. 27 Figura 18: Tela inicial ........................................................................................ 28 Figura 19: Dilogo de progresso (Salvando...) .................................................. 29 Figura 20: Telas de listagem, de resumo e de mapa ......................................... 29 Figura 21: Tela de preferncias ......................................................................... 30 Figura 22: Telas de ajuda e de informaes sobre a aplicao ......................... 31 Figura 23: Assistente de exportao ................................................................. 32 Figura 24: Emulador .......................................................................................... 33 Figura 25: Ferramenta DDMS ........................................................................... 34 Figura 26: Smartphone Samsung Galaxy .......................................................... 34

1. Introduo
1.1 O surgimento do Android O mundo da telefonia mvel nunca esteve to aquecido quanto s demandas do mercado consumidor. De acordo com a consultoria IDC, as fabricantes de smartphone (telefone celular com funcionalidades avanadas) distriburam 43,3 milhes de dispositivos durante o terceiro trimestre de 2009, nmero 4,2% superior aos 41,5 milhes do mesmo perodo de 2008 (Hamblen, 2009). J atentas a este mercado em constante crescimento, diversas empresas, entre elas a Google, se juntaram para formar, em novembro de 2007, a OHA (Open Handset Alliance) e lanar a plataforma Android (OHA, 2009a). O Android, como a plataforma tambm chamada, um conjunto completo de softwares para dispositivos mveis que inclui sistema operacional e importantes aplicativos. um projeto de cdigo aberto e foi idealizado para aparelhos com especificaes diversas (OHA, 2009b). Ele suporta tecnologias presentes nos smartphones mais modernos atualmente como touchscreen (tela sensvel ao toque) e GPS (Global Positioning System Sistema de Posicionamento Global; permite localizar a posio em termos de latitude e longitude da Terra). O logotipo do Android exibido na Figura 1 (OHA, 2009c).

Figura 1: Logotipo do Android

A plataforma inclui, dentre outros aplicativos instalados nativamente, navegador, discador, galeria de imagem, tocador de msica, gerenciador de contatos, calculadora, alarme e mensageiro (OHA, 2009c). E, assim como aquelas que competem em seu mercado, a Android permite que aplicaes sejam criadas por terceiros (Arima, 2009a). Porm, nela ainda possvel substituir facilmente as aplicaes nativas e acessar todos os recursos utilizados por elas (Meier, 2009).

O Android conta com uma loja virtual, a Android Market, que possibilita ao desenvolvedor disponibilizar uma aplicao gratuitamente para o usurio final ou lucrar com a sua venda, em um modelo semelhante AppStore, loja virtual de aplicativos para o iPhone, smartphone da marca Apple. (Arima, 2009a). A plataforma Android possui tambm outras caractersticas interessantes, como a fcil integrao com servios oferecidos pelo Google. Alm disto, diversas ferramentas esto disponveis gratuitamente para os seus

desenvolvedores (Meier, 2009). Estes temas sero abordados em mais detalhes no decorrer deste trabalho. O primeiro smartphone equipado com o Android, o T-Mobile G1 (veja Figura 2), fabricado pela HTC, foi lanado em setembro de 2008 nos Estados Unidos e, seis meses aps o seu lanamento, j havia vendido 1 milho de unidades (Gohring, 2009). Outras importantes empresas, entre elas Samsung e Motorola, j anunciaram dispositivos equipados com a plataforma

(Machado, 2009). O Android foi anunciado no Brasil, muito recentemente, em setembro de 2009 (Arima, 2009b).

Figura 2: Smartphone HTC T-Mobile G1

1.2 Objetivos deste trabalho Este trabalho objetiva destacar as principais caractersticas do Android e demonstrar como elas podem ser utilizadas atravs da criao de uma aplicao que explore os recursos desta plataforma. Assim, ser til para os desenvolvedores interessados nela, que podem utilizar o projeto como uma fonte de estudos. Vale ressaltar que algumas consideraes feitas so aplicveis tambm no desenvolvimento de aplicativos para dispositivos mveis em geral.

Visando experimentar as capacidades da plataforma, foi desenvolvido um aplicativo para smartphone com Android 1.5 utilizando reconhecimento de interao atravs de touchscreen (tela sensvel ao toque), GPS (Global Positioning System Sistema de Posicionamento Global; permite localizar a posio em termos de latitude e longitude da Terra) e acelermetro (dispositivo que detecta movimentos). Alm destas funcionalidades, que esto presentes nos dispositivos mais modernos existentes atualmente, peculiaridades do Android foram utilizadas, como, por exemplo, a fcil integrao com o aplicativo de mapas Google Maps. Para alcanar o objetivo do trabalho, muito do que foi aprendido durante o curso de graduao foi aplicado. Por exemplo, a linguagem de programao utilizada Java (OHA, 2009c), ento os conceitos de orientao a objetos foram importantes. Alm disto, a plataforma Android dispe de um sistema de banco de dados SQLite para guardar informaes de aplicaes (OHA, 2009c). Esta funcionalidade foi explorada e, portanto, o conhecimento na rea de banco de dados fez diferena. Alm destes, as prticas de boa programao, tcnicas de modelagem, estruturas de dados, noes de lgica e algoritmos e princpios de interao com usurio e de segurana da informao influenciaram positivamente para um melhor produto final.

2. Estado da arte
Hoje existem muitas opes de sistemas operacionais para smartphones alm do Android. As principais so: Blackberry, da RIM, iPhone OS, da Apple, webOS, da Palm, Windows Mobile, da Microsoft e Symbian, da Nokia (Amaral, 2009). Muitas caractersticas presentes no Android, tais como grficos 3D e suporte a banco de dados nativo, tambm esto disponveis em outras plataformas mveis. Porm, apenas no Android h um componente que permite exibir e manipular um mapa do Google Maps, servio de mapas do Google, dentro de uma aplicao (Meier, 2009). Somente no Android todos os aplicativos so criados igualmente. Ou seja, nele no h diferena entre aplicaes nativas e as demais aplicaes, o que possibilita uma grande personalizao do sistema, ao permitir a substituio completa de aplicativos nativos por outros, criados por terceiros. Alm disto, todos os aplicativos tem acesso s mesmas funcionalidades (Meier, 2009). Em termos de mercado, o nmero de dispositivos portteis tem tido um crescimento expressivo. O aumento da popularidade dos smartphones combinado com a crescente disponibilidade de internet tem criado um ambiente ideal para uma maior demanda de aplicaes para dispositivos mveis (Arima, 2009a). Mas, segundo Meier (2009), apesar de os avanos tecnolgicos ocorridos nos ltimos anos terem proporcionado o surgimento de dispositivos mveis mais potentes e com novas funcionalidades, quando comparados aos desktops e notebooks, ainda possuem relativamente: Menor poder de processamento; Memria RAM limitada; Capacidade de armazenamento persistente restrita; Tela pequena e de baixa resoluo; Altos custos associados transferncia de dados; Conexo pouco confivel e de baixa velocidade; Tempo de vida de bateria curto.

Portanto, estas caractersticas devem ser consideradas durante o processo de desenvolvimento de aplicaes para dispositivos mveis em geral.

3. Sobre a plataforma Android

A seguir sero exibidos, de forma resumida, alguns conceitos importantes relacionados plataforma Android. Este resumo est baseado no guia disponvel no site voltado para os desenvolvedores da plataforma (OHA, 2009c).

3.1 Arquitetura A plataforma Android composta pelos elementos mostrados na Figura 3.

Figura 3: Arquitetura da plataforma Android

Na base da pilha est um Linux Kernel verso 2.6. Alm de permitir uma abstrao entre o hardware e o software, ele o responsvel pelos principais servios do sistema como gerenciamento de memria e gerenciamento de processos. Embora as aplicaes para Android sejam escritas utilizando a linguagem Java, elas no so executadas em uma mquina virtual Java tradicional e sim em outra, chamada Dalvik. Assim como diversos componentes da plataforma, esta mquina virtual otimizada especialmente para dispositivos mveis. A plataforma tambm inclui uma coleo de bibliotecas C/C++ utilizadas por vrios componentes do sistema. Elas so as responsveis por prover, dentre

outros, udio, vdeo, grficos, banco de dados e navegador e so expostas para os desenvolvedores atravs do framework de aplicao. A arquitetura foi projetada para simplificar o reuso e a troca de componentes. Para tanto, a camada de framework de aplicao disponibiliza aos desenvolvedores as mesmas APIs (Application Programming Interface Interface de Programao de Aplicativos) usadas para criar as aplicaes originais do sistema. O Android j vem equipado com diversas aplicaes, escritas em linguagem Java. Dentre outras, h cliente de e-mail, navegador e gerenciador de contatos. Estas aplicaes esto localizadas no topo da pilha, juntamente com todas as demais, criadas por terceiros, instaladas no sistema.

3.2 Conceitos fundamentais das aplicaes As aplicaes para Android so escritas em linguagem Java. O cdigo, depois de compilado, empacotado juntamente com outros recursos utilizados pela aplicao em um arquivo com o sufixo .apk. Este arquivo o veculo de distribuio para os usurios instalarem a aplicao em seus dispositivos. Por padro, cada aplicao executada em um processo prprio e cada processo tem a sua mquina virtual. Para cada aplicao designado um ID de usurio Linux nico e as permisses so dadas de forma que os arquivos fiquem visveis apenas para a aplicao dona. Uma aplicao no tem um nico ponto de entrada. Elas so construdas utilizando componentes que so instanciados no momento em que se tornam necessrios. Existem quatro tipos de componentes bsicos: atividades, servios, provedores de contedo e receptores de broadcast. Uma atividade geralmente corresponde a uma tela para o usurio. Servios no possuem uma interface visual e so utilizados para executar processamentos em segundo plano. Os provedores de contedo servem para disponibilizar dados especficos de uma aplicao para outras aplicaes. Por fim, os receptores de broadcast so componentes que ficam inativos e respondem a eventos. Exceto os provedores de contedo, todos os outros trs componentes so ativados atravs de mensagens assncronas. Intent o nome do objeto que contem a mensagem com a ao que se deseja executar. Por exemplo, para

iniciar uma atividade necessrio enviar um Intent cujo contedo especifique esta inteno. Existem dois tipos de Intents: explcitos e implcitos. No primeiro, o componente que deve ser executado j definido explicitamente. No segundo, a escolha do componente feita pelo sistema operacional que, baseado em alguns critrios, determina qual componente responde melhor quela inteno naquele momento. Cada pacote .apk contm um arquivo de manifesto onde esto declarados todos os componentes da aplicao. O arquivo estruturado em linguagem XML e tambm utilizado para declarar as bibliotecas utilizadas, permisses, verso e requisitos. Quando o primeiro componente de uma aplicao precisa ser executado, um processo com um nico thread iniciado. Por padro, todos os componentes da aplicao so executados neste thread. O Android dispe de um mecanismo que permite a chamada de procedimentos remotos, executados em outros processos. Em determinado momento, quando a memria est escassa, por exemplo, o Android pode destruir um processo. Consequentemente, todos os

componentes da aplicao que esto sendo executados naquele processo so destrudos. Para decidir qual processo deve ser eliminado, levada em conta a importncia dos processos para o usurio. Por exemplo, o sistema ir destruir primeiro aqueles que contm atividades que no esto mais visveis na tela. Cada componente de uma aplicao tem um ciclo de vida bem definido que inicia no momento em que instanciado e acaba quando destrudo. Enquanto o componente est sendo executado, seu estado pode ser alterado diversas vezes. Uma atividade possui essencialmente trs estados: ativo, pausado e parado. As transies entre estes estados so notificadas atravs de chamadas a sete mtodos especiais, conforme demonstrado na Figura 4. Estes mtodos so utilizados para realizar as aes apropriadas a uma determinada mudana de estado.

Figura 4: Ciclo de vida de uma atividade

Durante o tempo entre as chamadas dos mtodos onStart() e onStop(), a atividade pode ser vista pelo usurio. Entre os mtodos onResume() e onPause() a atividade est na frente de todas as outras atividades e o usurio est interagindo com ela. E, devido ao fato de o onPause() ser o nico mtodo cuja chamada garantida antes do processo ser eventualmente destrudo, ele deve ser utilizado para armazenar, de forma persistente, dados para posterior restaurao. Como as atividades, os servios tambm possuem estados e mtodos de ciclo de vida que podem ser implementados para responder a mudanas de estado. Os receptores de broadcast possuem apenas um mtodo de ciclo de vida que chamado no momento em que uma mensagem chega para ele e o componente considerado ativo apenas durante a execuo deste mtodo, ou seja, enquanto reage mensagem.

3.3 Interface com o usurio No Android a interface com o usurio construda utilizando uma hierarquia de objetos View e ViewGroup. Nesta hierarquia, representada em forma de uma rvore, as folhas so do tipo View e os ramos do tipo ViewGroup, como na Figura 5. Uma View controla uma rea retangular especfica da tela e serve de base para a implementao de objetos como campos de texto e botes, chamados de widgets. A classe ViewGroup serve de base para os

layouts, utilizados para organizar a maneira como os objetos so dispostos na tela.

Figura 5: rvore de objetos View e ViewGroup

Os objetos podem ser organizados automaticamente, dentro de uma regio especfica da tela, entre outras, de forma linear, relativa ou absoluta. Para cada uma delas, deve ser utilizado um layout especfico. Por exemplo, os objetos filhos do ViewGroup LinearLayout so dispostos na tela linearmente e os filhos do ViewGroup AbsoluteLayout, de forma absoluta. Embora seja possvel especificar exatamente as coordenadas e o tamanho do componente a ser desenhado na tela, esta abordagem deve ser evitada. A organizao em layouts no absolutos mais vantajosa, pois possibilita uma melhor adaptao da interface da aplicao s diferentes telas (resoluo e tamanho distintos) dos dispositivos nos quais pode ser executada. A plataforma disponibiliza diversos widgets e layouts prontos que, em conjunto, permitem criar uma interface com o usurio bastante rica. Porm, se necessrio, tambm possvel construir e adicionar componentes customizados. E, quando o objetivo for personalizar objetos de forma uniforme, podem ser aplicados estilos e temas. Para tornar o visual da aplicao ainda mais atrativo, o sistema disponibiliza algumas maneiras de animar grficos em duas dimenses de forma facilitada. Uma das possibilidades a animao quadro a quadro, onde so especificadas as imagens e a ordem na qual elas devem ser trocadas. Tambm possvel utilizar uma animao Tween, que executa uma srie de transformaes simples (posio, tamanho, rotao e transparncia) em um objeto View. A plataforma tambm permite a criao de menus padronizados (veja Figura 6). Existem trs tipos fundamentais de menus: opo, submenu e

10

contexto. O primeiro exibido quando o usurio pressiona a tecla MENU do dispositivo e, em alguns casos, quando um de seus itens selecionado, um submenu revelado. J o contexto um tipo de menu que aparece quando o usurio pressiona de forma longa um objeto View.

Figura 6: Menu de opes, submenu e menu de contexto

Ao notificar o usurio sobre um evento que tenha ocorrido na aplicao, deve ser utilizada a tcnica adequada dentre as trs disponveis no Android: Toast, dilogo ou barra de estado (veja Figura 7). Resumidamente, a primeira til para mensagens pequenas que no requerem interao. O dilogo ideal para chamar a ateno do usurio e capturar uma resposta. Quando a aplicao est executando em segundo plano e necessita notificar o usurio, a barra de estado deve ser utilizada. Ao lanar uma notificao na barra de estado, possvel tambm emitir um som ou vibrar o dispositivo, desde que a aplicao tenha a permisso para isto.

Figura 7: Notificao - Toast, barra de estado e dilogo

11

3.4 Recursos e internacionalizao Geralmente, uma aplicao para Android contm recursos, que so elementos externos referenciados dentro dela, como imagens, sons e layouts, por exemplo. Todos os recursos devem estar dentro do diretrio res/, que reside no topo da rvore do projeto, no mesmo nvel do src/, onde ficam os arquivos com o cdigo fonte. Tudo que est localizado dentro do diretrio res/ pode ser acessado pela aplicao utilizando a classe R, gerada automaticamente pelas ferramentas de desenvolvimento. Esta classe contm subclasses para cada tipo de recurso suportado pelo Android com identificadores dos recursos compilados. possvel disponibilizar diferentes recursos dependendo da lngua ou das configuraes do dispositivo. Para isto, devem ser criados diretrios paralelos nomeados com qualificadores. Existem muitos qualificadores disponveis para diferenciar, por exemplo, a lngua e o tamanho de tela e eles podem ser utilizados em conjunto. O sistema seleciona automaticamente o diretrio cuja qualificao a mais adequada configurao do dispositivo naquele momento.

3.5 Armazenamento de informaes Diferentemente de sistemas operacionais para desktop, que geralmente disponibilizam um sistema de arquivos comum, no Android todos os dados so visveis apenas para a aplicao dona. Para que estas informaes sejam acessadas por outras aplicaes, deve ser utilizado um componente do tipo provedor de contedo. O Android permite que os dados sejam armazenados de diversas formas, como atravs de um mecanismo chamado de preferncias, onde possvel armazenar tipos primitivos. Esta possibilidade geralmente utilizada para guardar as preferncias do usurio. Tambm possvel armazenar dados diretamente no aparelho ou em um dispositivo de memria removvel, utilizando arquivos. A aplicao pode, alternativamente, com o SQLite, armazenar informaes em tabelas em um banco de dados. A plataforma suporta ainda o acesso a operaes de rede que podem ser utilizadas para guardar ou requisitar dados.

12

3.6 Mapas e localizao O sistema disponibiliza provedores de localizao que podem ser utilizados na construo de aplicaes baseadas na posio corrente do dispositivo. O componente central de localizao o objeto LocationManager. Com este objeto possvel listar os provedores de localizao disponveis, registrar para receber informaes peridicas sobre mudanas de localizao do dispositivo ou registrar um Intent para ser enviado quando o dispositivo se aproxima de um dado local, definido em termos de latitude e longitude. No momento em que feito o registro para receber informaes peridicas sobre mudanas de localizao do dispositivo, possvel selecionar um provedor de localizao especfico, pelo seu nome, ou atravs de um critrio considerando a preciso necessria para aplicao. Entre os provedores de localizao disponveis, geralmente esto a rede da operadora de telefonia mvel e o GPS. Estes provedores variam dependendo das especificaes do dispositivo. Vale ressaltar que, para utilizar um provedor de localizao, necessria a respectiva permisso. Alm de escolher o provedor de localizao, ao fazer o registro para receber informaes peridicas sobre mudanas de localizao do dispositivo, possvel tambm determinar um tempo mnimo e uma distncia mnima entre as atualizaes. importante determinar um tempo mnimo para economizar energia. Uma opo para exibir um mapa na tela utilizar um componente MapView, disponvel na biblioteca do Google Maps. Esta biblioteca no padro da plataforma Android e, portanto, necessrio indicar a sua importao no arquivo de manifesto. Para utilizar este componente, preciso estar de acordo com os termos de servios do Google Maps e se registrar para obter uma chave. Esta chave fornecida gratuitamente e sem ela o componente no funciona. O componente MapView exibe um mapa cujo contedo requisitado em tempo real utilizando uma conexo com a internet. Portanto, necessrio que a aplicao tenha a permisso para o acesso internet. Obviamente, mesmo com a permisso de acesso, caso a internet no esteja disponvel no momento, o mapa no ser exibido. O MapView disponibiliza mtodos para controlar o mapa que est sendo exibido. E, para personalizar ainda mais o mapa, utilizada uma classe especial (Overlay) que implementa uma camada sobre ele na qual podem ser desenhados diversos elementos.

13

3.7 Publicando uma aplicao Uma aplicao distribuda atravs de um arquivo com o sufixo .apk que empacota seu cdigo compilado juntamente com dados e recursos utilizados. Porm, antes de empacotar, deve ser atribuda, no arquivo de manifesto, uma verso para a aplicao. O sistema no utiliza esta informao, mas ela til para os usurios e para outras aplicaes. Para publicar uma aplicao necessrio que ela esteja assinada digitalmente. Portanto, deve ser utilizada uma chave do desenvolvedor para identific-lo como responsvel pela aplicao. Depois de assinada, ela est pronta para ser distribuda para usurios com dispositivos equipados com a plataforma Android. Entre as opes de distribuio, a principal a Android Market, loja virtual de aplicativos para a plataforma. Ela til quando se deseja atingir um grande nmero de usurios, visto que pode ser acessada a partir da maioria dos dispositivos.

3.8 Consideraes importantes Algumas recomendaes oficiais devem ser seguidas no desenvolvimento de aplicaes para a plataforma Android. Uma boa aplicao deve ser rpida e sem emendas. A qualidade de no ter emendas diz respeito padronizao entre todos os artefatos presentes no dispositivo. Como o sistema permite que aplicaes criadas por diversos desenvolvedores sejam instaladas, para garantir ao usurio uma usabilidade intuitiva e consistente, importante que todas utilizem os recursos disponveis de forma adequada. Para tanto, constam, na

documentao oficial, diversas diretrizes a serem seguidas. No Android, quando uma aplicao no responde a uma ao do usurio em menos de cinco segundos, o sistema exibe um dilogo (ANR - Application Not Responding), como na Figura 8, que permite a ele abortar a sua execuo.

14

Figura 8: Dilogo ANR

Alm destas consideraes, importante lembrar que a plataforma Android pode estar presente em dispositivos com caractersticas bem variadas. As diferenas podem ser no tamanho da tela e em sua resoluo ou na ausncia de teclado fsico, por exemplo. Portanto, necessrio projetar a aplicao de forma a possibilitar uma execuo adequada aos diversos dispositivos nos quais ela pode estar inserida.

15

4. Experincias com o Android

4.1 Atividades realizadas Apesar de um pequeno conhecimento prvio na rea de desenvolvimento para celulares, adquirido em uma disciplina durante o curso, tudo relativo plataforma Android era novo. Ento, inicialmente foi realizado um estudo detalhado sobre ela, utilizando como material, principalmente, o guia disponvel no site de desenvolvedores para Android (OHA, 2009c). Alm dele, um livro de Lecheta (2009) e outro, de Meier (2009), foram consultados. No menos importantes foram os vdeos de apresentaes voltadas para desenvolvedores da plataforma criados pelo Google (2009). Muitos deles foram gravados durante o evento Google I/O, realizado em maio de 2009 nos Estados Unidos, e proporcionam horas de informaes relevantes. A maior parte do tempo foi aplicada neste estudo sobre a plataforma Android, incluindo, dentre outros, os conceitos fundamentais de suas aplicaes, formas de interagir com os usurios, utilizao de recursos e as recomendaes oficiais de boas prticas. Alm disto, foram estudadas tambm funcionalidades mais sofisticadas, como acelermetro e GPS junto ao Google Maps. importante destacar que o estudo destas funcionalidades menos triviais exigiu um esforo maior, pois no foram encontrados bons manuais didticos completos. Apesar de a plataforma ter sido idealizada para facilitar o trabalho dos desenvolvedores e permitir um rpido desenvolvimento (Meier, 2009), uma poro de tempo expressiva foi consumida no seu aprendizado, pois se optou por um melhor entendimento ao invs de uma abordagem mais simplista. Lembrando que este entendimento menos superficial crucial no

desenvolvimento de uma boa aplicao para diferentes dispositivos mveis com Android, onde o poder de processamento e a autonomia da bateria so limitados e as caractersticas dos dispositivos (tamanho de tela e presena de teclado fsico, por exemplo) variam. Como a linguagem de programao utilizada Java, foi necessrio um pequeno aperfeioamento na mesma, pois, apesar de contar com um conhecimento prvio adquirido durante o curso de graduao, a experincia de programao nela no era grande. Para este propsito, foi consultado o tutorial da Sun (2009).

16

4.2 Avaliaes e recomendaes Para o desenvolvimento dos aplicativos, foi escolhido o IDE Eclipse 3.4 (ltima verso disponvel no incio do projeto), pois alm de ser um ambiente gratuito bastante conhecido, o mais recomendado pelas referncias oficiais e h um bom plugin oficial para ele, o ADT (Android Development Tools) 0.9, que tambm foi utilizado na produo. Nenhuma alternativa ao Eclipse foi cogitada, j que o ADT est disponvel apenas para ele (OHA, 2009c). Tal plugin facilita a criao dos arquivos XML, a edio dos layouts, o gerenciamento de recursos e conta com uma boa integrao com o emulador. Apesar de seu uso no ser obrigatrio, o ADT, como o esperado, proporcionou um grande ganho de produtividade. O SDK oficial do Android fundamental no desenvolvimento de aplicativos para a plataforma (OHA, 2009c) e, portanto, foi utilizado (verso 1.5). Nele, alm das bibliotecas necessrias, esto presentes importantes ferramentas de apoio ao desenvolvimento, como o emulador, que capaz de simular um smartphone com Android e, por isto, foi extremamente til nos testes do aplicativo. Com ele foi possvel testar inclusive as mudanas na localizao GPS e caractersticas inerentes ao dispositivo, como diferentes tamanhos de telas. Mas, apesar de ser bastante bom, o emulador no completo e carece, por exemplo, de uma simulao para o acelermetro. Para suprir esta deficincia, foi tentado um programa gratuito, disponvel por terceiros, chamado SensorSimulator. Porm, devido s atualizaes no SDK, este programa no se mostrou compatvel e acabou no sendo utilizado. Por esta razo, o acelermetro foi testado apenas no dispositivo real. A familiarizao com o ambiente e com as ferramentas mais importantes disponveis no foi trabalhosa, apesar de algum tempo para baixar, instalar e configurar todos os componentes ter sido necessrio. Mas, assim como aconteceu com as documentaes e com o plugin, o SDK tambm sofreu importantes atualizaes no decorrer do projeto, o que exigiu algumas adaptaes. Alm disto, foram encontrados alguns bugs que demandaram tempo para serem contornados. Vale ressaltar que j foram lanadas verses do IDE, do SDK e do plugin ainda mais recentes. Porm, as novas verses no adicionaram facilidades que pudessem ser aplicadas diretamente no trabalho. Portanto, o tempo necessrio para configurar todo o ambiente de desenvolvimento com as novas verses no seria compensado e, por isto, elas no foram utilizadas.

17

Para consolidar os conceitos estudados e experimentar as funcionalidades disponveis para os desenvolvedores de aplicativos para Android, algumas pequenas aplicaes foram criadas. Entre elas, um Notepad, mostrado na Figura 9, onde foram aplicados alguns conceitos importantes de ciclo de vida da aplicao, de interface e de armazenamento em um banco de dados.

Figura 9: Aplicativo Notepad, criado para testes

Depois, foi criado um jogo no estilo Sokoban (jogo de tabuleiro onde o jogador deve empurrar as caixas para os locais marcados), mostrado na Figura 10. Apesar de aparentemente simples, nesta criao esto presentes diversos conceitos como: ciclo de vida e propriedades do componente atividade, utilizao de recursos como imagens e sons, criao de layouts mais sofisticados com XML, animao com XML, tratamento de diferentes formas de interao com o usurio, criao de menu com XML, tratamento de preferncias do usurio e persistncia utilizando banco de dados. Muitos destes conceitos esto presentes no aplicativo final deste trabalho.

18

Figura 10: Jogo Sokoban, criado para testes

Alm de possibilitar a prtica do contedo estudado, a criao destas pequenas aplicaes ajudou na familiarizao com o sistema e com as ferramentas utilizadas no desenvolvimento. Vale destacar que a resoluo de muitos problemas encontrados durante a confeco destes artefatos

proporcionou um ganho na experincia de desenvolvimento para o Android que foi muito til no restante do projeto. No final do primeiro semestre de 2009, o escopo do aplicativo a ser criado foi traado com detalhes. Mais tarde, com um conhecimento ainda maior da plataforma (funcionalidades disponveis e facilidades) e das ferramentas de apoio ao desenvolvimento, algumas especificaes de determinadas

funcionalidades foram levemente alteradas para adequar melhor a aplicao ao seu contexto. Posteriormente, a etapa de implementao foi iniciada seguindo as boas prticas de programao aprendidas durante o curso e os padres e recomendaes oficiais existentes para a plataforma Android. O cdigo da aplicao foi escrito de forma incremental e iterativa: as funcionalidades eram adicionadas e testadas progressivamente no emulador. A parte mais difcil da etapa de programao foi implementar o controle do estado do GPS juntamente com o ciclo de vida da tela que exibe o mapa com a rota atualizada. Alm disto, um grande tempo foi gasto na construo dos arquivos responsveis pela organizao dos componentes visuais de algumas telas. Devido indisponibilidade de um dispositivo real para testar a aplicao, ela foi implementada por inteiro, sendo testada no emulador. Os testes no

19

emulador foram feitos progressivamente, sempre que uma nova funcionalidade era adicionada. Depois, com o lanamento de dispositivos equipados com Android no Brasil, foi adquirido um aparelho para testar a aplicao em um ambiente real. Infelizmente, algumas dificuldades s permitiram a compra do aparelho em novembro de 2009. Mas, apesar do tempo exguo disponvel, foi possvel realizar os testes como o desejado. A conexo entre o dispositivo real e o computador no qual o aplicativo estava sendo desenvolvido (para utilizar a ferramenta adb) foi bastante trabalhosa devido incompatibilidade do driver. Aps muito tempo e diversas tentativas, o problema foi solucionado instalando um driver genrico existente em uma verso antiga do SDK. Depois de conectado com o computador, foi possvel, utilizando a ferramenta adb, depurar o aplicativo no dispositivo real. Isto foi essencial para testar e ajustar o uso de seu sensor de movimento (acelermetro), utilizado para detectar chacoalhadas no dispositivo. Um problema que dificultou os testes de monitoramento no dispositivo foi a fraca recepo de seu GPS e o grande tempo que decorre entre o seu acionamento e a captura da primeira posio. O GPS do dispositivo utilizado s funcionou em ambientes externos, onde a aplicao teve que ser testada. E, mesmo assim, o sinal no era sempre bom, provavelmente devido grande quantidade de prdios em algumas ruas. Alm disto, o sinal do GPS tambm era afetado pelas condies climticas. Os melhores resultados foram obtidos na beira da praia com um tempo aberto. No geral, a passagem para o dispositivo real foi bem sucedida e os resultados obtidos foram bastante satisfatrios, iguais aos obtidos utilizando o emulador, concluindo assim o trabalho como almejado inicialmente. A Figura 11 exibe o aplicativo sendo executado no dispositivo real.

20

Figura 11: Aplicativo no dispositivo real

Portanto, como visto anteriormente, o cronograma (veja Apndice 1), planejado durante o Projeto Final I, s precisou ser levemente alterado: os testes no dispositivo real foram atrasados em um ms, pois dependiam da disponibilidade de um aparelho.

21

5. Projeto e especificao do sistema

O produto final criado um aplicativo para smartphones equipados com a plataforma Android. O aplicativo, cujo nome MyRoute, est focado em proprietrios de smartphones com este sistema. O artefato utiliza mapas e GPS e foi construdo para o monitoramento de rotas em ambientes externos. Basicamente, o aplicativo armazena rotas percorridas pelo usurio, capturando as posies do dispositivo ao longo do tempo, e alguns dados relacionados a elas. Atravs de um boto na tela inicial do aplicativo, possvel iniciar um monitoramento novo e, atravs de seu menu, acessar as telas de preferncias, de informaes sobre o aplicativo e de ajuda. Na tela de preferncias, algumas opes podem ser personalizadas como a preciso da captura de posies (alta, mdia ou baixa), os alertas (sonoro e/ou vibratrio ou desligado) e a unidade de medida utilizada (quilmetro ou milha). Ao ligar o monitoramento, um cone adicionado na barra de estado do sistema. Com o monitoramento ativo, a rota que o usurio percorre passa a ser exibida na tela em um mapa. Alm dela, tambm so exibidos o tempo, a velocidade instantnea e a distncia percorrida at o dado momento. Para isto, quando acionado, um componente que executa aes em segundo plano criado. Este componente se registrada a um provedor de localizao e recebe as atualizaes de mudanas de posio do dispositivo. A aplicao controla o estado do monitoramento, que pode estar ligado e carregando, ligado e ativo ou desligado, com indicado no diagrama da Figura 12.

Usurio aciona o monitoramento Incio

Primeira localizao GPS obtida

Localizao GPS obtida

Ligado / Carregando

Ligado / Ativo

Fim Desligado A rota armazenada

Usurio finaliza o monitoramento

Figura 12: Diagrama de estados do monitoramento

O provedor de localizao utilizado o GPS, por ser mais preciso, e seu tempo mnimo para receber atualizaes de mudanas de posio do dispositivo

22

especificado baseado nas preferncias de preciso do usurio. Mudanas no estado do provedor de localizao so notificadas para o usurio. Para tanto, o cone exibido na barra de estado do sistema quando o monitoramento est ativo colorido de verde, de amarelo ou de vermelho, dependendo do estado do provedor de localizao. A cor verde indica que o GPS est ligado e disponvel. A cor amarela utilizada caso o GPS esteja ligado, mas temporariamente indisponvel. Por fim, a cor vermelha indica que o GPS est desligado ou fora de servio. Alm do cone, mensagens e alertas sonoros e vibratrios notificam o usurio. Estes alertas tambm podem ser personalizados por ele. Para a exibio do mapa, utilizado o Google Maps e a rota representada na tela atravs de linhas interligando os pontos (posies) capturados desenhadas em uma camada sobre ele. Conforme novos pontos so adicionados, o mapa movimentado para manter a ltima posio no centro. Nesta tela tambm h um menu, que permite ao usurio selecionar o nvel de zoom do mapa desejado. Se o usurio desejar, pode fechar a tela do aplicativo depois de acionar o monitoramento e este continuar ativo, em segundo plano. Porm, com a tela fechada, o aplicativo no exibe nenhuma informao (mapa com a rota, tempo, velocidade e distncia). Ao desligar o monitoramento, possvel visualizar um mapa com a rota percorrida, o tempo e a distncia totais e a velocidade mdia. Estas informaes so armazenadas no banco de dados, divididas em duas tabelas, conforme o esquema da Figura 13.

Routes -<<id>> _id : int -name : string -date : string -time : string -speed : float -distance : float 1 2..* Points -<<id>> _id : int -route_id : int -latitude : int -longitude : int

Figura 13: Esquema do banco de dados

Ao escolher a opo de consultar as rotas anteriores na tela inicial, uma nova tela aberta onde so listadas todas as rotas armazenadas, com as mais recentes exibidas no topo. Nesta tela possvel apagar e modificar os nomes das rotas. E, ao selecionar uma delas, todas as suas informaes so exibidas.

23

Na tela que exibe o mapa de uma rota armazenada possvel mov-lo e alterar o seu nvel de zoom. E, para que a rota volte a ser exibida no centro, existe uma opo no menu. Outra forma de centralizar a rota chacoalhando o dispositivo. Neste caso, o acelermetro utilizado. O aplicativo foi criado para funcionar bem em aparelhos diversos, com telas de tamanho diferente, nos modos retrato e paisagem, e tambm naqueles que no possuem tela sensvel ao toque ou que carecem de um acelermetro. Obviamente, em determinados casos, algumas funcionalidades no esto disponveis. As nicas caractersticas obrigatrias so o GPS e um acesso internet. O primeiro necessrio para realizar a funo principal do aplicativo, que o monitoramento de rotas atravs da captura da posio do dispositivo; o segundo indispensvel para acessar o Google Maps para exibir os mapas. Por fim, importante salientar que o aplicativo est disponvel em duas lnguas: ingls e portugus (se o sistema no qual est o aplicativo estiver configurado para portugus, o contedo ser apresentado em lngua portuguesa e, caso contrrio, em lngua inglesa). Estruturalmente, o aplicativo composto por oito telas (principal, mapa atual, resumo, mapa antigo, lista de rotas armazenadas, preferncias, informaes sobre o aplicativo e ajuda), um componente que executa processamento em segundo plano (monitoramento utilizando o GPS) e duas tabelas em um banco de dados, que armazenam as informaes das rotas cujos monitoramentos foram concludos.

24

6. Implementao e avaliao
6.1 Como a aplicao foi implementada A aplicao utiliza oito telas que exibem, cada uma delas, uma interface diferente com o usurio. Portanto, foram necessrios oito componentes do tipo atividade. Alm disto, um componente do tipo servio foi utilizado para possibilitar que a aplicao execute em segundo plano. Todos os componentes utilizados esto descritos no arquivo de manifesto (AndroidManifest.xml), onde tambm constam as permisses para garantir aplicao o acesso internet (android.permission.INTERNET), ao GPS (android.permission.ACCESS_FINE_LOCATION) e ao vibrador do dispositivo (android.permission.VIBRATE) e uma declarao de uso de uma biblioteca externa (com.google.android.maps) necessria para a exibio dos mapas atravs do Google Maps. No arquivo ainda consta qual componente (Main) deve ser iniciado quando o usurio escolher o cone da aplicao na lista de aplicaes instaladas no dispositivo. Exceto no caso da atividade de preferncias (Preferences), cuja interface gerada automaticamente pela plataforma, todas as interfaces com o usurio dos outros componentes do tipo atividade (About, Help, Main, RouteMap, OldRouteMap, OpenList e Summary) foram definidas em XML. Cada uma delas est escrita em um arquivo individual, localizado no diretrio res/layout, onde consta a sua hierarquia de objetos View e ViewGroup. A interface carregada em um componente assim que este criado, em seu mtodo onCreate(). Apesar de ser possvel construir a interface diretamente no cdigo, em linguagem Java, a utilizao dos arquivos em formato XML bastante vantajosa, pois permite uma maior separao entre a lgica e o visual. importante lembrar que a aplicao foi pensada para funcionar bem em diferentes dispositivos. Para tanto, os layouts utilizam posicionamentos e unidades relativas ao invs de absolutas. A Figura 14 mostra como a tela inicial se adapta a tamanhos diferentes, como HVGA (480x320) e QVGA (240x320), e aos modos retrato e paisagem.

25

Figura 14: Tela inicial nos tamanhos HVGA (retrato e paisagem) e QVGA

Todas as atividades, exceto trs (About, Help e Summary), possuem menus de opes especficos que, assim como as interfaces com o usurio, foram definidos em arquivos no formato XML. Os menus so carregados no mtodo onCreateOptionMenu() da atividade correspondente, j que este mtodo chamado na primeira vez em que a tecla MENU do dispositivo pressionada enquanto a atividade est sendo exibida. Em alguns casos, necessrio modificar o menu de opes

dinamicamente e isto feito dentro do mtodo onPrepareOptionMenu(), que chamado sempre que a tecla MENU do dispositivo pressionada. Por exemplo, na atividade que lista as rotas armazenadas (OpenList), a opo de apagar todas elas deve estar ou no habilitada; caso a lista esteja vazia, a opo desabilitada dinamicamente, como na Figura 15.

Figura 15: Menu de opes modificado dinamicamente

26

Assim que o usurio escolhe dar incio a um novo monitoramento, selecionando o boto Iniciar na tela inicial do aplicativo (Main), uma atividade com um mapa (RouteMap) exibida, como na Figura 16. Esta atividade inicia um servio (BackgroundService) que requisita as atualizaes da posio do dispositivo utilizando GPS. Assim que criado, este servio lana uma notificao na barra de estado do sistema. Esta notificao persiste at que o monitoramento seja explicitamente desligado, mesmo que a tela com o mapa no esteja mais sendo exibida.

Figura 16: Tela que exibe a rota atual (carregando e ativa)

Para

controlar

as

notificaes

na

barra

de

estado,

classe

StatusBarNotification utilizada. Seu mtodo fireNotification() recebe como parmetro o tipo de notificao, entre os listados abaixo: GPS ligado GPS desligado GPS disponvel GPS temporariamente indisponvel GPS indisponvel Padro

Dependendo do tipo de notificao, a cor do cone, as mensagens e os alertas da notificao lanada so diferentes. Como estes alertas podem ser personalizados na tela de preferncias, antes de enviar um, a preferncia atual do usurio verificada e respeitada. Na Figura 17 mostrada como exemplo a notificao que enviada na barra de estado para indicar a disponibilidade do GPS, aps este estar fora de servio.

27

Figura 17: Notificao na barra de estado (GPS disponvel)

Depois de criar o servio, a atividade se conecta a ele possibilitando que estes dois componentes (RouteMap e BackgroundService) troquem informaes entre si. Mais especificamente, a atividade indica ao servio quando ela est ou no sendo exibida e, portanto, necessita ou no ser atualizada. Quando a atividade est sendo exibida, o servio o responsvel por enviar para ela novas informaes para a atualizao da tela. Como a obteno da primeira coordenada GPS pode ser demorada, enquanto ela no enviada pelo servio, a atividade exibe uma animao Tween indicando que est em fase de carregamento (veja Figura 16). Durante este perodo, se desejar, o usurio pode abortar a operao e nada ser armazenado. O controle do estado do monitoramento feito atravs de dois campos armazenados, utilizando o mecanismo de preferncias, e necessrio para permitir que o usurio feche a tela em diferentes etapas e continue sem problemas posteriormente. Alm disto, a tela inicial do aplicativo (Main) utiliza o estado (ligado ou desligado) para modificar o texto de um de seus botes entre Iniciar e Continuar (Iniciar, caso o monitoramento no esteja ativo, ou Continuar, caso contrrio), como na Figura 18.

28

Figura 18: Tela inicial

importante lembrar tambm que o sistema multitarefa. Ou seja, enquanto o aplicativo est carregando (aguardando a primeira posio adquirida utilizando o GPS) ou em qualquer outro momento, o usurio pode fechar esta tela para trabalhar em um aplicativo diferente e quando retornar espera encontrar o aplicativo funcionando corretamente. Para exibir o mapa na tela (veja Figura 16), a atividade utiliza um MapView. A construo da rota no mapa feita em uma camada sobre ele, utilizando a classe RouteOverlay, filha da classe Overlay. Mais especificamente, nela foram desenhados segmentos de retas interligando os pontos. Estes pontos, capturados atravs do GPS, so inseridos, enquanto o monitoramento est ativo, em um vetor (ArrayList) em forma de sistema de coordenadas geogrficas (latitude e longitude). Visando desprezar as informaes

desnecessrias e facilitar a converso de tipos, objetos da classe MyPoint so utilizados para armazenar os pares de coordenadas. Quando o usurio escolhe encerrar o monitoramento (apertando o boto Parar), todos os pontos, bem como a velocidade mdia, a distncia, o tempo do percurso, o nome da rota e a data atual so armazenados em um banco de dados. A classe RoutesDatabase a responsvel pelo acesso ao banco de dados bem como a disponibilizao de mtodos que implementam as consultas utilizadas. Os comandos SQL utilizados por esta classe esto no Apndice 2. O armazenamento de uma rota pode ser demorado, principalmente quando esta composta por muitos pontos. Ento, para no bloquear o thread principal, da interface, esta ao feita em um thread separado. Para tanto, utilizada a classe SaveRoute, que recebe como parmetro um objeto Route, com

29

todas as informaes da rota a ser armazenada. Enquanto isto, na tela exibido um dilogo de progresso, como na Figura 19.

Figura 19: Dilogo de progresso (Salvando...)

Quando o usurio aperta Abrir na tela inicial (Main), as rotas anteriores so listadas em uma atividade do tipo ListActivity (OpenList), mostrada na Figura 20. Atravs de um adaptador, esta atividade relaciona um cursor, resultado de uma consulta ao banco de dados, com um componente visual que lista itens na tela (ListView). Esta consulta retorna todas as rotas existentes na tabela em ordem decrescente de chave primria, para que as mais recentes apaream no topo da lista. E, quando o usurio seleciona um item da lista, aberta uma tela (Summary) com o resumo daquela rota e um boto para abrir o seu mapa, como na Figura 20. Ao apertar este boto, uma nova atividade (OldRouteMap) iniciada e exibe um mapa com a rota desenhada sobre ele, como na Figura 20.

Figura 20: Telas de listagem, de resumo e de mapa

30

Alm de um menu de opes, a atividade que lista as rotas armazenadas (OpenList) prov ainda um menu de contexto, criado em seu mtodo onCreateContextMenu(). Com o menu de contexto, exibido quando o usurio pressiona de forma longa um item da lista, possvel modificar o nome de uma rota ou remov-la. Para que o usurio possa escolher as suas opes preferenciais, uma atividade (Preferences) do tipo PreferenceActivity foi utilizada. Este componente carrega, utilizando o mtodo addPreferencesFromResource(), um arquivo de preferncias quando criado. O arquivo construdo em XML e com ele o sistema capaz de definir os itens a serem exibidos na tela (veja Figura 21) bem como responder interao com o usurio e armazenar as suas preferncias. Depois de armazenadas, todos os componentes que necessitam acessar o valor de uma preferncia o fazem utilizando a chave da preferncia de interesse.

Figura 21: Tela de preferncias

As outras duas telas utilizadas na aplicao, mostradas na Figura 22, so a de ajuda e a de informaes sobre a aplicao. A primeira contm um texto (veja Apndice 3) que explica a forma como a aplicao deve ser utilizada. E, na segunda, constam informaes sobre a aplicao, como verso e autoria.

31

Figura 22: Telas de ajuda e de informaes sobre a aplicao

Por fim, vale salientar que, tal como os arquivos que definem os layouts e menus, todos os outros recursos que no fazem parte da lgica da aplicao esto separados de seu cdigo, dispostos em diretrios especficos. Por exemplo, as imagens esto no diretrio res/drawable em formato PNG e os sons no diretrio res/raw em formato OGG (estes formatos de arquivos foram utilizados, pois so os recomendados na documentao oficial do Android). Os recursos so acessados dentro do cdigo Java atravs da classe R, que gerada automaticamente pelas ferramentas disponveis no SDK. Todos os arquivos utilizados no trabalho esto listados no Apndice 4. No caso das strings, elas esto armazenadas em dois arquivos XML de mesmo nome (strings.xml) em dois diretrios: res/values e res/values-pt. Isto permite que a aplicao funcione em ingls e em portugus, dependendo da configurao do dispositivo na qual est instalada, utilizando a funcionalidade de recursos alternativos provida pela plataforma: o sistema seleciona

automaticamente o diretrio no qual deve ser acessado o arquivo (values/ ou values-pt/, onde pt o qualificador para lngua portuguesa). Ou seja, no arquivo values/strings.xml ficam armazenados todos os textos padres utilizados na aplicao, em ingls. Em values-pt/strings.xml esto alguns textos traduzidos para o portugus. Caso o dispositivo esteja executando em portugus, o sistema buscar as strings no arquivo values-pt/strings.xml e aquelas strings no encontradas (por exemplo, o ttulo da aplicao, que igual em todas as lnguas) so buscadas no arquivo values/strings.xml. Depois de pronta, foi atribuda uma verso (1.0) para a aplicao no arquivo de manifesto (AndroidManifest.xml). E, para possibilitar a sua instalao em um dispositivo, a aplicao foi assinada digitalmente. Para assinar a

32

aplicao, foi utilizado o assistente de exportao do plugin ADT (veja Figura 23), que executa todas as aes necessrias, inclusive criando um keystore (repositrio de chaves e certificados), se preciso.

Figura 23: Assistente de exportao

Em complemento, todos os cdigos implementados foram devidamente comentados e esto disponveis, juntamente com os recursos (imagens e sons) utilizados, no CD que integra este relatrio e tambm no site

http://www.icad.puc-rio.br/~projetos/android.

33

6.2 Testes realizados Primeiramente, os testes foram realizados no emulador, ferramenta disponvel no SDK. O emulador, mostrado na Figura 24, um dispositivo mvel virtual executado no computador que simula as configuraes reais tpicas de hardware e software de um smartphone com Android.

Figura 24: Emulador

Para testar o funcionamento do GPS, simulando a mudana de localizao do dispositivo, foi utilizada a ferramenta DDMS, para enviar coordenadas geogrficas para uma instncia do emulador em execuo. Estas coordenadas fictcias foram geradas utilizando outro programa, o Google Earth. Nele, uma rota foi criada e gravada em um arquivo .kml que depois foi importado em um painel da DDMS (veja Figura 25) para facilitar os testes.

34

Figura 25: Ferramenta DDMS

No final do trabalho, depois de ter a aplicao funcionando bem no emulador, ela foi testada em um dispositivo real. Para tanto, foi utilizado o smartphone Samsung Galaxy (veja Figura 26) cujas especificaes esto detalhadas no Apndice 5.

Figura 26: Smartphone Samsung Galaxy

Os primeiros testes no dispositivo real foram realizados para verificar se as telas e o funcionamento bsico vistos no emulador seriam reproduzidos corretamente. Depois, aconteceu o teste do reconhecimento de chacoalhada, que utiliza o sensor de movimento do dispositivo (acelermetro). Para tanto, foi

35

utilizada a ferramenta adb, disponvel no SDK, que permite depurar uma aplicao em fase de desenvolvimento em um dispositivo real, conectado ao computador atravs de sua porta USB. Este teste foi essencial para ajustar o sensor adequadamente. Durante os testes no dispositivo, foi experimentado tambm outro provedor de localizao alm do GPS: a rede da operadora de telefonia mvel. Porm, apesar da mesma ser rpida e estar disponvel, inclusive em ambientes fechados, se mostrou extremamente imprecisa, como j era esperado. Em alguns casos, a posio informada distava mais de 500 metros da posio real, algo inaceitvel para o contexto desta aplicao. Ento, o GPS permaneceu como nico provedor de localizao utilizado na aplicao, apesar deste s ter tido possibilidade de uso em ambientes abertos. O teste funcional total da aplicao, incluindo o monitoramento utilizando o GPS, foi, posteriormente, executado, exclusivamente, no dispositivo, em um ambiente externo (para obter uma melhor recepo do GPS). Por fim, os resultados de todos os testes realizados foram bastante satisfatrios: todas as funes presentes no aplicativo funcionam adequadamente.

36

7. Consideraes finais
O presente trabalho procurou destacar o bom momento do mercado de telefonia mvel, no qual se encontra os smartphones, e a importncia de novidades como o Android neste cenrio. Foram demonstradas as principais caractersticas desta plataforma e como as ferramentas de desenvolvimento disponveis podem ser utilizadas na construo de uma aplicao real para ela. Portanto, o contedo apresentado ser til aos interessados no desenvolvimento de aplicativos para dispositivos mveis, especialmente aqueles equipados com a plataforma Android. A realizao do trabalho possibilitou um grande aprendizado na plataforma Android. Alm disto, foram assimilados importantes conceitos relacionados com a rea de dispositivos mveis, a qual possui caractersticas bem singulares. E, por fim, permitiu a aplicao do conhecimento adquirido durante o curso de graduao na construo de um artefato real, com utilidade prtica. Como visto ao longo do texto, aos interessados na rea, a plataforma Android representa uma boa oportunidade, pois fornece muitas facilidades para o desenvolvedor criar aplicaes interessantes. Alm disto, atualmente j possvel encontrar uma boa bibliografia sobre ela. E, quanto ao mercado, a possibilidade de estar em diferentes dispositivos, de diversos fabricantes, tem feito aumentar muito a quantidade de seus usurios. Vale lembrar que, quando a proposta deste trabalho foi redigida, havia apenas um modelo de dispositivo equipado com Android. Hoje, menos de um ano depois, j so mais de dez.

37

Referncias Bibliogrficas
AMARAL, Bruno do. Conhea os 6 principais sistemas operacionais de smartphones. PC Magazine, 12 jan. 2009. Disponvel em: <http://pcmag.uol.com.br/conteudo.php?id=810>. Acesso em: 20 abr. 2009. ARIMA, Ktia. Qual ser o seu prximo celular?: Por que o Google, a Apple e a Palm tm cada vez mais chances de disputar essa resposta. Info Exame, So Paulo, v. 1, n. 276, p. 24-41, fev. 2009a. ARIMA, Ktia. TIM ir vender Android no Brasil. Info Online, So Paulo, 15 set. 2009b. Disponvel em: <http://info.abril.com.br/noticias/tecnologiapessoal/tim-ira-lancar-android-no-brasil-15092009-31.shl>. Acesso em: 16 set. 2009. GOHRING, Nancy. Android completa um ano envolto em dvidas e expectativas. IDG Now, 28 set. 2009. Disponvel em: <http://idgnow.uol.com.br/telecom/2009/09/28/android-completa-um-anoenvolto-em-duvidas-e-expectativas/>. Acesso em: 29 set. 2009. GOOGLE. Google Developers Channel. Disponvel em: <http://www.youtube.com/user/GoogleDevelopers>. Acesso em: 6 jun. 2009. HAMBLEN, Matt. Android ajuda mercado de smartphones a bater recorde no terceiro trimestre. IDG Now, 6 nov. 2009. Disponvel em: <http://idgnow.uol.com.br/telecom/2009/11/06/android-ajuda-mercado-desmartphones-a-bater-recorde-no-terceiro-trimestre/>. Acesso em: 10 nov. 2009. LECHETA, Ricardo. Google Android: aprenda a criar aplicaes para dispositivos mveis com o Android SDK. So Paulo: Novatec, 2009. MACHADO, Andr. Conhea o HTC Magic, o Samsung Galaxy e o Motorola DEXT, todos com o sistema Android, do Google. O Globo, Rio de Janeiro, 16 nov. 2009. Disponvel em: <http://oglobo.globo.com/tecnologia/mat/2009/11/16/conheca-htc-magicsamsung-galaxy-o-motorola-dext-todos-com-sistema-android-do-google914782823.asp>. Acesso em: 20 nov. 2009. MEIER, Reto. Professional Android Application Development. Indianapolis: Wiley Publishing, 2009.

38

OHA. Alliance Overview. Disponvel em: <http://www.openhandsetalliance.com/oha_overview.html>. Acesso em: 20 mar. 2009a. OHA. Android Overview. Disponvel em: <http://www.openhandsetalliance.com/ android_overview.html>. Acesso em: 20 mar. 2009b. OHA. The Developer's Guide. Disponvel em: <http://developer.android.com/guide/index.html>. Acesso em: 20 mar. 2009c. SUN. The Java Tutorials. Disponvel em: <http://java.sun.com/docs/books/tutorial/>. Acesso em: 6 jun. 2009.

39

Apndices

40

A1: Cronograma

Projeto Final I Projeto Final II Tarefa Mar/09 Abr/09 Mai/09 Jun/09 Ago/09 Set/09 Out/09 Nov/09 1 X X X 2 X X 3 X X 4 X 5 X X 6 X X X X 7 X X X 8 X 1 - Estudo da plataforma Android 2 - Estudo de acelermetro e GPS com Google Maps 3 - Anlise e escolha das ferramentas que sero utilizadas 4 - Anlise de possveis aplicaes 5 - Especificao do sistema 6 - Implementao e reviso da aplicao 7 - Testes no emulador 8 - Testes no aparelho

Observao: Os testes no aparelho estavam previstos, inicialmente (Projeto Final I), para os meses de outubro e novembro. Entretanto, foram feitos apenas no ms de novembro, pois dependiam da disponibilidade de um aparelho, o qual foi obtido efetivamente em novembro.

41

A2: Banco de dados (modelo e comandos SQL)

Routes -<<id>> _id : int -name : string -date : string -time : string -speed : float -distance : float 1 2..* Points -<<id>> _id : int -route_id : int -latitude : int -longitude : int

Criar tabelas de rotas e de pontos

create table routes (_id integer primary key autoincrement, name text, date text, speed float, distance float, time text) create table points (_id integer primary key autoincrement, route_id integer, latitude integer, longitude integer)

Selecionar uma rota (sem seus pontos)

select * from routes where _id = id_rota

Selecionar dados identificadores de todas as rotas em ordem decrescente

select _id, name, date from routes orderby _id desc

Selecionar pontos de uma rota

select * from points where route_id = id_rota orderby _id

Adicionar uma rota

insert into table routes (name, date, speed, distance, time) values (nome, data, velocidade, distncia, tempo) insert into table points (route_id, latitude, longitude) values (id_rota, latitude_ponto1, longitude_ponto1) insert into table points (route_id, latitude, longitude) values (id_rota, latitude_ponto2, longitude_ponto2) (...) insert into table points (route_id, latitude, longitude) values (id_rota, latitude_pontoN, longitude_pontoN)

Renomear uma rota

update routes set name = novo_nome where _id = id_rota

Apagar uma rota

delete from points where route_id = id_rota delete from routes where _id = id_rota

Apagar todas as rotas

delete * from routes delete * from points

42

A3: Texto da tela de ajuda

O que ? MyRoute uma aplicao que permite monitorar uma rota. Quando o

monitoramento acionado, utilizando o GPS e acessando a internet, exibe a sua rota em um mapa juntamente com sua velocidade, distncia e tempo.

Como usar? Selecione Iniciar para dar incio a um novo monitoramento. Este continuar

ativo, mesmo se a tela for fechada, at que seja selecionado Parar. Quando desativado, a rota ser armazenada automaticamente. Selecione Continuar para reabrir uma tela fechada anteriormente. Selecione Abrir e ser exibida uma lista com todas as rotas armazenadas. Escolha a rota desejada para visualizar seus detalhes. Nesta tela tambm possvel apagar e modificar o nome das rotas.

Como customizar? Na tela de preferncias possvel modificar a preciso do GPS (reduzir a

preciso ajuda a economizar energia). Voc tambm pode modificar a unidade de medida e os alertas.

43

A4: Lista de todos os arquivos da aplicao

src/ br/puc_rio/myroute/ About.java BackgroundService.java Help.java Main.java MyGeoPoint.java OldRouteMap.java OpenList.java Preferences.java Route.java RouteMap.java RouteOverlay.java RoutesDatabase.java SaveRoute.java StatusBarNotification.java Summary.java gen/ br/puc_rio/myroute/ R.java res/ anim/ loading.xml drawable/ gradient.xml icon.png logo.png notification_green.png notification_red.png notification_yellow.png puc_rio.png vision_lab.png layout/ about.xml help.xml list.xml main.xml old_route_map.xml rename.xml route_map.xml row.xml summary.xml layout-land/ main.xml summary.xml menu/ list.xml main.xml map.xml old_map.xml raw/ notification_available.ogg
notification_out_of_service.ogg

Tela com as informaes sobre a aplicao. Servio executado em segundo plano que captura a posio corrente do dispositivo utilizando GPS e envia dados atualizados para a tela. Tela de ajuda. Tela principal da aplicao. Encapsula um ponto armazenando sua latitude e longitude. Tela com o mapa e com uma rota armazenada. Tela com a lista de todas as rotas armazenadas. Tela de preferncias da aplicao. Encapsula uma rota para salv-la. Tela com o mapa com a rota que esta sendo monitorada no momento e seus dados. Camada utilizada para exibir uma rota sobre o mapa. Criao e consultas do banco de dados utilizado para armazenar as rotas. Salva uma rota a partir de outro thread. Usada para notificar o usurio na barra de estado. Tela com as informaes de uma rota armazenada.

Classe gerada automaticamente. Usada para acessar os recursos.

Animao Tween aplicada na mensagem Carregando.... Forma utilizada no segundo plano da tela principal. cone da aplicao. Logotipo da aplicao. Imagem utilizada para notificar o usurio na barra de estado. Imagem utilizada para notificar o usurio na barra de estado. Imagem utilizada para notificar o usurio na barra de estado. Logotipo da PUC-Rio. Logotipo do VisionLab. Layout da tela de informaes sobre a aplicao. Layout da tela de ajuda. Layout da tela que lista as rotas armazenadas. Layout da tela principal. Layout da tela com o mapa e uma rota armazenada. Layout do dilogo utilizado para renomear uma rota. Layout da tela com o mapa e a rota atual. Layout da linha utilizada na lista de rotas armazenadas, que pode ser composta por vrias destas linhas (uma linha para cada item). Layout da tela com as informaes de uma rota armazenada. Layout da tela principal em modo paisagem. Layout da tela com as informaes de uma rota armazenada em modo paisagem. Menu de opes da tela que lista as rotas armazenadas. Menu de opes da tela principal. Menu de opes da tela com o mapa e a rota atual. Menu de opes da tela com o mapa e uma rota armazenada. Som utilizado para notificar a disponibilidade do GPS aps estar fora de servio e na primeira vez que uma posio capturada. Som utilizado para notificar o usurio que o GPS est fora de servio. Vetores com valores utilizados para gerar a tela de preferncias. Todos os textos da aplicao em ingls. Todos os textos da aplicao em portugus. Arquivo utilizado para gerar a tela de preferncias. Arquivo de manifesto da aplicao. Contm, dentre outros, as permisses, as bibliotecas e os componentes utilizados na aplicao.

values/ arrays.xml strings.xml values-pt/ strings.xml xml/ preferences.xml AndroidManifest.xml

44

A5: Especificaes do dispositivo real utilizado para testes

Smartphone Samsung Galaxy I7500:

Dimenses: 115,4 x 57 x 12,5 mm Peso: 116g Frequncia: Quad-Band GSM / 3G Conexo HSDPA 7.2 Mps / HSUPA 5.76 Mbps CPU (ARM11) MSM7200A 528 MHz 128 MB RAM Display Touchscreen 3.2 - HVGA (320 x 480) AMOLED Android OS, v1.5 (Cupcake) Cmera fotogrfica de 5 megapixels com flash Power LED USB 2.0 Bluetooth 2.1 GPS Wi-Fi b / g Acelermetro Bateria: 1500 mAh Memria interna de 8GB expansvel por carto microSD Capacidade mxima de memria: 32GB