aplicativo para previsÃo do tempo em plataforma...

UNIVERSIDADE DE RIBEIRÃO PRETO

CENTRO DE CIÊNCIAS EXATAS, NATURAIS E TECNOLÓGICAS

ENGENHARIA DE COMPUTAÇÃO

DIEGO MASCAGNI

APLICATIVO PARA PREVISÃO DO TEMPO EM

PLATAFORMA ANDROID

Ribeirão Preto

2011

DIEGO MASCAGNI

APLICATIVO PARA PREVISÃO DO TEMPO EM

PLATAFORMA ANDROID

Monografia apresentada ao Centro de Ciências

Exatas, Naturais e Tecnológicas da

Universidade de Ribeirão Preto como parte dos

requisitos para obtenção do grau de Engenheiro

de Computação.

Orientador: Prof. Dr. Rodrigo de Oliveira

Plotze

Ribeirão Preto

2011

Ficha catalográfica preparada pelo Centro de Processamento

Técnico da Biblioteca Central da UNAERP

- Universidade de Ribeirão Preto -

Mascagni, Diego, 1988 - M395a Aplicativo para previsão do tempo em plataforma android / Diego Mascagni. - - Ribeirão Preto, 2011.

55 f.: il. color.

Orientador: Prof. Dr. Rodrigo de Oliveira Plotze. Monografia (graduação) - Universidade de Ribeirão Preto,

UNAERP, Engenharia da computação. Ribeirão Preto, 2011.

1. Sistemas operacionais. 2. Plataforma android. I. Título.

CDD: 005.1

FOLHA DE APROVAÇÃO

784.952 – Diego Mascagni

Aplicativo para Previsão do Tempo em Plataforma Android

Monografia apresentada ao Centro de Ciências

Exatas, Naturais e Tecnológicas da

Universidade de Ribeirão Preto como parte dos

requisitos para obtenção do grau de Engenheiro

de Computação.

Orientador: Prof. Dr. Rodrigo de Oliveira

Plotze

Aprovada em: 19/12/2011

Banca Examinadora

Prof. Dr. Rodrigo de Oliveira Plotze (orientador)

Instituição: Universidade de Ribeirão Preto – UNAERP

Prof. Msc. Luís Fernando Cozin


Prof. Msc. Luciano A. L. Saraiva


DEDICATÓRIA

Dedico este trabalho a todos os meus familiares, por acreditarem no meu sonho e

permitirem que ele fosse possível de ser realizado. A eles, principalmente aos meus pais, Luís

e Maria, e também ao meu irmão, Wellington, digo que aqui está concluída mais uma grande

etapa da minha vida e, com certeza, da vida de vocês também.

Sinceramente, o meu grande obrigado!

AGRADECIMENTOS

Agradeço, primeiramente, a Deus, pois, sem Ele, nada disto seria possível. Por Ele,

tive saúde, capacidade e motivação para chegar até aqui.

Agradeço aos meus pais por me darem todas as condições necessárias para estudar.

Chegar até a Faculdade foi e é ainda uma grande conquista.

Agradeço a todos os professores que tive durante o decorrer destes vários anos, desde

a infância até esta fase em que me encontro. Em especial, ao Prof. Dr. Rodrigo de Oliveira

Plotze, por ser o meu orientador, e por me ajudar na realização deste trabalho.

Agradeço também aos meus amigos de sala, que estiveram comigo ao longo destes

cinco anos, nos momentos de diversão e também naqueles mais difíceis.

Por fim, a todos aqueles que, de forma direta ou indireta, participaram da minha vida e

que permitiram que isto ocorresse.

Meus sinceros agradecimentos!

RESUMO

MASCAGNI, D. Aplicativo para Previsão do Tempo em Plataforma Android. 83 p.

Monografia (Graduação em Engenharia de Computação) – Centro de Ciências Exatas,

Naturais e Tecnológicas, Universidade de Ribeirão Preto, Ribeirão Preto-SP, 2011.

Este trabalho tem como objetivo o desenvolvimento de uma aplicação, voltada ao Sistema

Operacional Android, que realize a previsão do tempo de uma determinada localidade. Esta

localidade será definida a partir das coordenadas geográficas (latitude e longitude) obtidas por

meio de um dispositivo móvel (smartphone), dotado da tecnologia GPS. Para a sua realização,

foram estudadas diversas características importantes deste SO, como seu funcionamento

interno, além de como é feita a programação destinada a ele. Basicamente, após obter as

informações, a aplicação acessa um serviço existente na Internet que informará em qual local

físico o usuário se encontra e onde ele está localizado no mapa. Após esta definição, pode-se

descobrir qual é a provável previsão do tempo, ao se acessar outro serviço Web.

Palavras-chave: Android, Previsão do Tempo, GPS, Sistemas Operacionais

ABSTRACT

MASCAGNI, D. Application to Weather Forecasting on Android Platform. 83 p. Monografia

(Graduação em Engenharia de Computação) – Centro de Ciências Exatas, Naturais e

Tecnológicas, Universidade de Ribeirão Preto, Ribeirão Preto-SP, 2011.

This work search developing an application, directed to the Android Operating System, that

realize weather forecasting of some location. This location will be defined from the

geographic coordinates (latitude and longitude), received through a mobile device

(smartphone), compatible with GPS technology. For your realization, were studied several

characteristics this OS, per example, your internal running, or your programming. Basically,

after to get the informations, the application accesses a service on Internet that will inform

your real localization and your local on the map. After that definition, will can discover

what‟s the probable weather forecast, when accessing other Web service.

Keywords: Android, Weather Forecast, GPS, Operating Systems

SUMÁRIO

1. INTRODUÇÃO ................................................................................................................ 11 1.1. OBJETIVO ................................................................................................................ 12 1.2. ESTRUTURA DA MONOGRAFIA ......................................................................... 12

2. SISTEMA OPERACIONAL ANDROID ........................................................................ 14

2.1. CONSIDERAÇÕES INICIAIS ................................................................................. 14 2.2. HISTÓRICO .............................................................................................................. 14

2.2.1. Principais Versões do Android ........................................................................... 17 2.3. ARQUITETURA DO SISTEMA .............................................................................. 21 2.4. CARACTERÍSTICAS ............................................................................................... 23

2.5. GERENCIAMENTO DE PROCESSO ..................................................................... 24 2.6. GERENCIAMENTO DE MEMÓRIA ...................................................................... 24

2.7. SEGURANÇA ........................................................................................................... 25 2.8. CONSIDERAÇÕES FINAIS .................................................................................... 26

3. TÉCNICAS DE PROGRAMAÇÃO PARA O SO ANDROID ....................................... 27 3.1. CONSIDERAÇÕES INICIAIS ................................................................................. 27

3.2. FRAMEWORK ........................................................................................................... 27 3.3. BIBLIOTECAS ......................................................................................................... 29

3.4. INTERFACES GRÁFICAS ...................................................................................... 31 3.5. ARMAZENAMENTO DE DADOS ......................................................................... 33 3.6. MULTIMÍDIA ........................................................................................................... 34

3.7. COMPILAÇÃO E DISTRIBUIÇÃO ........................................................................ 35

3.8. AMBIENTES PARA DESENVOLVIMENTO ........................................................ 36 3.9. CONSIDERAÇÕES FINAIS .................................................................................... 39

4. CONCEITOS DE PREVISÃO DO TEMPO E GPS ........................................................ 40

4.1. CONSIDERAÇÕES INICIAIS ................................................................................. 40 4.2. PREVISÃO DO TEMPO ........................................................................................... 40

4.3. SISTEMA DE POSICIONAMENTO GLOBAL ...................................................... 41

4.4. CONSIDERAÇÕES FINAIS .................................................................................... 43 5. MATERIAIS E MÉTODOS ............................................................................................. 45

5.1. MATERIAIS UTILIZADOS ..................................................................................... 45 5.2. DESENVOLVIMENTO ............................................................................................ 45

5.2.1. Modelagem e Diagrama de Classes .................................................................... 45

5.2.2. Interfaces Gráficas .............................................................................................. 49

5.2.3. O Arquivo AndroidManifest.xml ........................................................................ 62

6. RESULTADOS E DISCUSSÃO ..................................................................................... 65 6.1. RESULTADOS DO EMULADOR ........................................................................... 65

6.2. RESULTADOS REAIS ............................................................................................. 71 6.2.1. Criação de um Arquivo de Instalação................................................................. 71 6.2.2. Testes .................................................................................................................. 72

6.3. DISCUSSÃO ............................................................................................................. 77 7. CONCLUSÃO .................................................................................................................. 78

REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 79

LISTA DE FIGURAS

Figura 1 – Logo do Android ..................................................................................................... 15

Figura 2 – HTC G1 ................................................................................................................... 16 Figura 3 – Google Nexus One .................................................................................................. 17 Figura 4 – Indicador do uso de bateria ..................................................................................... 18 Figura 5 – Múltiplas contas no Android 2.0/2.1 ....................................................................... 19 Figura 6 – Nova interface do Android 2.2 ................................................................................ 20

Figura 7 – Interface do Android 3.0 ......................................................................................... 21 Figura 8 – Arquitetura do Sistema Android.............................................................................. 22 Figura 9 – Hierarquia de um ViewGroup ................................................................................. 32

Figura 10 – Plataformas instaladas pelo Android SDK ............................................................ 37 Figura 11 – Alguns AVDs criados ........................................................................................... 38 Figura 12 – Criação de um novo Projeto Android .................................................................... 39 Figura 13 – Disposição do projeto criado ................................................................................. 46 Figura 14 – Modelo esquemático da aplicação ........................................................................ 47

Figura 15 – Diagrama de Classes do projeto ............................................................................ 48

Figura 16 – Activities utilizadas na aplicação: (a); (b); (c) e (d) .............................................. 52 Figura 17 – AVD utilizado para os testes do projeto ............................................................... 65

Figura 18 – Tela inicial da aplicação ........................................................................................ 66 Figura 19 – Apresentação da tela Sobre ................................................................................... 66 Figura 20 – Início da aplicação ................................................................................................ 67

Figura 21 – Momento de indicação de Sem Latitude! e Sem Longitude! ................................. 68

Figura 22 – Carregamento de acesso ao servidor da API Yahoo Place Finder ....................... 69 Figura 23 – Retorno do endereço definido pelas coordenadas ................................................. 69 Figura 24 – Indicação do ponto no mapa através de um overlay ............................................. 70

Figura 25 – Retorno da Previsão do Tempo ............................................................................. 70 Figura 26 – Smartphone Motorola Quench .............................................................................. 72

Figura 28 – Aplicativo instalado com sucesso ......................................................................... 73 Figura 27 – Permissões necessárias para a instalação .............................................................. 73 Figura 29 – Menu do Android, com todas as aplicações instaladas ......................................... 74 Figura 30 – Mensagem informativa sobre a necessidade de se ligar o GPS ............................ 74

Figura 31 – Confirmação de GPS ligado .................................................................................. 75 Figura 32 – Resultado de localização na cidade de Pitangueiras ............................................. 75 Figura 33 – Resultado de localização para a cidade de Ribeirão Preto .................................... 76

Figura 34 – Sem retorno de previsão do tempo nas cidades testadas ....................................... 76

file:///D:/Meus%20Documentos/Engenharia%20da%20Computação/2011/Projeto%20de%20Conclusão%20de%20Curso%20II/Monografia%20-%20Diego%20Mascagni.doc%23_Toc312147325

LISTA DE SIGLAS

2D Duas Dimensões

3D Três Dimensões

3G Terceira Geração

AAC Advanced Audio Coding

ADC Android Developer Challenge

ADT Android Development Tools

AMR Adaptive Multi-Rate

API Application Programming Interface

APK Android Package File

AVD Android Virtual Device

C/A Coarse / Acquisition

CPTEC Centro de Previsão de Tempo e Estudos Climáticos

DoD Department of Defense

EDGE Enhanced Data Rates for GSM Evolution

Email Electronic mail

GB Gigabytes

GHz Gigahertz

GIF Graphics Interchange Format

GPS Global Positioning System

GSM Global System for Mobile Communications

HP Hewlett Packard

HTC High Tech Computer Corporation

HTTP Hypertext Transfer Protocol

INMET Instituto Nacional de Meteorologia

INPE Instituto Nacional de Pesquisas Espaciais

JDK Java Development Kit

JPEG Joint Photographic Experts Group

LCD Liquid Crystal Display

MB Megabytes

MHz Megahertz

MP3 MPEG-1/2 Audio Layer 3

MPEG4 Moving Picture Experts Group 4

MPx Megapixels

NAVSTAR-GPS Navigation System Using Time and Ranging - Global Positioning

System

NDFD National Digital Forecast Database

NOAA National Oceanic and Atmospheric Administration's

OHA Open Handset Alliance

OpenGL ES Open Graphics Library for Embedded Systems

P Precision

PNG Portable Network Graphics

SA Selective Availability

SD Secure Digital

SDK Software Development Kit

SGBD Sistema Gerenciador de Banco de Dados

SGL Scalable Graphics Library

SI Sistema Internacional

SO Sistema Operacional

SSL Secure Sockets Layer

USB Universal Serial Bus

UX User eXperience

VoIP Voice over Internet Protocol

Wi-Fi Wireless Fidelity

XML eXtensible Markup Language

11

1. INTRODUÇÃO

Até pouco tempo atrás, tarefas rotineiras no meio acadêmico ou profissional, ou até

mesmo no mundo do entretenimento (como o envio de mensagens de correio eletrônico

(email), a edição de documentos de texto com os últimos relatórios da empresa, jogos

eletrônicos super desafiantes e até a reprodução da série favorita que acabou de ser lançada

nos Estados Unidos) só podiam ser feitos com a utilização de um computador. Assim, caso

não houvesse a possibilidade de seu uso, certamente deixariam frustrados aqueles que

gostariam de realizar estas tarefas.

Apesar de sua popularização, os computadores não são máquinas viáveis de serem

transportadas de um local para o outro, devido a fatores como ao seu tamanho, quanto ao seu

peso, grandes em relação a outros dispositivos eletrônicos, incluídos os notebooks ou laptops,

netbooks, entre outros. Mas apesar de sua miniaturização em relação aos computadores

tradicionais, nem sempre eles podem estar ao alcance das mãos de quem precisa de seu uso

(por exemplo, não é uma coisa comum ver alguém com um notebook em uma sala de espera

em um consultório médico).

Assim, para situações como esta ou para praticamente todas as outras, os smartphones

(conhecidos também como telefones inteligentes) são a escolha mais recorrente para se

manter conectado a todos os benefícios trazidos pela “Era Digital”, mais especificamente a

Internet. A troca de mensagens instantâneas, postagem de fotos e comentários nas principais

redes sociais, visualização de vídeos enviados por diversos amigos e outras finalidades, não

são apenas possíveis como também são situações repetidas todos os dias na vida de quem os

possui.

Porém, para que estes dispositivos tenham estas funcionalidades, são necessárias

pessoas ou mesmo equipes inteiras envolvidas no processo de criação de novos aplicativos ou

jogos para as plataformas móveis. Este novo foco certamente é o futuro de um segmento da

tecnologia que deverá ainda movimentar milhões e milhões de dólares, e aqueles que

estiverem aptos a desenvolver as habilidades requeridas se destacarão muito bem no mercado.

Ainda mais que, a cada dia, seu preço de venda vem diminuindo devido a uma maior

aceitação dos consumidores, além de que, há ainda muitos mercados a serem explorados com

maior ênfase.

12

Isto leva a uma maior motivação e também a uma maior responsabilidade àqueles

desenvolvedores que desejam desenvolver para estas plataformas, pois só com inovações e

novas formas de uso ou interação é que poderão cativar os novos proprietários dos aparelhos.

E para aproveitar ainda mais esta mobilidade trazida pelos smartphones, diversos

aplicativos, que também podem ser conhecidos como apps, permitem realizar diversas

funcionalidades e tarefas úteis referentes à vida cotidiana: a previsão do tempo poderia ser um

bom exemplo.

Ela é útil àqueles indivíduos que gostam de se manter sempre informados e, acima de

tudo, estarem precavidos, podendo ter uma noção de como estará o tempo no momento de

saída para algum compromisso e como ele estará no momento de retorno à sua casa.

Com um determinado aplicativo, de interface amigável e de fácil utilização, que tenha

acesso à Internet, pode-se obter estas informações a partir de uma base de dados específica,

que retornará qual será a provável condição meteorológica no dia atual e, até mesmo, nos dias

subsequentes.

Desta maneira, evitam-se surpresas ou contratempos desagradáveis, que poderiam

prejudicar um compromisso importante, como uma reunião de trabalho, visto que, pode-se

programar antecipadamente em relação ao tempo nas próximas horas.

1.1. OBJETIVO

O objetivo do trabalho é apresentar o desenvolvimento de uma aplicação,

desenvolvida na linguagem de programação Java para o Sistema Operacional móvel Android,

com o intuito de disponibilizar informações sobre a previsão do tempo, utilizando-se para isto

as informações de latitude e longitude, que serão obtidas a partir do GPS (Global Positioning

System) do smartphone.

1.2. ESTRUTURA DA MONOGRAFIA

O trabalho está dividido em sete partes principais, sendo que a primeira apresenta a

Introdução, o objetivo e a estrutura da monografia.

A segunda parte (Capítulo 2) mostra a ambientação necessária para o SO (Sistema

Operacional) Android, como as considerações iniciais, o histórico, a arquitetura, suas

características, como são feitos os gerenciamentos de processo e de memória, a segurança,

finalizando com as considerações finais.

13

A próxima parte (Capítulo 3) corresponde às técnicas utilizadas para programação

nesta plataforma, abrangendo as considerações iniciais, o framework, as bibliotecas, as

interfaces gráficas, como se armazena dados, multimídia, a fase de compilação e distribuição

do software, alguns ambientes para desenvolvimento, além de suas considerações finais.

O Capítulo 4 engloba: as considerações iniciais, uma descrição de como é feita a

previsão do tempo, uma síntese sobre o Sistema de Posicionamento Global, além das

considerações finais.

A quinta parte (Capítulo 5) se refere aos materiais e métodos utilizados para o

desenvolvimento da aplicação, dividindo-se em: materiais utilizados e o desenvolvimento

propriamente dito (contando com a modelagem da aplicação, o seu diagrama de classes e suas

interfaces gráficas); finalizando-se com os testes experimentais e seus resultados, assim como

uma breve discussão, na sexta parte (Capítulo 6).

A próxima parte (Capítulo 7) é a conclusão do trabalho, seguindo, finalmente, para as

referências bibliográficas necessárias para a sua elaboração.

14

2. SISTEMA OPERACIONAL ANDROID

2.1. CONSIDERAÇÕES INICIAIS

Este capítulo abordará os principais aspectos da arquitetura do SO Android. Serão

apresentadas informações a respeito da evolução histórica, os desenvolvedores, os aparelhos

(smartphones) capazes de executar este sistema, além das principais versões lançadas até os

dias atuais.

Em seguida será mostrada como é organizada a arquitetura do sistema. Há também

uma enumeração de suas principais características presentes. Serão comentados os

gerenciamentos de processo e de memória, finalizando-se de que forma é tratada a segurança.

2.2. HISTÓRICO

O Android é um SO móvel, baseado no sistema operacional Linux, criado pela

empresa Google, destinado a smartphones e tablets, podendo ser utilizado, futuramente, em

outros dispositivos. Ele gerou uma grande repercussão no seu lançamento por ter o nome da

empresa Google envolvido (LECHETA, 2010).

Porém, não é apenas a empresa Google que participa do desenvolvimento desse

sistema. Há também várias empresas envolvidas nessa tarefa, companhias que fabricam

celulares (LG, Motorola, Samsung, Sony Ericsson, entre outras), operadoras de telefonia

celular (T-Mobile, Telecom Italia, Telefónica, Vodafone, entre outras), fabricantes de

semicondutores (ARM, Intel, Nvidia, entre outras), totalizando 80 empresas (OHA, 2011a). A

este conjunto é dado o nome de Open Handset Alliance (OHA). Este consórcio tem como

motivação expandir ainda mais o mercado de dispositivos móveis, visando garantir sempre a

melhor experiência possível, já que compreende as empresas líderes neste segmento, além de

permitir o desenvolvimento de qualquer tipo de aplicação, já que é uma plataforma open

source, ou seja, de código aberto (LECHETA, 2010; OHA, 2011b).

De uma forma geral pode-se dizer que o Android é:

[...] a nova plataforma de desenvolvimento para aplicativos móveis como

smartphones e contêm um sistema operacional baseado em Linux, uma interface

visual rica, GPS, diversas aplicações já instaladas e ainda um ambiente de

desenvolvimento bastante poderoso, inovador e flexível. Outra boa notícia é que

pode-se utilizar a consagrada linguagem Java para desenvolver as aplicações,

usufruindo de todos os recursos a que se tem direito (LECHETA, 2010, p. 21).

15

Antes mesmo do Android ser realmente lançado, a empresa Google já havia lançado

um concurso para promover o sistema operacional, o Android Developer Challenge (ADC). O

total em prêmios era superior a US$ 10.000.000,00 (dez milhões de dólares norte-

americanos). Para isto, bastava apenas utilizar a primeira versão do Software Development Kit

(SDK), traduzido ao português como Kit de Desenvolvimento de Software, até o dia 14 de

abril de 2008. Como nesta época ainda não havia sido lançado um modelo compatível, era

utilizado o emulador do próprio SDK para os testes e execuções (LECHETA, 2010).

Um dos símbolos mais importantes da plataforma Android é a sua logo, que é

facilmente reconhecida. Ela é representada por um robô (daí o seu nome: um androide)

estilizado na cor verde (Figura 1).

Figura 1 – Logo do Android

Fonte: PDA MAGAZINE (2009)

Após o sucesso do concurso ADC, o primeiro smartphone a ser comercializado com

Android foi o G1, fabricado pela HTC (High Tech Computer Corporation) e disponibilizado

pela operadora T-Mobile nos Estados Unidos (Figura 2). Seu lançamento ocorreu no dia 22 de

outubro de 2008, a um custo de US$ 179,00 e teve seu estoque esgotado durante a fase de pré-

venda. Sua configuração envolvia uma tela LCD (Liquid Crystal Display) de 3,2 polegadas;

um teclado em estilo QWERTY (o mesmo utilizado nos computadores), para ser utilizado na

posição horizontal; um processador de 528 MHz (Megahertz); memória interna de 256 MB

(Megabytes), podendo ser expansível a até 8 GB (Gigabytes) de armazenamento com um

cartão de memória do tipo micro SD (Secure Digital); além de acesso à Internet usando-se a

16

rede de telefonia 3G (Terceira Geração) ou com um ponto de acesso Wi-Fi (Wireless

Fidelity).

Porém, o que mais se destaca é o conteúdo multimídia, como reprodução de músicas,

vídeos e imagens, e também a navegação na web (email, redes sociais, serviços da própria

Google – como o Gmail, o YouTube ou o Maps – e praticamente qualquer site que seja

possível de se navegar em um computador); além da opção de tirar fotos com a sua câmera –

porém sem a capacidade de gravação de vídeo (INFO, 2009; LECHETA, 2010).

Figura 2 – HTC G1

Fonte: T-MOBILE (2011)

Outro smartphone que se pode destacar é o Nexus One, o primeiro com a chancela da

empresa Google, fabricado também pela HTC e lançado no dia 5 de janeiro de 2010.

Destacam-se nele a tela touch screen (sensível ao toque) de 3,7 polegadas de grande qualidade

visual; teclado virtual (que usufrui desta característica táctil); interpretação de comandos de

voz – pode-se dizer algo que ele reconhecerá e realizará a ação; memória interna de 512 MB;

câmera de 5 MPx (Mega Pixels); processador de 1 GHz (Gigahertz); 3G, GPS, Wi-Fi, bússola

e acelerômetro (Figura 3). Na época de seu lançamento era vendido nos Estados Unidos por

US$ 529,00 (sem plano com nenhuma operadora) ou por US$ 179,00 (em um plano de dois

anos com a T-Mobile) (INFO, 2010).

17

Figura 3 – Google Nexus One

Fonte: GOOGLE PHONE GALLERY (2011)

2.2.1. Principais Versões do Android

No dia 7 de novembro de 2007 a OHA definitivamente anunciou o lançamento do

Android. De início havia apenas uma ideia vaga sobre o quê ele poderia realizar:

possibilidades de personalização pelas operadoras de telefonia ou acesso total às capacidades

e ferramentas de criação de softwares pelos programadores. Somente, a partir da primeira

versão, a 1.0, lançada com o HTC G1, foi possível ter um melhor entendimento sobre esta

plataforma. Porém, ela ainda apresentava limitações (IMASTERS, 2009a).

Após esta versão inicial, várias outras foram lançadas, cada uma adicionando

novidades. Duas curiosidades que se podem comentar acerca delas são: os seus nomes

representam um doce, escrito em inglês, onde a sua letra inicial segue a ordem alfabética; e a

outra seria a customização que cada fabricante de celular realiza na versão Android de seus

aparelhos, podendo-se citar algumas como: a HTC Sense, da empresa HTC; a MotoBlur, da

empresa Motorola, focada em redes sociais (principalmente Facebook e Twitter) e UX (User

eXperience), da empresa Sony Ericsson (IMASTERS, 2009a; LECHETA, 2010).

A seguir serão citadas as principais versões seguintes a 1.0:

18

1.5 Cupcake: foi lançada em maio de 2009, inicialmente disponível apenas

para o HTC G1 da T-Mobile. Era voltada para aplicações da Web 2.0, como o

envio de vídeos do aparelho para o YouTube ou de fotos para o serviço de

hospedagem de fotos da empresa Google, o Picasa. Também apresentava

modificações visuais (transição animada entre as janelas, rotação das janelas a

partir do acelerômetro e novas aparências nos aplicativos); maior velocidade na

inicialização e captura de imagens e vídeos pela câmera, e na aquisição do

sinal do GPS (ANDROID DEVELOPERS, 2009; IMASTERS, 2009b).

1.6 Donut: disponibilizada primeiramente nos smartphones G1, Hero e Magic,

ambos da HTC, via T-Mobile, a partir de outubro de 2009. Teve como

principais avanços: um novo aplicativo para a câmera, mais rápido; um

aplicativo de monitoramento de consumo da memória dos programas que estão

sendo executados (Figura 4); um sistema de busca universal melhorado; além

de aperfeiçoamentos para os desenvolvedores, como o suporte a

reconhecimento de gestos ou o sintetizador de voz, que pronuncia qualquer

tipo de texto (IMASTERS, 2009c).

Figura 4 – Indicador do uso de bateria

Fonte: ANDROID DEVELOPERS (2011a)

2.1 Eclair: começou a ser disponibilizada em janeiro de 2010. Consiste em

uma atualização da versão anterior, a 2.0; ambas podem ser consideradas

uma única versão. Trouxe como novidades a possibilidade de múltiplas

contas de email e contatos, com rápido acesso a eles – como a realização de

19

uma ligação ou o envio de uma mensagem eletrônica (Figura 5); a opção de

ajustes visuais na câmera (como zoom, balanço de branco e modos de cena,

entre outras) e suporte a flash; teclado virtual redesenhado que corrige mais

facilmente os erros de digitação; e uma performance gráfica melhor,

habilitada pela aceleração por hardware (ANDROID DEVELOPERS,

2010).

Figura 5 – Múltiplas contas no Android 2.0/2.1

Fonte: ANDROID DEVELOPERS (2010)

2.2 Froyo: lançada em maio de 2010, apresenta uma repaginação gráfica

mais bonita (esta nova interface é ilustrada na Figura 6, sendo a imagem do

lado esquerdo a tela principal ou Home e a da direita, uma tela para

destravamento do sistema). Ela apresenta um aumento na velocidade de

execução de aplicativos de 2x a 5x, graças a um compilador em tempo real;

também foi melhorado o desempenho em navegação Web, através do

incremento de 2x na renderização do JavaScript. Há o suporte ao Adobe

Flash, mas sem todas as possibilidades de utilização encontradas em

computadores comuns, e sem um desempenho convincente. Pode-se

também instalar nela novas aplicações diretamente no cartão de memória, o

que representa a utilização de inúmeros programas sem depender da

memória interna limitada do smartphone; ou utilizar-se o tethering, que

20

permite o compartilhamento da Internet 3G como se fosse uma rede sem

fio - Wi-Fi (IMASTERS, 2010a).

Figura 6 – Nova interface do Android 2.2

Fonte: IMASTERS (2010a)

2.3 Gingerbread: disponível inicialmente apenas para o Samsung Nexus S,

o novo smartphone com o nome da empresa Google, e tendo seu

lançamento em dezembro de 2010. Basicamente reúne as mesmas

características encontradas na versão anterior, a 2.2, além de uma melhora

em relação à velocidade e no consumo de energia da bateria – através do

gerenciamento dos aplicativos que estão em segundo plano. O teclado

virtual ficou mais bonito e prático, e permite copiar e colar sem os

problemas presentes na versão Eclair. Um grande destaque nesta versão é a

possibilidade de realizar ligações VoIP (Voice over Internet Protocol)

nativamente – através da Internet, sem custos adicionais (IMASTERS,

2010b; IMASTERS, 2010c).

3.0 Honeycomb: desenvolvida exclusivamente para tablets e lançada em

fevereiro de 2011. Foi feita do zero, tendo em vista todas as características

21

e funcionalidades presentes nestes dispositivos móveis. Nela há uma barra

de sistema com todos os botões de navegação, que substitui a área de

notificações existente nas versões para smartphones (Figura 7); a área

contextual apresenta várias opções de ações a serem executadas de acordo

com o programa que esteja em funcionamento. Seu teclado virtual é maior

e mais fácil de digitar palavras, aproveitando-se do tamanho físico da tela.

Capacidades básicas, como acesso web e câmera fotográfica ganham uma

nova percepção neste ambiente, com maior facilidade no seu uso

(SAMPAIO, 2011).

Figura 7 – Interface do Android 3.0

Fonte: ANDROID DEVELOPERS (2011b)

2.3. ARQUITETURA DO SISTEMA

A arquitetura da plataforma Android é dividida em cinco camadas principais, as quais

são demonstradas na Figura 8 e denominadas como de Aplicações, de Framework, de

Bibliotecas, de RunTime, e Kernel Linux (PEREIRA; SILVA, 2009).

22

Figura 8 – Arquitetura do Sistema Android

Fonte: ANDROID DEVELOPERS (2011c)

A primeira camada, chamada de Aplicações, está situada no mais alto nível, e

corresponde aos aplicativos básicos presentes no sistema – cliente de e-mails, navegador web,

discador para a realização de ligações, gerenciador de contatos, entre tantos outros que podem

ser instalados manualmente (PEREIRA; SILVA, 2009).

A segunda camada, a de Framework, possui as APIs (Application Programming

Interface ou em português, Interface de Programação de Aplicações) e recursos necessários

para a criação dos aplicativos. Isto permite que os desenvolvedores utilizem procedimentos

que já foram criados sem terem que reescrevê-los novamente. Nela, pode-se gerenciar e

comandar funções como as de bluetooth, Wi-Fi, USB (Universal Serial Bus), janelas, troca de

informações entre os aplicativos, estética e gráfica das aplicações e o ciclo de vida destas

aplicações (ANDROID DEVELOPERS, 2011c; PEREIRA; SILVA, 2009).

A camada de Bibliotecas se refere às bibliotecas com suporte a multimídia; de acesso a

banco de dados; representação de camadas 2D (duas dimensões) e 3D (três dimensões);

bibliotecas C/C++ (usadas por vários recursos do sistema, como a biblioteca padrão Libc; o

Webkit – que renderiza as páginas do navegador; ou o SQLite, que representa um banco de

dados relacional, incluído no próprio sistema); entre outras (PEREIRA; SILVA, 2009).

23

A menor camada, a RunTime, possui um conjunto de várias bibliotecas da linguagem

de programação Java, como as de funções de acesso a redes, a arquivos, estruturas de dados,

entre outras, presentes nas Core Libraries. Ao se executar uma aplicação, é criada uma

instância da Máquina Virtual Dalvik (que é otimizada para dispositivos de pouco desempenho

gráfico, de processamento e de armazenamento), independentes uma da outra, e que são

compatíveis com qualquer dispositivo com Android (PEREIRA; SILVA, 2009).

A última camada, a Kernel Linux, realiza diversos serviços do sistema, incluindo os

gerenciamentos de memória e de processo, segurança, protocolos de rede e drivers

compatíveis com os modelos. Utiliza-se da versão 2.6 do Linux e atua também como uma

abstração entre as camadas de hardware e software (PEREIRA; SILVA, 2009).

2.4. CARACTERÍSTICAS

De acordo com Pereira e Silva (2009), as principais características presentes no SO

Android são:

Possui um Framework de Aplicação, que possibilita a incorporação, a

reutilização e a substituição de recursos dos componentes, necessários à

criação de novas aplicações.

Apresenta uma Máquina Virtual própria, chamada de Dalvik, que foi criada

especialmente para atender às necessidades dos dispositivos móveis.

É disponibilizado com um navegador Web integrado, baseado em um projeto

de código aberto, chamado de WebKit.

São otimizados os gráficos, tanto os em 2D, quanto os em 3D (através da API

OpenGL ES – Open Graphics Library for Embedded Systems – na versão 1.0).

Vem integrado com um gerenciador de bancos de dados, chamado de SQLite,

direcionado ao armazenamento de dados estruturados.

Suporte nativo aos formatos multimídia mais comuns, tais como MP3 (MPEG-

1/2 Audio Layer 3), AAC (Advanced Audio Coding) e AMR (Adaptive Multi-

Rate), voltados a áudio; MPEG4 (Moving Picture Experts Group 4) e H.264,

para vídeo; e JPEG (Joint Photographic Experts Group), PNG (Portable

Network Graphics) e GIF (Graphics Interchange Format), para imagens.

Integra-se facilmente às tecnologias de telefonia GSM (Global System for

Mobile Communications), mas depende do hardware do dispositivo.

24

Suporte a protocolos sem fio, dependentes de hardware, como 3G, Wi-Fi e

EDGE (Enhanced Data Rates for GSM Evolution).

Integra-se a acessórios diversos, como, por exemplo, câmera fotográfica, GPS,

bússola e acelerômetro.

Além de possuir um ambiente de desenvolvimento completo, possuindo

emulador de um dispositivo real e ferramentas para o desenvolvimento

propriamente dito (PEREIRA; SILVA, 2009).

2.5. GERENCIAMENTO DE PROCESSO

Um componente de uma aplicação, quando é inicializado, cria um processo do SO

Linux para aquela aplicação, além de um thread (fluxo de execução), desde que, ainda não

exista nenhum outro componente dela sendo executado. Isto é definido por padrão,

independentemente de quantos componentes existirem para aquela aplicação.

Entretanto, se houver necessidade em um caso específico, podem ser criados processos

e threads separados. Para que ocorra isto, o desenvolvedor deve especificar essa situação

durante a sua implementação, em um arquivo chamado AndroidManifest.xml, podendo, desta

maneira, criar processos e threads únicos para cada componente ou, então, criar alguns

conjuntos separados. Porém, para que componentes de aplicações diferentes rodem em um

mesmo processo, elas devem possuir a mesma identificação de usuário Linux e serem

assinadas com o mesmo certificado (ANDROID DEVELOPERS, 2011d).

2.6. GERENCIAMENTO DE MEMÓRIA

O número de aplicações que podem ser executadas, ao mesmo tempo, é limitado à

quantidade de memória livre disponível, que é variável em cada dispositivo. Assim, o sistema

Android pode encerrar um determinado processo que não esteja sendo utilizado no momento,

para liberar memória suficiente para um aplicativo que será utilizado imediatamente pelo

usuário. O SO tenta manter um processo que não está sendo utilizado pelo maior tempo

possível, mas nem sempre isto é viável, visto que, a todo o momento, é requerida mais

memória.

Para determinar quais processos serão eliminados, o próprio sistema “mede” o grau de

importância deles em relação ao usuário. Esta classificação leva em conta o ciclo de vida do

processo, definida em uma hierarquia, que descarta aqueles de menor relevância primeiro. De

25

acordo com o Portal de Desenvolvedores Android – Android Developers (2011d), o ciclo de

vida é dividido em:

Processo em Primeiro Plano: é necessária a sua utilização pela tarefa realizada

pelo usuário no momento. Normalmente, há poucos processos em primeiro

plano existentes durante todo o tempo, e eles são eliminados apenas em último

caso, quando a memória está tão baixa, que atingiu o estado de paginação.

Processo Visível: ocorre quando não existe nenhum componente da aplicação

em primeiro plano, mas que possui o poder de alterar o que pode ser

visualizado na tela, como, por exemplo, se houver uma pausa na execução e,

logo em seguida, é retornado ao ponto anterior a que estava.

Processo do Serviço: é um processo que precisa estar, ao mesmo tempo, nas

duas categorias mais altas (Processo em primeiro plano e Processo visível). Ele

apresenta certas informações que são de interesse do usuário (como a execução

de uma música em segundo plano ou o download de dados). Só são eliminados

se não houver memória suficiente para mantê-lo junto com processos em

primeiro plano e processos visíveis.

Processo em Plano de Fundo: não é visível, no momento, ao usuário, já que foi

parado. Pode ser descartado a qualquer momento para acrescentar mais

memória aos outros tipos mais importantes, já que não causa um impacto

direto na experiência de uso do usuário, porém, aqueles que foram os mais

utilizados recentemente, serão os últimos a serem “mortos”.

Processo Vazio: não realiza qualquer atividade. Tem como único objetivo

acelerar a inicialização dele na próxima vez que ela for requerida. É o primeiro

tipo de processo a ser eliminado (ANDROID DEVELOPERS, 2011d).

2.7. SEGURANÇA

No Android, cada aplicação possui privilégios separados, onde cada uma delas

apresenta uma identidade de sistema Linux única, assim como há também certas partes do

próprio sistema que também são separadas. Isto faz com que sejam isoladas as aplicações

umas das outras, e estas, do sistema.

Por padrão, nenhuma aplicação tem poderes para realizar quaisquer operações que

interfiram ou prejudiquem outros aplicativos, o SO ou as informações pessoais do usuário

(como o acesso à agenda de contatos ou uma conta de email). Para que isto possa ocorrer,

26

deve-se ser autorizado explicitamente pelo núcleo de cada aplicação, através de um pedido de

autorização do sistema para o usuário, perguntando se este deseja que ela seja instalada com

as suas capacidades de execução necessárias, tendo-se ainda uma ou mais indicações no

próprio código fonte da aplicação (um arquivo chamado AndroidManifest.xml) solicitando o

uso de um recurso protegido do dispositivo, como, por exemplo, o GPS ou a bússola.

Além disto, cada aplicativo deve ser assinado por um certificado, que é mantido pelo

seu desenvolvedor. Cada um deles tem como objetivo identificar quem é o responsável pela

sua criação. Ao se instalar estes aplicativos, o gerenciador de pacotes do sistema verifica as

assinaturas em busca das permissões necessárias para o seu perfeito funcionamento. Caso as

aprove, elas são concedidas; caso contrário, qualquer tentativa será barrada e o usuário não

terá nenhum aviso acerca disto (ANDROID DEVELOPERS, 2011e).

2.8. CONSIDERAÇÕES FINAIS

Tendo-se concluído o conhecimento teórico acerca do SO Android, pode-se agora

avançar em direção a como é feita a programação para esta plataforma, que será esclarecida

adiante, no Capítulo 3.

27

3. TÉCNICAS DE PROGRAMAÇÃO PARA O SO ANDROID


Este capítulo é destinado à explicação de algumas técnicas e conceitos utilizados para

o desenvolvimento de aplicações voltadas ao Sistema Operacional Android.

Inicia-se com a enumeração dos componentes que pertencem às camadas de

Framework e de Bibliotecas, com a citação de algumas interfaces e alguns métodos que

existem neles. Em seguida, como são tratadas as interfaces gráficas e como se pode realizar o

armazenamento de dados.

Será descrito sobre a área de multimídia, com a reprodução de áudio e vídeo e a

obtenção de imagens com a câmera do dispositivo. Encerrando-se com a compilação e a

distribuição das aplicações desenvolvidas, além de alguns ambientes existentes para a criação

delas.

3.2. FRAMEWORK

A camada de Framework, pertencente à arquitetura da plataforma Android, é dividida

em nove classes principais, sendo elas: Activity Manager, Window Manager, Content

Providers, View System, Package Manager, Telephony Manager, Resource Manager,

Location Manager e Notification Manager (PEREIRA; SILVA, 2009).

A classe Activity Manager, estendida de android.app.ActivityManager, tem como

objetivo realizar o gerenciamento de todas as atividades que estão sendo executadas pelo

sistema no momento. Ela apresenta diversos métodos, utilizados para se obter informações,

como: verificar quanto de memória está disponível (classe

getMemoryInfo(ActivityManager.MemoryInfo)), quais processos estão sendo executados

(classe ActivityManager.RunningAppProcessInfo), quais são os atributos de configuração do

dispositivo (método getDeviceConfigurationInfo()), a quantidade de memória que é utilizada

por um ou mais processos (getProcessMemoryInfo(int[] pids)), entres outros (ANDROID

DEVELOPERS, 2011f).

A classe Window Manager, herdeira de android.view.WindowManager, é usada como

uma interface, na qual os aplicativos em execução a utilizam para se comunicar com o

gerenciador de janelas. Ela apresenta dois métodos públicos: public abstract Display

getDefaultDisplay(), usado para a obtenção de um objeto padrão do tipo Display; e public

http://developer.android.com/reference/android/app/ActivityManager.html#getDeviceConfigurationInfo%28%29http://developer.android.com/reference/android/app/ActivityManager.html#getProcessMemoryInfo%28int[]%29

28

abstract void removeViewImmediate (View view), utilizado para se remover um objeto do tipo

View, onde seu uso deve ser feito com cuidado, já que não é recomendado a aplicações

normais (ANDROID DEVELOPERS, 2011g).

A classe Content Provider ou, em português, Provedor de Conteúdo, pertencente a

android.content.ContentProvider, permite que certas informações tornem-se públicas a outras

aplicações instaladas, podendo estas informações serem consultadas, inseridas, alteradas, ou,

até mesmo, excluídas. Podem ser consultados os contatos da agenda, ou arquivos de imagem

ou de vídeo, entre outros.

Por exemplo, para se verificar todos os contatos da agenda telefônica, é necessário o

comando content://com.android.contacts/contacts/; já para o retorno de todas as imagens

armazenadas basta utilizar-se: content://media/internal/images/media/ (LECHETA, 2010).

View System é utilizado para a realização da interface gráfica da aplicação, podendo

ela ser uma View (usada para a geração de botões, de textos, e outros) ou um View Group (que

é relacionado ao layout da aplicação) (PEREIRA; SILVA, 2009).

O Package Manager, que existe a partir da importação da classe

android.content.pm.PackageManager, tem a função de recuperar diversos tipos de

informações acerca dos pacotes das aplicações que estão instalados no dispositivo, como os

que se referem: à bluetooth, à câmera, à bússola, ao acelerômetro, e outros. Um método que

pode ser citado é: public abstract Resources getResourcesForApplication (ApplicationInfo

app), que recupera informações dos recursos utilizados em uma aplicação; dentre outros

(ANDROID DEVELOPERS, 2011h).

O Gerenciador de Telefonia ou, como definido, Telephony Manager, vindo de

android.telephony.TelephonyManager, obtém informações sobre o estado e os serviços da

rede telefônica (como: tipo de rede, protocolos utilizados, informações do chip da operadora

utilizado no dispositivo, entre outros). Existem diversos métodos utilizados para se obter

informações, podendo ser citados os seguintes: getCallState(), que retorna o estado de

chamada da rede; getCellLocation(), que mostra a localização atual do dispositivo;

getNetworkType(), que retorna uma constante com o tipo de tecnologia de rádio utilizado na

rede; entre outros (ANDROID DEVELOPERS, 2011i).

A classe Resource Manager é indicada para a criação de configurações personalizadas

da aplicação a ser executada em dispositivos diferentes, podendo ser: tamanhos de tela

diferentes, ou outros idiomas a serem mostrados. Assim, de acordo com a configuração

determinada àquele dispositivo, a exibição pode ser totalmente diferente de outro dispositivo

http://developer.android.com/reference/android/telephony/TelephonyManager.html#getCallState%28%29http://developer.android.com/reference/android/telephony/TelephonyManager.html#getCellLocation%28%29http://developer.android.com/reference/android/telephony/TelephonyManager.html#getNetworkType%28%29

29

de configurações contrárias a ele. Estas personalizações podem ser criadas dentro do diretório

res/ presente no projeto de desenvolvimento da aplicação (ANDROID DEVELOPERS,

2011j).

Location Manager, vinda de android.location.LocationManager, tem a função de

acessar serviços de localização do sistema, como, por exemplo, a localização geográfica, que

é atualizada periodicamente. Esta classe possui métodos que fazem o tratamento e o

gerenciamento do GPS, como o método public boolean addGpsStatusListener

(GpsStatus.Listener listener), que adiciona um listener ou ouvinte de status ao GPS, e é

responsável por receber as atualizações de localização quando elas ocorrem; ou descobrir o

estado atual dele (public GpsStatus getGpsStatus (GpsStatus status)); entre outros métodos

(ANDROID DEVELOPERS, 2011k).

Por fim, a classe Notification Manager tem o intuito de informar o usuário sobre

eventos que aconteceram ou estão acontecendo em plano de fundo, através de notificações. É

derivada de android.app.NotificationManager. As notificações que podem ser feitas são:

mostrar determinado ícone na barra de status sobre alguma aplicação ou tarefa que está sendo

realizada; ligar ou piscar luzes do dispositivo; ou alertar o usuário sobre algo, através de

alguma luz que está piscando, execução de algum som, ou vibrando-se o dispositivo.

De acordo com ANDROID DEVELOPERS (2011l), dois métodos que poderiam ser

utilizados para realizar uma notificação seriam: public void notify (int id, Notification

notification), que introduz um ícone de notificação na barra de status; ou public void notify

(String tag, int id, Notification notification), que tem a mesma função do anterior. Os

parâmetros id devem ser únicos àquela aplicação; tag é um identificador do tipo string para a

aplicação, podendo ser nulo; e notification é um objeto do tipo Notification, não nulo, que

descreve o que será mostrado ao usuário.

3.3. BIBLIOTECAS

De acordo com Pereira e Silva (2009), as Bibliotecas, que fazem parte, também, de

uma camada da Arquitetura do SO Android, são formadas pelos elementos: Surface Manager,

Media Framework, SQLite, OpenGL / ES, Freetype, WebKit, SGL, SSL, e Libc.

O Surface Manager é o responsável pelo gerenciamento de gráficos em 2D ou em 3D,

a serem visualizados na tela do dispositivo, podendo eles serem de uma única aplicação, ou de

várias outras (ANDROID DEVELOPERS, 2011c).

30

Esta classe é importada de android.view.Surface, e apresenta constantes do tipo de

dado inteiro, que podem ser utilizadas para realizar certos efeitos na apresentação das telas,

como: borrões (FX_SURFACE_BLUR), escurecimento (FX_SURFACE_DIM), escondê-las

(SURFACE_HIDDEN), entre outras. Um método interessante seria o de congelamento (void

freeze()) ou de ocultamento (void hide()) destas mesmas telas, entre outros mais (ANDROID

DEVELOPERS, 2011m).

As Bibliotecas de Mídia (Media Framework) proveem suporte aos formatos

multimídia – áudio, vídeo e imagem – mais comuns, que poderão ser utilizados para

enriquecer ainda mais uma aplicação Android (ANDROID DEVELOPERS, 2011c).

Para poder manipular estes arquivos é utilizado o pacote android.media, que possui

classes voltadas a esta especialidade. Podem ser citadas, dentre outras classes: a AudioRecord

– utilizada para gravação de áudio a partir de uma fonte de entrada; a FaceDetector – usada

na detecção do rosto de uma pessoa, ao gerar um objeto do tipo Bitmap; e a MediaPlayer, que

tem a função de realizar o controle da reprodução de arquivos de áudio e/ou vídeo

(ANDROID DEVELOPERS, 2011n).

Tarefas relacionadas a banco de dados, como a criação ou manutenção destes, são

executadas através do SQLite, um banco de dados relacional poderoso e leve, que, para

funcionar corretamente, precisa utilizar o pacote android.database.sqlite. Ele pode realizar

consultas, a partir da classe SQLiteQuery, entre outras funções, que existem em SGBDs

comuns (ANDROID DEVELOPERS, 2011o).

O OpenGL / ES é uma “versão” direcionada a dispositivos móveis da biblioteca de

gráficos tridimensionais OpenGL, utilizada na concepção de jogos, aplicações gráficas, entre

outras (ANDROID DEVELOPERS, 2011c). Para poder utilizá-la na criação de uma

aplicação, é necessária a chamada do pacote android.opengl, que apresenta todas as utilidades

necessárias para o seu uso, como a renderização de uma interface genérica (interface

GLSurfaceView.Renderer), ou da manipulação de uma matriz matemática (classe Matrix)

(ANDROID DEVELOPERS, 2011p).

O Freetype tem como objetivo realizar a renderização de imagens Bitmap ou de fontes

(ANDROID DEVELOPERS, 2011c). A renderização de fontes pode ser feita a partir da

classe Font, presente em android.renderscript.Font. Assim, podem ser utilizados diversos

estilos para serem executados a múltiplas fontes (negrito, itálico ou sublinhado), alteração do

seu tamanho, de sua cor, entre outras modificações. Um método para criação de uma fonte

seria: public static Font create (RenderScript rs, Resources res, String familyName,

http://developer.android.com/reference/android/media/AudioRecord.htmlhttp://developer.android.com/reference/android/media/FaceDetector.htmlhttp://developer.android.com/reference/android/database/sqlite/SQLiteQuery.htmlhttp://developer.android.com/reference/android/opengl/GLSurfaceView.Renderer.html

31

Font.Style fontStyle, float pointSize), em que familyName especifica o nome da fonte

desejada, como, por exemplo, Arial (ANDROID DEVELOPERS, 2011q).

O pacote WebKit, denominado como android.webkit, fornece as ferramentas

necessárias para a criação de uma aplicação que possa navegar na Web. Algumas classes

pertencentes a ele são: WebView (que representa a página Web a ser exibida),

GeolocationPermissions (utilizada para, caso seja permitida, obter a geolocalização do

dispositivo, que terá acesso a alguma página), WebViewDatabase (uma WebView que utiliza

banco de dados), entre outras (ANDROID DEVELOPERS, 2011r).

A biblioteca SGL, sigla de Scalable Graphics Library, é uma biblioteca gráfica 2D de

baixo nível, criada em código nativo do sistema. Ela atua junto com outras camadas de nível

mais alto do Framework, como o Windows Manager ou o Surface Manager, para realizar as

funcionalidades gráficas (ANDROID DEVELOPERS, 2011c).

O SSL, ou em inglês, Secure Sockets Layer, utilizado a partir do pacote javax.net.ssl,

tem a finalidade de prover as classes e interfaces precisas para o desenvolvimento de sockets

para a plataforma Android. Assim, uma aplicação cliente pode realizar uma requisição ao

servidor, e este, retornar a tarefa desejada. A interface para criação de uma sessão SSL é a

SSLSession; a API para a implementação do protocolo SSL é a SSLContext; entre outras

tantas existentes (ANDROID DEVELOPERS, 2011s).

Por fim, a Libc, ou Biblioteca Padrão C, é uma biblioteca voltada a dispositivos que

são controlados por Linux; esta mesma biblioteca possui uma versão desenvolvida

especialmente para o Android, que é customizada e otimizada a ele, chamada de Bionic

(PEREIRA; SILVA, 2009).

3.4. INTERFACES GRÁFICAS

Segundo Pereira e Silva (2009), existem duas formas de apresentar algo na tela do

dispositivo: as Views e as ViewsGroups.

Uma View, instância herdada da classe android.view.View, representa um retângulo de

apresentação ao usuário. A ela, podem ser incluídos diversos elementos, chamados de

Widgets, sendo os principais: TextView (caixa de saída de texto), EditText (caixa de entrada de

texto), Button (botão comum), RadioButton (botão de dois ou mais estados, onde é possível

escolher apenas um), Checkbox (botão de dois ou mais estados, que pode ser escolhida mais

de uma opção), ImageButton (botão que possui uma imagem) e ImageView (imagem a ser

http://developer.android.com/reference/android/webkit/WebView.htmlhttp://developer.android.com/reference/android/webkit/WebViewDatabase.htmlhttp://developer.android.com/reference/javax/net/ssl/SSLSession.htmlhttp://developer.android.com/reference/javax/net/ssl/SSLContext.html

32

mostrada), entre outros. Para que os componentes possam ser desenhados na tela, o método

onDraw(Canvas canvas) deve ser implementado.

Um elemento de uma View pode ser definido por um nome de referência, de

preferência único, chamado de ID. Ele possui, também, parâmetros para posicionamento e

tamanho. A posição pode ser definida como: left, top, width e height; a unidade utilizada por

eles é o pixel. O tamanho pode ser definido como: fill_parent (esta View ocupa o tamanho

máximo possível) e wrap_content (utiliza o tamanho mínimo para a ocupação) (LECHETA,

2010; PEREIRA; SILVA, 2009).

“Um viewgroup é uma view „pai‟ que pode conter e gerenciar um conjunto de views ou

viewgroups „filhas‟ de forma estruturada” (PEREIRA; SILVA, 2009, p. 68). Na Figura 9 é

representada uma possível hierarquia de um ViewGroup.

Figura 9 – Hierarquia de um ViewGroup

Fonte: ANDROID DEVELOPERS (2011t)

Dentro de um ViewGroup, existe um arquivo chamado Layout, que contém os objetos

filhos dele, informa qual será o comportamento destes “filhos” e o seu posicionamento na

tela. Os tipos de layout podem ser: FrameLayout (aloca-se somente um objeto, para preencher

a tela inteira), LinearLayout (organiza-os na horizontal ou na vertical), RelativeLayout (os

“filhos” são organizados em relação a eles mesmos ou em relação ao “pai”, podendo ser lado

a lado, acima ou abaixo), TableLayout (organizados em uma tabela, com linhas e colunas) e

AbsoluteLayout (especifica exatamente o posicionamento do “filho” – nos eixos x e y – em

relação ao “pai”, em pixels). Estes layouts são herdeiros da classe android.view.ViewGroup.

Podem ser configuradas também outras propriedades, como: height, width, margin e

border. Porém, é melhor configurar cada view individualmente (LECHETA, 2010; PEREIRA;

SILVA, 2009).

33

3.5. ARMAZENAMENTO DE DADOS

O Android, ao contrário dos SOs comuns, permite que apenas a aplicação que é

executada tenha pleno acesso aos dados utilizados. Porém, há uma maneira de fazer com que

estes dados privados sejam disponibilizados a outras aplicações, através do Content Provider,

que permite a possibilidade de leitura e escrita daqueles dados, desde que seja permitida sua

utilização (PEREIRA; SILVA, 2009).

Segundo Pereira e Silva (2009) existem quatro formas de armazenamento e

recuperação de dados:

Preferências: é uma forma simples para a realização de armazenamento e

recuperação de valores de tipos de dados primitivos, como as preferências do

usuário (por exemplo, uma mensagem de saudação).

Para acessá-los, é utilizado o método Context.getSharedPreferences()

ou o método Activity.getPreferences() - onde o primeiro permite o

compartilhamento de informações com outros componentes da mesma

aplicação, desde que haja um nome associado a este conjunto de preferências;

o segundo, sem um nome associado, mantém privada a preferência para a

atividade a ser chamada.

Arquivos: em dispositivos que utilizam o SO Android, podem ser

armazenados arquivos no próprio aparelho ou, então, em um cartão de

memória; porém, estes arquivos só podem ser utilizados pelo aplicativo que os

possui.

Para poder ler as informações presentes neste arquivo, é usado o

método Context.openFileInput(), seguido do nome local e do seu caminho; será

retornado um objeto padrão do tipo FileInputStream.

Já para a escrita no arquivo, usa-se o método Context.openFileOutput(),

seguido de seu nome local e caminho; retornar-se-á um objeto do tipo

FileOutputStream.

Bases de Dados: é utilizado o SGBD (Sistema Gerenciador de Banco de

Dados) SQLite, que é simples e pequeno, e apresenta a possibilidade de criação

de um arquivo em disco, onde se pode ler e escrever informações diretamente

sobre ele.

34

O objeto SQLiteDatabase representa uma base de dados, onde sua

criação é feita através da chamada SQLiteDatabase.create(), utilizando-se da

subclasse SQLiteOpenHelper.

Os dados armazenados podem ser manipulados utilizando-se comandos

como: Select, Insert, Update e Delete; e definidos por: Create, Alter e Drop.

Todas as bases de dados criadas e armazenadas no dispositivo ficam em:

/data/data/nomedopacote/databases/, e podem ser acessadas pelo nome em

qualquer outra classe da mesma aplicação, mas não fora desta.

Rede: quando existir alguma rede disponível, há a possibilidade de utilizá-la

para o armazenamento e a recuperação de dados. Para esta finalidade existem

duas classes que podem ser utilizadas para realizar a implementação:

Java.net.* (realiza a manipulação de endereços de Internet e trata de

solicitações do protocolo HTTP - Hypertext Transfer Protocol – ou, em

português, Protocolo de Transferência de Hipertexto) e Android.net.* (auxilia o

acesso à rede, além de complementar as funcionalidades existentes em

Java.net).

3.6. MULTIMÍDIA

O SO Android tem como característica a reprodução de diversos formatos multimídia,

sendo eles de imagem, de áudio e de vídeo. Pode haver uma grande quantidade destes

arquivos, visto que, com cartões de memória de maior espaço de armazenamento, tem-se esta

oportunidade.

Para reproduzir um arquivo de áudio, por exemplo, um no formato MP3, deve-se

utilizar a classe android.media.MediaPlayer e este arquivo deve estar na pasta do projeto

chamada res/raw; ao ser compilada esta aplicação, o arquivo já estará embutido nela; ou

então, uma outra alternativa seria carregá-lo diretamente do cartão de memória.

Assim, para Lecheta (2010), uma forma bem simples de se reproduzir este arquivo,

presente na mesma pasta do projeto, seria escrever o código como apresentado no Quadro 1.

Quadro 1 – Comando para execução de áudio

MediaPlayer player = MediaPlayer.create(this, R.raw.nome_do_arquivo);

player.start();

35

Esta é uma implementação básica, sem grande detalhamento de comandos; porém,

pode-se simular um reprodutor real, com recursos mais completos (funções de pausa, parar e

reproduzir novamente) utilizando-se, respectivamente, os métodos pause(), stop() e reset();

caso a aplicação não seja mais utilizada, pode-se usar o método release(), que libera os

recursos de memória que haviam sido utilizados para realizar a reprodução.

Já para a reprodução de vídeos, a classe MediaPlayer pode ser utilizada, porém, existe

uma classe mais simplificada, voltada a esta finalidade, chamada android.widget.VideoView.

Nela, para realizar a reprodução, basta chamar o método setVideoPath(arquivo), onde em

arquivo deve ser fornecido o caminho deste vídeo, e setMediaController(controlador), que

inclui automaticamente os comandos de reprodução. Um detalhe que se deve ter atenção é

quanto aos formatos de vídeo suportados pelo dispositivo, já que nem todos são compatíveis

(LECHETA, 2010).

É possível, também, manipular e editar imagens obtidas pela câmera do smartphone.

Existe uma classe chamada de android.hardware.Camera voltada exatamente para isto. O

desenvolvedor pode implementar todas as funções voltadas a obtenção das fotos (usando-se o

método takePicture()) e outras operações; ou então, utilizar o aplicativo nativo da câmera do

sistema, que gerará um objeto Bitmap que representa a imagem adquirida, poupando um

grande trabalho; assim, basta implementar o que se deseja com a imagem gerada (LECHETA,

2010).

3.7. COMPILAÇÃO E DISTRIBUIÇÃO

Ao ser compilada em algum ambiente de desenvolvimento, uma aplicação Android

gera um arquivo de extensão .apk (Android Package File), que nada mais é do que, todas as

classes e funcionalidades implementadas no projeto presentes em um único arquivo binário. O

próprio ambiente de desenvolvimento gera isto automaticamente. Assim, para se utilizar em

um dispositivo real, basta apenas copiar este arquivo para ele, instalá-lo, e executá-lo

(LECHETA, 2010).

Para uma forma mais cômoda de distribuição de aplicações, existe um portal próprio

para isto, podendo elas serem pagas ou gratuitas, chamado Android Market, que está

disponível no endereço: https://market.android.com/. Com ele, os desenvolvedores podem

cadastrar suas aplicações desenvolvidas, receber comentários e ter um ranking de

classificação delas, sendo necessário o pagamento de uma taxa única de US$ 25,00. Cerca de

70% do lucro gerado pela venda acaba sendo repassado ao seu criador (LECHETA, 2010).

36

Quanto aos usuários, é preciso apenas que entrem na aplicação própria do Android

Market, presente em seu dispositivo, escolher o aplicativo desejado, avaliar os comentários e

a classificação, se assim desejar, e realizar o download (LECHETA, 2010).

Sempre é preferível instalar uma aplicação vinda diretamente do Android Market, mas,

caso seja conhecida a sua idoneidade, não há problema de se instalar um .apk encontrado na

Internet (LECHETA, 2010).

3.8. AMBIENTES PARA DESENVOLVIMENTO

Segundo Lecheta (2010), podem ser criadas aplicações Android em qualquer ambiente

de desenvolvimento Java, tais como: Eclipse, Netbeans e IntelliJ IDEA.

A empresa Google incentiva o uso do Eclipse para a criação de suas aplicações. Por

este motivo, será adotado este ambiente para o desenvolvimento deste trabalho. Para facilitar

a vida do desenvolvedor, existe um plugin chamado ADT (Android Development Tools),

disponível no endereço: http://developer.android.com/sdk/eclipse-adt.html, que permite

utilizar um emulador Android diretamente do próprio Eclipse, onde se pode realizar

praticamente qualquer tarefa que seria possível em um dispositivo real (LECHETA, 2010).

Mas, antes da escolha e instalação de qual ambiente será utilizado, deve-se, primeiro,

instalar o Android SDK, disponível em: http://developer.android.com/sdk/index.html, que

apresenta todas as funcionalidades necessárias para a realização de aplicações voltadas a

dispositivos que utilizam Android. É preferível sempre instalar a versão mais recente, já que

ela provê as funcionalidades mais atuais; e, deve-se, também, ficar atento quanto à versão

corresponde ao SO utilizado para a implementação (PEREIRA; SILVA, 2009).

Finalizado o download desta ferramenta, é necessária a sua descompactação em algum

diretório qualquer. Em seguida, é requerida a instalação das plataformas (versões) do Android,

visto que o arquivo baixado encontra-se sem nenhuma disponível; basta apenas executar o

executável SDK Setup.exe e escolher quais são as desejadas. Na Figura 10 são apresentadas

algumas plataformas já previamente instaladas (LECHETA, 2010).

37

Figura 10 – Plataformas instaladas pelo Android SDK

Terminadas todas estas etapas, pode-se instalar o ambiente de desenvolvimento

preferencial. Porém, para poder utilizar o emulador do Android, tem-se que criar um AVD

(Android Virtual Device) ou, em português, Dispositivo Android Virtual, que nada mais é do

que, uma configuração que permite com que o emulador simule exatamente um dispositivo

real, com todas as suas características, tais como tamanho de tela, resolução, capacidade de

memória, entre outras. Esta configuração pode ser feita diretamente pelo próprio ambiente

escolhido (que varia de um para o outro) ou, então, por linha de comando no prompt e

também pelo utilitário de criação de AVD existente no arquivo SDK Setup.exe (LECHETA,

2010).

Na Figura 11 representa-se dois AVDs genéricos, criados a partir do executável SDK

Setup.exe. Pode-se ver que cada um deles é direcionado a uma versão (ou plataforma)

específica do Android. Por exemplo, a configuração chamada de “Emulador” é voltada à

plataforma 1.5 do sistema, enquanto que a “2.1”, como pode se supor, é direcionada à versão

2.1. Além destas, pode-se criar quantos outros AVDs forem necessários, bastando-se escolher

a opção New e selecionar as configurações do dispositivo desejadas.

38

Figura 11 – Alguns AVDs criados

Como dito, este trabalho será realizado a partir do ambiente Eclipse. Ele pode ser

obtido a partir do endereço virtual http://www.eclipse.org/downloads/. Existem diversas

versões dele, voltadas a diversos fins, como desenvolvimento Web, linguagem C/C++, dentre

outras. Neste caso, foi escolhida a Eclipse IDE for Java and Report Developers, por ser a

opção direcionada à linguagem de programação Java mais completa.

Terminada a transferência do arquivo, é necessária a descompactação dele. Em

seguida, abrindo-se a pasta gerada, e executando-se o aplicativo eclipse.exe já é possível

realizar as implementações em Java. Porém, para o desenvolvimento para a Plataforma

Android ainda é necessária a instalação do plugin ADT, como já citado anteriormente.

Caso todos os passos sejam realizados corretamente, pode-se criar um novo projeto

Android, como pode ser observado na Figura 12, a partir do menu File, opção New e se

escolhendo Project.

39

Figura 12 – Criação de um novo Projeto Android


Com o conhecimento adquirido sobre a estruturação da programação empregada para

o desenvolvimento de uma aplicação Android, falta apenas discorrer sobre como ocorre a

previsão do tempo e como é o funcionamento do GPS, que serão mostrados no Capítulo 4.

40

4. CONCEITOS DE PREVISÃO DO TEMPO E GPS


Este capítulo tem como objetivo apresentar uma fundamentação básica de como é

realizada a previsão do tempo, a partir da coleta de diversos dados, que depois serão

analisados e divulgados aos meios de comunicação para informar a comunidade em geral. Em

seguida, finalizando este capítulo, será mostrado como ocorre o processo de localização pelo

Sistema de Posicionamento Global.

4.2. PREVISÃO DO TEMPO

A previsão do tempo, que, para alguns pode parecer algo banal, é uma utilidade de

grande importância, visto que diversas áreas, como, por exemplo, a agricultura, precisam

dessa informação para determinar o melhor momento para se plantar ou colher certo tipo de

cultura. Ressalta que essa é uma função, mas também para saber como estará o tempo durante

o decorrer dos dias.

Ela é determinada segundo as condições climáticas e as variáveis meteorológicas do

local a que se destina o seu conhecimento. Por variáveis meteorológicas, podem-se entender

os seguintes fatores: a temperatura, a pressão atmosférica, a direção e a intensidade dos

ventos, a umidade do ar, a chuva, entre outras (DUARTE, 2010).

Inicialmente são coletados vários dados, através de estações meteorológicas

espalhadas por diversos locais. Estes dados correspondem às chamadas variáveis, e são

analisados por estas estações para a obtenção de um diagnóstico acerca da condição

meteorológica em um momento específico. Com este diagnóstico, é possível ter uma previsão

mais precisa (DUARTE, 2010).

O conjunto de dados capturados é armazenado em uma “carta de tempo”, que consiste

em diversos mapas que representam os sistemas meteorológicos que atuam na atmosfera. As

variáveis, entretanto, podem também ser utilizadas em equações matemáticas e físicas, que

serão processadas em computadores com grande desempenho computacional, que simularão

comportamentos atmosféricos futuros, ou seja, gerarão a previsão (DUARTE, 2010; CPTEC,

2011).

41

Apesar dos resultados apresentados pelo computador, estas saídas, que consistem em

vários gráficos, devem ser interpretadas por um profissional chamado de meteorologista. É ele

quem dirá como será o tempo, através de boletins que serão repassados a clientes e usuários

dos sistemas meteorológicos.

Porém, este profissional deve atuar em equipe, visto que podem ocorrer imprecisões

no momento das simulações computacionais dos processos físicos que ocorrem na atmosfera.

Estas imprecisões podem gerar erros na hora da divulgação da previsão. Desta forma, uma

equipe experiente, com grandes conhecimentos de geografia, clima e vegetação do local, é de

grande necessidade (DUARTE, 2010; SOARES, 2010; CPTEC, 2011).

Por apresentar uma maior margem de segurança e maior efetividade, é aconselhável

fazer a previsão para, no máximo, os próximos cincos dias. Isto ocorre devido às mudanças de

tempo que podem ocorrer ao longo dos dias. Seguindo esta lógica, uma previsão para o dia

imediatamente seguinte apresenta um valor em torno de 95% de chances de acerto. Com o

passar dos dias, esta porcentagem pode decair e gerar previsões erradas ou imprecisas

(SOARES, 2010).

No Brasil, os institutos que realizam previsão do tempo são: o CPTEC / INPE (Centro

de Previsão de Tempo e Estudos Climáticos / Instituto Nacional de Pesquisas Espaciais) e o

INMET (Instituto Nacional de Meteorologia).

4.3. SISTEMA DE POSICIONAMENTO GLOBAL

O GPS (Global Positioning System), conhecido, em português, como Sistema de

Posicionamento Global, mas que também pode ser chamado de NAVSTAR-GPS (Navigation

System Using Time and Ranging - Global Positioning System) consiste em um sistema de

rádio navegação por meio de satélites. Para isto, existe um conjunto de vários satélites

orbitando a Terra, e estes enviam, de forma contínua, diversas informações, por ondas

eletromagnéticas, a receptores compatíveis com esta tecnologia na superfície do planeta

(SILVEIRA, 2004; LIMA, 2006; INNOCENTE, 2007).

O GPS foi desenvolvido pelo Departamento de Defesa dos Estados Unidos da

América (DoD – Department of Defense), no início da década de 1960, com o objetivo de ser

o melhor sistema de navegação para o uso militar (CAMARGO; REDIVO; FLORENTINO,

2003; SILVEIRA, 2004).

42

Para uso civil foi liberado a partir de 1995 (LIMA, 2006). Ele pode ser utilizado em

áreas como: navegação, posicionamento topográfico e geodésico, agricultura, entre outras

(CAMARGO; REDIVO; FLORENTINO, 2003).

Conforme Innocente (2007), o sistema GPS pode ser dividido em três segmentos:

Espacial, de Controle e do Usuário.

O Segmento Espacial é formado pelos satélites, que conseguem girar em torno da

Terra a cada 12 horas, ou seja, duas vezes ao dia. Para conseguir uma precisão maior, ao

menos quatro satélites podem ser observados ao mesmo tempo, independentemente de qual

seja a localização terrestre. Eles são identificados de acordo com o número sequencial do seu

lançamento, na sigla de SVN (Space Vehicle Number), seguido do número correspondente

(LIMA, 2006; SILVEIRA, 2004; INNOCENTE, 2007).

Cada um destes satélites é formado por um conjunto de dois relógios de césio e dois

relógios de rubídio, para manter uma escala de tempo precisa, além de um rádio (que

transmite sinais em duas frequências de micro-ondas distintas, chamadas de Banda L, sendo

elas: L1 e L2).

A L1 utiliza a frequência de 1.575,42 MHz (e transporta dois tipos de códigos,

também chamados de códigos pseudo-aleatórios: C/A – Coarse / Aquisition, ou fácil

aquisição, que é de uso civil; e P – Precision, de precisão); enquanto que L2 usa a de 1.227,60

MHz, tendo como código P, e direcionado a uso militar norte-americano ou a dispositivos

autorizados. Por possuir este código, é considerado mais preciso. A L1 apresenta um

comprimento de onda de 19,05 cm, e L2, 24,45 cm (LIMA, 2006; SILVEIRA, 2004;

INNOCENTE, 2007).

Cada um dos satélites envia as seguintes informações, através das faixas L1 e L2:

posição, horário, como se calcula a distância entre o satélite e o aparelho receptor, correções a

serem feitas devido às influências atmosféricas e o almanaque (que demonstra o estado ou

“saúde” de cada um dos satélites e dados genéricos sobre a localização) (LIMA, 2006;

SILVEIRA, 2004).

Os dados gerados são controlados por estações terrestres, espalhadas por diversos

países, no chamado Segmento de Controle, que são utilizadas para o seu monitoramento e

controle. Assim, quando problemas de ordem atmosférica ou gravitacional (efemérides) são

detectados, são geradas as devidas correções no trajeto e na manutenção dos satélites (LIMA,

2006; SILVEIRA, 2004; INNOCENTE, 2007).

43

O último segmento existente é o Segmento do Usuário, que nada é mais do que o

conjunto de pessoas, civis ou militares, que operam dispositivos que possuem a capacidade de

receber as informações advindas dos satélites, e são utilizados em diversas finalidades

(LIMA, 2006; SILVEIRA, 2004; INNOCENTE, 2007).

O GPS funciona segundo o princípio da trilateração, em que os satélites são utilizados

como pontos de referência. Nele, as coordenadas são obtidas através da distância de cada um

dos satélites. Sabendo-se a distância de, pelo menos, três satélites, podem ser calculadas as

coordenadas. Estas distâncias são calculadas a partir do tempo levado pelas informações

transmitidas pelo satélite até atingirem o aparelho receptor, através dos algoritmos gerados no

momento da criação dos códigos (LIMA, 2006; SILVEIRA, 2004).

Seriam necessários apenas três satélites para se determinar as coordenadas, mas,

devido à falta de sincronização dos relógios dos satélites e do receptor, é necessário pelo

menos mais um satélite, que terá a função de realizar a sincronização entre estes, permitindo

assim a obtenção de informações como: a latitude, a longitude e a altitude do local (LIMA,

2006).

A partir dos dados presentes no almanaque do satélite, podem ser determinadas: a

distância e a posição deste em relação ao local da medição (LIMA, 2006). Apesar de detectar

a localidade aproximada, o GPS não é 100% preciso, visto que as informações a serem

enviadas do satélite ao receptor sofrem alterações de velocidade devido às diversas camadas

atmosféricas terrestres (prejudicando o cálculo da distância real), ou então a erros de

sincronização de relógios e alguns metros de diferença na posição dos satélites em órbita,

entre outras interferências (LIMA, 2006; SILVEIRA, 2004).

Um erro existente para a obtenção dos sinais do GPS, criado de forma proposital, foi o

AS (Selective Availability), que utilizava a manipulação dos dados das efemérides e dos

relógios dos satélites obtidos para gerar uma imprecisão no posicionamento, devido a

questões de segurança ou de sigilo. A partir de maio de 2000 ele foi desabilitado pelo DoD,

tornando a acurácia (exatidão ou proximidade do valor medido em relação ao valor real) no

posicionamento maior (SILVEIRA, 2004).


Este capítulo apresentou os principais aspectos teóricos a respeito da previsão do

tempo e do Sistema de Posicionamento Global (GPS). Estes conceitos serão fundamentais

para o desenvolvimento da aplicação para o dispositivo móvel. Finalizados estes conceitos,

44

serão mostrados os Métodos e os Materiais necessários para a realização deste trabalho, no

Capítulo 5.

45

5. MATERIAIS E MÉTODOS

5.1. MATERIAIS UTILIZADOS

O trabalho em questão será implementado utilizando a Linguagem de Programação

Java, um tipo de linguagem orientada a objetos, que pode ser considerada flexível, visto que,

pode ser utilizada para a criação de aplicações voltadas aos computadores comuns (Desktops),

aplicações ou sistemas baseados em Web, ou então, para dispositivos móveis (mobile), que é o

foco deste projeto. Além disto, ela é a linguagem de programação base para o

desenvolvimento de aplicativos ou jogos para o SO Android.

O programa utilizado para o desenvolvimento foi o Eclipse, um ambiente de

desenvolvimento gratuito, disponibilizado no endereço eletrônico: Eclipse (2011). A opção

utilizada foi a Eclipse IDE for Java and Report Developers, versão Helios Service Release 2,

considerada a mais completa em relação à programação Java.

Ele foi instalado em um notebook criado pela empresa Hewlett Packard (HP), modelo

Pavilion DV2765BR, que executa o SO Windows 7 Professional, um sistema de 32 bits,

disponibilizado pela empresa Microsoft. Acrescentando, para permitir o uso direcionado ao

Android, foi instalado o plugin ADT versão 14.0.0 (mais recente no momento de

desenvolvimento) junto ao Eclipse, além da instalação prévia do Android SDK (com todas as

atualizações das plataformas disponíveis).

Para os testes físicos foi utilizado o smartphone Quench, fabricado pela empresa

Motorola. Ele utiliza a versão 2.3.4 (Gingerbread) do Android, uma versão customizada não

oficial, visto que, a única versão suportada e disponibilizada para este modelo pela fabricante

é a 1.5 (Cupcake), que já está defasada e que não proveria todos os recursos necessários em

termos de funcionalidades ou de desempenho. Vale salientar, também, que ele possui os

recursos de GPS e de Internet, que são necessários para a execução da aplicação.

5.2. DESENVOLVIMENTO

5.2.1. Modelagem e Diagrama de Classes

O projeto foi nomeado como TempoGps, sendo que, foi construído sob a plataforma

2.2 do Android, que possui acesso às APIs da empresa Google, como o serviço Google Maps

aplicativo para previsÃo do tempo em plataforma...

Documents