Upload
others
View
3
Download
1
Embed Size (px)
Citation preview
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
Instituição: Universidade de Ribeirão Preto – UNAERP
Prof. Msc. Luciano A. L. Saraiva
Instituição: Universidade de Ribeirão Preto – UNAERP
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
3.1. CONSIDERAÇÕES INICIAIS
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
3.9. CONSIDERAÇÕES FINAIS
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
4.1. CONSIDERAÇÕES INICIAIS
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).
4.4. CONSIDERAÇÕES FINAIS
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