COMPUTAÇÃO PARA

DISPOSITIVOS MÓVEIS
CAPÍTULO 1 – VAMOS CRIAR UM
APLICATIVO MÓVEL?
Evandro de Souza Lima Rocha

INICIAR

Introdução
Os dispositivos móveis estão presentes na vida pessoal e profissional das pessoas,
mas você consegue mensurar isso? Segundo uma pesquisa do IBGE (2016), o uso de
dispositivos móveis, para navegar na internet, já é maior que o de computador
pessoal (PC). Em cerca de 97% dos domicílios com acesso à internet, o smartphone
(dispositivo móvel mais popular) é utilizado. E cerca de 92,4% dos habitantes que
acessam a internet no Brasil (116 milhões de habitantes), utilizaram aplicativos
móveis.
A grande procura por aplicações móveis ocorre devido à crescente necessidade que
as pessoas têm, de coleta e acesso às informações de forma rápida, correta,
intuitiva e segura, a qualquer momento e em qualquer localização, o que torna cada
vez mais importante a criação de aplicativos. É por isso que o desenvolvimento de
aplicativos móveis é uma promissora habilidade para despontar no mercado de
trabalho.
Considerando a importância dessas aplicações na vida das pessoas, como começo
a desenvolver aplicativos móveis?
Neste capítulo, vamos compreender o universo da computação móvel e começar a
desenvolver aplicativos. Para isso, vamos identificar e analisar os principais
dispositivos, plataformas de so ware, ferramentas, padrões, técnicas e métodos
voltados para a computação móvel, presentes no mercado. Assim, este
conhecimento é utilizado para a construção e entendimento de nossa primeira
aplicação.
Vamos entender como funciona o desenvolvimento de aplicações móveis e criar um
aplicativo? Bons estudos!

1.1 Introdução ao desenvolvimento de

aplicativos
Antes de começar a desenvolver aplicações, é importante entendermos o universo
da computação e dos dispositivos móveis. Este tópico visa responder às seguintes
perguntas: que características possuem os dispositivos móveis? Quais são as
principais plataformas de so ware utilizadas neste meio e suas características?
Quais padrões são utilizados neste ecossistema de aplicações? Acompanhe!

1.1.1 Dispositivos móveis

Desde o final dos anos 1990, a popularização e modernização das tecnologias, para
comunicação em redes sem fio, proporcionaram maior conectividade aos
dispositivos e possibilitaram o acesso a informações remotas, onde quer que se
esteja, favorecendo a computação móvel.
A computação móvel é um paradigma computacional que possibilita, às pessoas, o
acesso a serviços em qualquer localização, mesmo em movimento, ou seja, a
função essencial da computação móvel é permitir às pessoas o acesso à informação
em qualquer lugar e a qualquer momento.
Nessa linha, o dispositivo móvel é qualquer equipamento computacional que
possua mobilidade, para se transportar, possibilitando a seus usuários, o acesso a
serviços computacionais independentes de localização a qualquer momento.
Segundo Lee (et al., 2005), as principais características dos dispositivos móveis são:
portabilidade: esta característica está ligada diretamente ao tamanho
e peso do dispositivo, quanto mais leve e menor um dispositivo for, mais
portável ele é, pois permite que seja facilmente deslocado; usabilidade:
capacidade de ser utilizado pelas pessoas em diversos ambientes; funcionalidade:
oferece serviços ao usuário em aplicações móveis; conectividade: comunicação
com outros sistemas e dispositivos, transmitindo ou recebendo informações.

Analisando essas características, podemos perceber a enorme variedade de

dispositivos móveis presentes em nossa sociedade como, por exemplo: telefones
inteligentes (smartphones), tablets, computadores portáteis (notebooks),
videogames portáteis (PS Vita, Nintendo 3DS), câmeras e filmadoras digitais,
players de multimídia portáteis (Ipod, MP4, MP3), relógios inteligentes
(smartwatches), óculos de realidade virtual, etc.
A grande variedade de dispositivos móveis está associada a plataformas e
arquiteturas de desenvolvimento móvel distintas, sendo algumas, até mesmo,
fechadas para o grande público de desenvolvedores. Então, a fim de abordar o
desenvolvimento de aplicações de uma forma prática, para que consigamos
desenvolver nossas próprias aplicações, vamos nos concentrar no
desenvolvimento para smartphones, devido à enorme popularidade e versatilidade
destes equipamentos.
Antes do smartphone, veio o telefone celular, que tinham poucas funções, como
envio de voz (chamadas eletrônicas), e funções básicas de dados (acesso precário à
internet por wap e envio e recebimento de mensagens por SMS e MMS).
Considerados pela indústria como uma nova era na evolução dos telefones
celulares, os smartphones são telefones celulares com um sistema operacional ou
plataforma que permite a instalação, atualização e remoção de aplicativos móveis.
Quando surgiram os primeiros smartphones, não havia tantas funcionalidades e
facilidade de acesso às aplicações móveis quanto hoje. A primeira geração destes
aparelhos se iniciou no ano 2000, com o lançamento do Ericsson R380 que rodava a
plataforma Symbian OS. Nesta época, os celulares em geral, não tinham tela touch,
nem lojas de aplicativos centralizadas. As principais plataformas eram: Symbian,
Palm, Windows Mobile e Blackberry.
A partir de 2007, impulsionados pelo lançamento do iPhone, surgiu uma nova era
de smartphones com tela touch, como principal característica.
 VOCÊ O CONHECE?
Steven Paul Jobs (1955-2011) é considerado um gênio da área de tecnologia por ter inovado nos setores
de computação, animação no cinema, música, telefonia celular, tablets, varejo e publicação digital. Com
a criação do iPhone, revolucionou o mundo dos smartphones, mudando totalmente a forma como as
pessoas interagiam com os dispositivos móveis.

Quando as lojas centrais de aplicativos, como a App Store, se popularizaram em um

novo modelo, Fling (2009) definiu esta, como a era touch na evolução dos telefones
celulares.

1.1.2 Principais plataformas móveis

Muitas plataformas surgiram na era touch, como Android, iOS, Windows Phone,
Bada, web OS, Tizen, Firefox OS. Porém apenas os sistemas Android e iOS possuem
quantidade relevante no mercado de smartphones. Segundo pesquisa da
consultoria Gartner (2018), as plataformas Android e iOS dominam o mercado de
smartphones, estando presentes em 99,9% dos dispositivos vendidos.

Figura 1 - Principais plataformas móveis no mercado. Fonte: Gartner (2018).

#PraCegoVer: Apresenta uma tabela composta por 5 linhas e 3 colunas. Na primeira

linha temos os nomes das 3 colunas: primeira coluna: plataforma, segunda coluna:
unidades em 2017 e a terceira coluna: percentual do mercado em 2017. Na segunda
linha a plataforma Android possui 1.320.118,1 unidades e um percentual do
mercado de 85,9%. Na terceira linha a plataforma iOS possui 214.914,4 unidades e
um percentual do mercado de 14,0%. Na quarta linha a plataforma Outras
plataformas possui 1.493,0 unidades e um percentual do mercado de 0,1%. Na
quinta linha o total de todas as plataformas possui 1.536.535,5 unidades e um
percentual do mercado de 99,9%.
Mas, antes de desenvolver nossos aplicativos, devemos entender cada uma das
plataformas relevantes no mercado. Nesta seção, é apresentada uma visão geral
das plataformas Android e iOS.

Android
Segundo o Google (2018), a plataforma Android é uma pilha de so wares baseada no
sistema operacional Linux, de código-fonte aberto, e foco em atender dispositivos
móveis. A versão mais recente deste sistema, em 2019, é a 8.1 (Oreo). As versões
ativas do Android em dispositivos móveis podem ser vistas na figura abaixo.

Figura 2 - Fragmentação de versões da plataforma Android. Fonte: Google (2018).

#PraCegoVer: Apresenta uma tabela composta por 9 linhas e 4 colunas. A primeira

linha indica os nomes das colunas; Primeira coluna: Version, segunda coluna:
Codename, terceira coluna: API e quarta coluna: Distribuition; Segunda linha:
Version: 2.3.3 – 2.3.7, Codename: Gingerbread, API: 10, Distribuition: 0.3%. Terceira
linha: Version: 4.0.3 – 4.0.4, Codename: Ice Cream Sandwich, API: 15, Distribuition:
0.4%. Quarta linha: Version: 4.1.x, Codename: Jelly Bean, API: 16, Distribuition:
1.5%; Version: 4.2.x, Codename: Jelly Bean, API: 17, Distribuition: 2.2%; Version: 4.3,
Codename: Jelly Bean, API: 18, Distribuition: 0.6%. Quinta linha: Version: 4.4,
Codename: KitKat, API: 19, Distribuition: 10.3%. Sexta linha: Version: 5.0,
Codename: Lollipop, API: 21, Distribuition: 4.8%; Version: 5.1, Codename: Lollipop,
API: 22, Distribuition: 17.6%; Sétima linha: Version: 6.0, Codename: Marshmallow,
API: 23, Distribuition: 25.5%. Oitava linha: Version: 7.0, Codename: Nougat, API: 24,
Distribuition: 22.9%; Version: 7.1, Codename: Nougat, API: 25, Distribuition: 8.2%.
Nona linha Version: 8.0, Codename: Oreo, API: 26, Distribuition: 4.9%;
Para acompanhar o percentual de mercado de cada versão da plataforma Android
rodando em dispositivos móveis, você pode acessar o link
<https://developer.Android.com/about/dashboards/?hl=pt-br
(https://developer.Android.com/about/dashboards/?hl=pt-br)>.

VOCÊ QUER VER?

Quer conhecer a história do Android e visualizar um breve histórico das versões das plataformas
Android? O vídeo A história do Android – Tecmundo (KLEINA, 2017), disponível no endereço
<https://www.youtube.com/watch?v=5K4pEk19nhs (https://www.youtube.com/watch?
v=5K4pEk19nhs)> apresenta esta plataforma da origem e da evolução das versões até chegar na Oreo.

O ambiente de desenvolvimento Android é baseado nas linguagens de

programação Java e Kotlin. Este ambiente não requer um sistema operacional
específico, podendo ser instalado nos sistemas Windows, MAC OS e Linux. O
Android Studio é a ferramenta oficial recomendada pelo Google para
desenvolvimento de aplicações Android.
Para a publicação na loja de aplicativos do Google, deve ser criada uma conta e
realizado um pagamento de uma taxa única de inscrição ao programa de
desenvolvedores Android. Antes de serem publicados, os aplicativos passam por
um processo de revisão para assegurar que não violam as políticas estabelecidas
pela loja.
iOS iOS é a abreviatura para Iphone Operation System, sendo desenvolvido pela
Apple. Esta plataforma é baseada no Sistema Operacional MAC OS X e foi projetada
para atender às necessidades exclusivas de aparelhos móveis desenvolvidos pela
Apple (iPhone, iPod, iPad).
O sistema operacional iOS é uma plataforma proprietária e sua versão mais recente,
em 2018, é o iOS11. A figura, abaixo, apresenta a fragmentação das versões ativas
da plataforma iOS.

Figura 3 - Fragmentação de
versões da plataforma iOS. Fonte: Owen (2018, [s./d.]).

#PraCegoVer: Apresenta um gráfico de pizza com 3 fatias, uma fatia é chamada de

iOS11 e representa 76%, a outra fatia é chamada de iOS10 e representa 19% e a
outra fatia é chamada de Earlier e representa 5%.

O desenvolvimento de aplicações para esta plataforma, requer um computador

com a plataforma macOS e o ambiente de desenvolvimento Xcode, que permite que
os desenvolvedores criem suas aplicações e as testem em emuladores baseados no
sistema iOS. O desenvolvimento é atrelado a duas linguagens de programação: o
Objective-C e o Swi .
 VOCÊ SABIA?
A linguagem de programação Swi foi lançada pela Apple para suceder o Objective-
C.S. Segundo o ranking “IEEE Spectrum ranking – IEEE” (DIAKOPOULOS; CASS,
2018), a linguagem Swi já é a décima mais popular do mundo. Saiba mais em:
<https://spectrum.ieee.org/static/interactive-the-top-programming-languages2017
(https://spectrum.ieee.org/static/interactive-the-top-programminglanguages-2017)>.

Para a utilização de recursos avançados do Xcode e a distribuição na App Store, loja

de aplicativos da Apple, é exigida uma licença no Apple Developer Program.
Além da licença citada, é necessário que os aplicativos submetidos à loja de
aplicativos, estejam de acordo com as diretrizes estabelecidas pela Apple, como as
orientações de interface gráfica e as orientações de revisão da App Store.
Comparação entre as plataformas móveis apresentadas
O quadro a seguir, resume as principais diferenças entre as plataformas Android e
iOS para desenvolvedores individuais de aplicativos móveis.
 Quadro 1 - Comparação entre as principais plataformas móveis. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta uma tabela composta por 8 linhas e 3 colunas. Primeira

linha temos os nomes das 3 colunas: primeira coluna: Características, segunda
coluna: Android e a terceira coluna: iOS. Segunda linha: Características: Diversidade
de dispositivos, Android: Alta. Inúmeros dispositivos de variados fabricantes
atingindo as várias camadas da sociedade. iOS: Baixa. Pouca variedade de
dispositivos. Apenas iPhone, iPad e iPod touch rodam esta plataforma. Terceira
linha: Características: Ambiente de desenvolvimento (SDK), Android: Aplicações
nativas podem ser desenvolvidas em computadores com os sistemas Windows,
Linux e macOS. iOS: Aplicações nativas devem ser desenvolvidas utilizando o
sistema macOS X. Quarta linha: Características: Licença de desenvolvedor, Android:
Uma taxa de única inscrição no valor de U$ 25,00. iOS:Taxa paga anualmente no
valor de U$ 99,00. Quinta linha: Caracaterísticas: Publicação de aplicações nas lojas
oficiais de aplicativos da plataforma, Android: Termos mais simples de aprovação,
favorecendo a uma aprovação rápida do aplicativo, iOS: Os termos da Apple para
aprovação de um aplicativo são rigorosos, normalmente leva um tempo bem mais
longo de aprovação que nas demais plataformas. Sexta linha: Características:
Linguagens oficiais de programação, Android: Java e Kotlin, iOS: Objective-C e Swi
. Sétima linha: Características: Fragmentação de versões presentes no mercado,
Android: Alta. Devido a cada fabricante de dispositivo disponibilizar atualização do
Android como queira, iOS: Baixa. Todos os dispositivos iPhone, a partir do iPhone
5S, permitem atualização para o iOS, que proporcionam uma concentração maior
de dispositivos nesta versão. Oitava linha: Características: Licença da plataforma,
Android: Código aberto, iOS: Sistema fechado e proprietário.
São vários fatores que diferenciam estas plataformas, o que dificulta a vida dos
desenvolvedores, quando desejam criar aplicações que rodem nestas duas
plataformas. Na próxima seção, entenderemos os métodos para trabalhar com
aplicações multiplataforma.

1.1.3 Abordagens de desenvolvimento de aplicativos móveis

Cada plataforma é associada a padrões, ferramentas de desenvolvimento e
linguagens de programação próprios, tornando custosa e trabalhosa, a criação de
aplicações para mais de uma plataforma. Porém, um componente é comum em
todas elas: a visualização de páginas web, que possibilita a execução de aplicações
web, independente de plataforma.
Assim, existem três abordagens para a construção de aplicativos: abordagem
nativa, abordagem web móvel e abordagem híbrida (mescla entre as abordagens
nativa e web móvel).

Abordagem de desenvolvimento de aplicações nativas

As aplicações móveis, ditas nativas, são construídas com o uso dos SDK’s,
disponibilizados pelas plataformas, nas quais a aplicação deve ser executada. A
grande desvantagem deste método de desenvolvimento é que existe baixa
reutilização de código entre plataformas, fazendo com que o volume de trabalho e
manutenção das aplicações aumente consideravelmente, na medida em que é
necessário suportar uma nova plataforma.
Existem frameworks no mercado que amenizam o retrabalho, ao desenvolver
aplicativos nativos para múltiplas plataformas. Os principais presentes no mercado
são o Xamarin e React Native. Eles proporcionam um ambiente único de
desenvolvimento para ambas as plataformas, utilizando uma única linguagem de
programação.
Os fatores que justificam o uso desta abordagem são (SANTOS, 2014):

a experiência do usuário é fator crítico do projeto, que justifica o

tempo e recursos despendidos em solução nativa para cada plataforma;
necessidade de fazer uso massivo dos recursos nativos de cada
plataforma suportada;
alta necessidade de otimização no uso de recursos de hardware, como
CPU, memória e processamento gráfico;
o projeto tem como alvo apenas uma plataforma móvel;
a aplicação deve ser instalada localmente e disponibilizada nas lojas de
aplicativos oficiais.

Abordagem de desenvolvimento de aplicações web móveis

As plataformas atuais têm, por padrão, um navegador web para acessar a internet.
A abordagem de desenvolvimento de aplicações web móveis foi criada com o
propósito de diminuir o tempo e custo no desenvolvimento de uma aplicação. Por
meio deste método, as aplicações são criadas, utilizando tecnologias web (HTML,
CSS, Javascript, entre outros) e não são instaladas nos dispositivos móveis, ou seja,
são hospedadas num servidor web. A única diferença deste tipo de aplicação para
um web site comum é o foco nos dispositivos móveis, fazendo tratamentos
específicos para as plataformas móveis e resoluções de tela. Os fatores que
justificam esta abordagem são (SANTOS, 2014)

a aplicação necessita operar em diferentes plataformas e existem

restrições críticas de tempo e orçamento;
a aplicação não tem requisitos para funcionar offline, ou seja, só deve
funcionar com acesso à internet;
 a performance e experiência do usuário não são itens críticos do projeto;
não existe necessidade de fazer uso dos recursos nativos de cada
plataforma;
não existe necessidade de disponibilizar aplicação nas lojas de aplicativos
oficiais.

Abordagem de desenvolvimento de aplicações híbridas

Com a combinação das abordagens de desenvolvimento nativo e web, surge a
abordagem de aplicações híbridas. Da mesma forma que as aplicações web móveis,
as aplicações híbridas fazem uso do motor web de cada plataforma.
A grande particularidade neste método de desenvolvimento é que os
desenvolvedores utilizam um framework que encapsula, em código padronizado
Javascript, as chamadas APIs nativas de cada plataforma disponibilizando um
único ambiente de desenvolvimento baseado em tecnologias web.
As aplicações híbridas são empacotadas e armazenadas localmente no dispositivo
depois de instaladas e podem ser distribuídas nas lojas oficiais de aplicativos das
plataformas móveis, assim como as aplicações nativas.
Os fatores que justificam esta abordagem são (SANTOS, 2014):

a performance e fluidez do aplicativo não são requisitos estritamente

necessários . Embora instalada no dispositivo, a aplicação faz uso do
motor web para renderização da interface de usuário que não é tão
rápido quanto o acesso dos componentes de IUs nativos; a equipe de
desenvolvimento detém conhecimento de tecnologias web; a
aplicação necessita usar recursos nativos, mas o ciclo de
desenvolvimento precisa ser curto;
não há necessidade de otimização no uso de recursos de hardware como
CPU, memória e processamento gráfico;
a aplicação deve ser instalada localmente e disponibilizada nas lojas de
aplicativos.
Comparação entre as abordagens
O quadro a seguir, apresenta um resumo de como relacionam fatores importantes
no desenvolvimento de aplicações multiplataforma, com cada abordagem de
desenvolvimento.

Quadro 2 - Comparação entre as abordagens de desenvolvimento.

#PraCegoVer: Apresenta uma tabela composta por 9 linhas e 4 colunas. Primeira
linha temos os nomes das 4 colunas: primeira coluna: Características, segunda
coluna: Aplicação nativa e a terceira coluna: Aplicação web e quarta coluna:
Aplicação híbrida. Segunda linha: Características: Custo de desenvolvimento de
manutenção, Aplicação nativa: Alto, Aplicação web: Baixo, Aplicação híbrida:
Baixo. Terceira linha: Características: Tempo de desenvolvimento e manutenção,
Aplicação nativa: Alto, Aplicação web: Baixo, Aplicação híbrida: Baixo. Quarta
linha: Características: Desempenho, Aplicação nativa: Alto, Aplicação web: Baixo,
Aplicação híbrida: Médio. Quinta linha: Características: Experiência do utilizador
da aplicação móvel, Aplicação nativa: Ótima, Aplicação web: Baixa, Aplicação
híbrida: Média. Sexta linha: Características: Reutilização de código em diferentes
plataformas, Aplicação nativa: Não, Aplicação web: Sim, Aplicação híbrida: Sim.
Sétima linha: Características: Acesso aos recursos do dispositivo, Aplicação nativa:
Total, Aplicação web: Baixo, Aplicação híbrida: Parcial. Oitava
linha: Características: Necessidade de conexão à Internet, Aplicação nativa:
Não, Aplicação web: Sim, Aplicação híbrida: Não. Nona linha: Características:
Canais de Distribuição, Aplicação nativa: Lojas de Aplicativos, Aplicação web: Web
site, Aplicação híbrida: Lojas de aplicativo.

Desta forma, a escolha do método de desenvolvimento para utilizar em aplicações

móveis, não é trivial. Cada abordagem possui vantagens e desvantagens, que vão
depender da natureza e requisitos de cada aplicativo.

1.2 Projeto de aplicativo

Como projetar um aplicativo? Ao desenvolver uma solução móvel, existem
diversos desafios e preocupações muito importantes no
paradigma da computação móvel, mas que são pouco
relevantes no paradigma de desenvolvimento para desktop ou
puramente web.
Neste tópico são apresentados aspectos mais gerais que devem ser levados em
conta, na concepção de uma nova aplicação. Dentre esses aspectos, é ressaltada a
preocupação de projetar interfaces de usuário condizentes com os padrões de
design de soluções móveis.
Por fim, são apresentadas técnicas para explorar um projeto de interface de
usuário, sem que seja necessária ainda, sua codificação, tornando o processo de
validar ideias e projetos, mais ágil e menos custoso.
1.2.1 Arquitetura de uma solução móvel
Ao iniciar um projeto de aplicativo para dispositivos móveis, devemos nos atentar a
diversas complicações decorrentes da grande variedade disponível e ritmo
acelerado de crescimento e evolução deste mercado (LEE et al., 2005):

diversidade de recursos físicos: os aplicativos móveis devem se

adequar aos diversos tamanhos de tela e resoluções dos dispositivos e
serem fluídos em uma enorme variedade de configurações de CPU e
memória;
tratar conexões de rede sem fio: os aplicativos móveis devem se
adaptar às diversas conexões com rede sem fio (Wi-fi, 2G, 3G, 4G,
Bluetooth, etc.), que costumam ser intermitentes, de baixa velocidade e
com alta latência;
dificuldade de entrada de dados: os aplicativos móveis devem
possuir interfaces de entrada de dados simplificadas e rápidas devido à
grande diversidade de contextos de uso e atenção limitada do usuário;
energia limitada: os aplicativos móveis devem oferecer uma
diversidade de recursos, consumindo o mínimo possível de energia do
dispositivo; manutenção e atualização dos aplicativos: os aplicativos
móveis demandam constante manutenção para se adequarem às rápidas
evoluções dos sistemas operacionais móveis que, normalmente, trazem
novos padrões de codificação e recursos a cada versão.

Quais são os elementos envolvidos num projeto de aplicativo? Lee et al. (2005)
apresenta múltiplos fatores que devem ser analisados num projeto de aplicativo,
representados na arquitetura de solução móvel apresentada na figura abaixo.
 Figura 4 - Arquitetura de solução móvel. Fonte: LEE et al. (2005, p. 7).

#PraCegoVer: Apresenta a arquitetura do negócio. Um boneco pintado todo de

preto representa o usuário, do lado direito tem se o IU de Cliente móvel – Appls de
cliente móvel representado com o desenho de 4 celulares (clientes móveis), em
seguida tem-se a transferência de dados em via dupla entre os clientes móveis com
os servidores back-end (Representados por 3 retângulos na vertical) e bancos de
dados (representado por um cilíndro). Abaixo de toda a figura tem-se 3 linhas: na
primeira linha tem-se a palavra usuário abaixo do boneco preto, depois a
infraestrutura móvel que engloba os clientes móveis e a transferência de dados e
por fim as aplicações existentes que engloba os servidores back-end e bancos de
dados; na segunda linha tem-se a segurança e na terceira linha o gerenciamento,
ambas englobam todo o processo desde o usuário, clientes móvies, transferência
de dados e servidores back-end até o bancos de dados.

Estes fatores definidos por Lee et al. (2005), têm as seguintes funções:

contexto do negócio: identificar as reais necessidades e objetivos dos

usuários – alvo da aplicação – se será uma aplicação para eles se
 comunicarem, como ferramenta de trabalho, para entretenimento, para
fins educacionais, etc.;
arquiteturas de aplicação móvel: analisar qual arquitetura de
aplicativo adotar, ou seja, tomar decisões, como definir a abordagem de
desenvolvimento (nativa, web, híbrida) e quais frameworks utilizar para
desenvolver o aplicativo;
infraestrutura móvel: definir quais dispositivos móveis (tablets,
telefones celulares, relógios inteligentes, etc.) e plataformas, a aplicação
deverá ser suportada; interface de usuário (IU de cliente móvel):
definir projeto de interface de usuário visando que a aplicação seja intuitiva;
transferência de dados: definir mecanismo de acesso a dados nos
servidores back-end e banco de dados;
segurança: atentar para a proteção dos dados para casos de perda e
roubo do dispositivo. É muito importante manter a privacidade,
buscando evitar vulnerabilidades e ameaças;
estudos de caso de aplicações móveis: realizar estudos de caso e
análises em aplicativos já existentes, identificando padrões e boas
práticas para serem utilizados em novas aplicações.

Esta arquitetura nos mostra uma visão geral da solução móvel completa, que
envolve mais que apenas o projeto do aplicativo móvel (apenas a solução cliente),
como segurança e conexão com servidores back-end, por exemplo. Porém, nesta
seção vamos focar apenas no projeto de interface de usuário de cliente móvel.

1.2.2 Projeto de interface de usuário

O projeto de interface do usuário é parte essencial do processo de projeto, para que
o so ware possa atingir todo o seu potencial. Este projeto deve combinar as
habilidades, experiências e expectativas dos usuários previstos, uma vez que
interfaces inadequadas poderão limitar, em vez de ajudar a atingir o objetivo para
o qual o sistema foi projetado (SOMMERVILLE, 2011).
Ao projetar aplicações móveis, é necessário entender que elas devem possuir
interações rápidas, curtas e focadas. devido aos seguintes fatores:

a atenção do usuário ser dividida com outras atividades; a interação

com a aplicação móvel constituir uma tarefa secundária, que não deve
 interferir na tarefa principal do usuário; o usuário está sujeito a
diversas interrupções durante a interação.

Assim, a interface projetada deve apresentar claramente a informação, de modo

que favoreça a compreensão do usuário, de como ele deve realizar a interação, para
propiciar melhor usabilidade. Fonseca (et al., 2010) define princípios que devem
existir na concepção de interfaces de usuário em aplicações para propiciar melhor
usabilidade.

proximidade: elementos relacionados entre si devem ser agrupados e

aproximados uns dos outros, para que sejam vistos como um conjunto
coeso e para apontar elementos que não possuam relação lógica, que
não devem ser misturados. Isso permite identificar elementos
relacionados de forma ágil;
alinhamento: nenhum elemento deve ser colocado arbitrariamente na
interface. Cada elemento deve ter uma conexão visual com outro. Assim
como o princípio da proximidade, este princípio visa coesão na interface
de usuário;
repetição: sempre que possível e relevante, elementos e representações
gráficas podem ser repetidos numa interface como espaçamentos,
tipografia, espessura, imagens e cores. Seguir este princípio, propicia
consistência na interface, visto que a repetição de elementos de forma
uniforme ao longo da interface, facilita o reconhecimento por parte do
usuário;
ordenação: o princípio da ordenação deve ser aplicado para dispor os
elementos numa ordem lógica que seja entendida pelo usuário,
evitando confusões e facilitando a informação contida na interface. A
lógica de ordenação é dependente da natureza dos elementos e
objetivo. Por exemplo, a ordem alfabética é a forma mais simples e,
normalmente, aplicada em listas de itens ou nomes.

Além destes princípios, os principais fabricantes de plataformas móveis

disponibilizam guias para auxiliar desenvolvedores na construção de interfaces de
usuário. As principais guias são: Android Style Guide para sistemas Android e o iOS
Human Interface Guidelines para sistemas iOS.

1.2.3 Protótipo de interface de usuário

São diagramas estáticos que representam o esqueleto do design de um projeto de
aplicativo, para discutir e comunicar o projeto de interface de usuário. Um modelo
de representa o de um aplicativo de forma bastante simplificada. Neste modelo não
há muita preocupação com critérios estéticos (cor, tamanho da fonte, etc.).
Normalmente, há grande predominância das cores preto e branco nestes desenhos,
como vemos na figura abaixo.

Figura 5 - Wireframe de um aplicativo. Fonte: FONTÃO et al. (2012).

#PraCegoVer: Apresenta o desenho de um celular com a interface do aplicativo

Rock in Rio, mostrando o menu de aplicação. Essa parte gerencia toda a App
consistindo na tela inicial para melhor usabilidade dos usuários. Conectado a essa
interface tem-se outros desenhos de celulares cada um representando um item do
menu principal: interface com as notícias e posts nas redes sociais sobre o evento;
interface onde o usuário pode compartilhar informações de um artista pelas redes
sociais; interface com a App informando uma lista dos artistas que virão no Rock in
Rio; interface onde os usuários podem ouvir músicas dos artistas do Rock in Rio;
interface onde são disponibilizadas as imagens sobre os artistas do evento e
interface onde o usuário pode ouvir músicas quais vídeos do seu artista favorito
estão disponíveis na web.

A representação do projeto de interface de usuário em wireframes deve conter a

representação de todas as partes importantes do projeto e poderão ser utilizados
como parte da documentação.

Mockup
Um mockup é um diagrama estático que representa fielmente o design de
aplicativo. Diferente do wireframe, um mockup é um modelo bem próximo do
design final do produto, ou até o próprio design visual do produto. Já neste modelo,
há uma preocupação bem maior com elementos estéticos, como cores, fontes e
contraste, que não acontece nos modelos de wireframe.
 Figura 6 - Mockup de um aplicativo. Fonte: FONTÃO et al. (2012).

#PraCegoVer: Apresenta o desenho de dois celulares, acima dos desenhos está

escrito Dispositivos touch e do lado esquerdo dos desenhos: Resolução de tela: 640
x 360 px (modo paisagem), Profundidade da cor: 24 bits, Plataforma: S60 5ª edição
e Browser: Web Runtime 1.1.

Os mockups (exemplo na figura acima) são muito utilizados com a função de vender
uma ideia de um produto antes de ele estar pronto para um público estratégico
(possíveis clientes, por exemplo).
Enfim, um projeto de um aplicativo cliente móvel pode ser construído seguindo as
seguintes diretrizes:

definir contexto do negócio: definir os requisitos, ou seja, levantar que o

aplicativo deve fazer;
 infraestrutura móvel: definir quais dispositivos e plataformas, o
aplicativo deve atender;
projeto de interface de usuário: definir interface de usuário, com
a técnica de prototipação; arquiteturas de aplicação móvel: definir
arquitetura de so ware do aplicativo. Sabendo dos requisitos e
plataformas, definir qual abordagem de desenvolvimento utilizar ou
quais frameworks utilizar.

1.3 Introdução ao desenvolvimento

Android
Como implementar uma aplicação móvel? Agora que podemos projetar nossos
aplicativos, é hora de botar a mão na massa. Pela plataforma Android, nossas
aplicações móveis atingirão mais de 80% do mercado de dispositivos móveis (vide
a tabela “Principais plataformas móveis no mercado”). Esta plataforma admite o uso
de duas linguagens oficiais de programação para aplicações nativas: Java e Kotlin.
Além destas duas linguagens, é possível escrever código, utilizando as linguagens C
e C++ em aplicações Android, utilizando o NDK (Android Native Development Kit),
caso necessite (GOOGLE, 2018), para:

conseguir mais desempenho de um dispositivo para aplicativos

de computação intensiva, como jogos ou simulações de física;
reutilizar bibliotecas C ou C++ ou as de outros desenvolvedores.

Neste tópico é apresentado como implementar e executar um aplicativo utilizando

a ferramenta Android Studio.
Para fins didáticos, vamos utilizar apenas a linguagem Java para os exemplos de
aplicativos apresentados por ser a linguagem mais difundida no ambiente Android.
O primeiro passo do processo de desenvolvimento é configurar o ambiente que
requer o kit de desenvolvimento Java (JDK), cuja versão seja superior a 1.6.
Para identificar a versão da máquina virtual Java instalada, acesse o terminal ou o
prompt de comando e digite o seguinte comando: java-version
Além disso, é necessária a instalação de um ambiente de desenvolvimento
integrado (IDE) na máquina de desenvolvimento. Aqui, abordamos a IDE Android
Studio 3.0, pois é a ferramenta oficial para desenvolvimento de aplicativos Android.

CASO
Vamos compreender, na prática, como desenvolver a partir do Android Studio.

Primeiro, faça o download do Android Studio, que pode ser realizado no endereço:
<https://developer.android.com/studio/install
(https://developer.android.com/studio/install)>. A instalação é simples e rápida,
mas caso tenha alguma dúvida, pode seguir o manual de instalação do Android na
página <https://developer.android.com/studio/install
(https://developer.android.com/studio/install)>.
Ao instalar o Android Studio, por padrão, já é instalado o kit de desenvolvimento (SDK)
mais atual e as ferramentas básicas (bibliotecas Android, emuladores, ferramentas de
debug), para a criação de uma aplicação móvel.

Agora, você está pronto para criar um projeto no Android Studio, utilizando as opções.
“File”/”New Project” (Arquivo/Novo projeto). Acompanhe o texto para saber o passo a
passo.

Na primeira tela da GUI de criação de projeto (figura abaixo), são preenchidas

informações básicas do projeto como nome, domínio e pasta do sistema, no qual
ficará armazenado. As opções de adicionar suporte às linguagens de programação
só devem ser marcadas, se houver necessidade de escrever partes da aplicação
móvel em C/C++ ou em Kotlin.
 Figura 7 - Primeiro passo na criação de um projeto Android. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela da GUI com o nome de Create Android Project e os

campos para preenchimento: Application name: Primeiro Aplicativo, Company
domain: br.com.dtcom, Project location:
/Users/dtcom/AndroidStudioProjects/PrimeiroAplicativo, Package name:
dtcom.com.br.primeiroaplicativo com o botão Edit na frente, opções não
selecionadas abaixo: Include C++ support e Include Kotlin suppor.t.

Como todos os códigos do material se focam na linguagem Java, todos os projetos

de exemplo apresentados podem ser criados com estas opções desmarcadas.
Na segunda tela (figura abaixo), deverão ser selecionadas as versões mínimas do
Android para cada categoria de dispositivo móvel. Por exemplo, se for selecionada
a API 15 (referente ao Android 4.0.3) para smartphones/ tablets, a aplicação só irá
executar em smartphones/ tablets com versão superior a 4.0.3. O Google recomenda
esta versão, pois atinge mais de 99% dos smartphones/ tablets ativos no momento
(vide figura “Fragmentação de versões da plataforma Android”).
 Figura 8 - Segundo passo na criação de um projeto Android. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: print da tela da próxima GUI com o nome de Target Android Devices,
abaixo: Select the form factors and minimum SDK, Some devices require assitional
SDKs. Low API levels target more devices, but offer fewer API features. Abaixo os
campos para preenchimento: Phone and Tablet: API 15: referente ao Android 4.0.3
(IceCreamSandwich), Wear: API 21: Android 5.0 (Lollipop), TV: API 21: Android 5.0
(Lollipop) e Android Things: API 24: Android 7.0 (Nougat).

A opção de criar o aplicativo como instant app deve estar desmarcada. O conceito
de instant app é compatível com versões superiores a 4.2 (API 17) e possibilita que
aplicativos nativos sejam executados em dispositivos móveis sem que estejam
instalados. Esta arquitetura de aplicativos é mais avançada e não será abordada,
por enquanto. Como o foco do nosso projeto são os smartphones, vamos marcar
apenas esta opção nesta etapa de criação do projeto.
Na terceira tela, é apresentada uma coleção de templates de Activity para selecionar
como tela inicial do aplicativo. Uma Activity ou atividade pode ser entendida como
uma tela da aplicação. Para cada tela é necessária a criação de, pelo menos, uma
Activity que permitirá aos utilizadores manipular, adicionar ou obter informação de
uma aplicação. Ou seja, neste passo de inicialização do projeto, estamos definindo
como será o layout da primeira tela do aplicativo, definida como Activity principal.
Neste exemplo (figura abaixo), vamos utilizar o template empty Activity, visto que
nosso propósito neste exemplo é de entender o funcionamento dos componentes
básicos do Android.

Figura 9 - Terceiro passo na criação de um projeto Android. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela da próxima GUI com o nome Add na Activity to Mobile,
abaixo temos as opções: Add No Activity, Basic Activity, Bottom Navigation Activity
e Empty Activity (opção selecionada).

Neste exemplo, utilizamos os nomes TelaPrincipalActivity e

Activity_tela_principal.xml para os respectivos nomes da Activity e do arquivo XML
de configuração de interface de usuário.
1.3.1 Entendendo a estrutura de um projeto Android
Depois dos primeiros passos de inicialização do projeto, é criado um projeto básico
contendo o padrão de três pastas principais, como mostra a figura abaixo.

Figura 10 - Estrutura de um projeto Android. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela do projeto básico do Pimeiro Aplicativo com as pastas:

manifests, java: dentro dessa pasta tem a opção dtcom.com.br.primeiroaplicativo
(test) e a pasta res.
Estas pastas têm as seguintes funções (GOOGLE, 2018):
 manifests: pasta contendo diretrizes principais da aplicação. Nesta pasta
devem conter arquivos de configurações com caráter global. O projeto é
criado com o arquivo AndroidManifest.xml, que apresenta informações
essenciais sobre o aplicativo ao sistema Android, necessárias para o
sistema antes que ele possa executar o código do aplicativo. Entre
outras coisas, o arquivo do manifest serve para: nomear o pacote Java
(identificador) para o aplicativo, descrever os componentes do
aplicativo, determinar os processos que se relacionam com o aplicativo,
declarar as permissões que o aplicativo deve ter para acessar partes
protegidas da API e interagir com outros aplicativos, declarar nível
mínimo de API que o aplicativo deve suportar, listar bibliotecas às quais
o aplicativo deve se vincular;
java: nesta pasta devem estar todos os arquivos de código fonte Java da
aplicação, separados por nome de pacote, inclusive o código de teste do
JUnit;
res: contém todos os recursos que não são código, como layouts XML,
strings de IU e imagens em bitmap, divididos em subdiretórios
correspondentes;
scripts Gradle: Nesta pasta deverá estar o arquivo build.gradle que
contém as diretrizes de compilação do projeto e demais scripts Gradle.

VOCÊ SABIA?
O Gradle é um sistema avançado de automatização de builds (compilação do código
fonte em um apk). O processo de compilação de um aplicativo Android envolve
muitas ferramentas e etapas que são integradas com o Gradle, tornando ágil e fácil
a geração de um apk. Maiores detalhes sobre esta ferramenta podem ser
encontradas no endereço:
<https://docs.gradle.org/current/userguide/userguide.html
(https://docs.gradle.org/current/userguide/userguide.html)>.
Desta forma, é estruturada uma aplicação padrão Android. Nas próximas seções
deste tópico, iremos focar nos arquivos de definição de interface de usuário que
ficam localizados na pasta res. As configurações globais realizadas no arquivo
AndroidManifest.xml e arquivos fontes java serão explicados mais adiante no tópico
1.4.

1.3.2 Construindo a interface de usuário

É na pasta /res/layout que, por padrão, ficam localizados os arquivos de definição
de interface de usuário de cada tela da aplicação. Em nosso projeto de exemplo, o
Android Studio criou o arquivo primeiro_aplicativo.xml. Ao acessar este arquivo na
IDE (dois cliques no arquivo) são apresentadas duas visões: design e Text (abas
localizadas no canto inferior esquerdo do Android Studio). Na visão Text, é
carregado um editor de texto de código fonte (figura abaixo) junto ao preview da
tela do aplicativo.
 Figura 11 - Ferramenta de construção de interface de usuário. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Ferramenta de construção de interface de usuário. No projeto de

exemplo, o Android Studio criou o arquivo primeiro_aplicativo.xml. Ao acessar este
arquivo na IDE (dois cliques no arquivo) são apresentadas duas visões: design e Text
(abas localizadas no canto inferior esquerdo do Android Studio). Na visão Text, é
carregado um editor de texto de código fonte junto ao preview da tela do aplicativo.

Já na visão design, são carregadas quatro ferramentas para montar o layout da tela
visualmente (GOOGLE, 2018):

pallete (paletas): contém uma lista de componentes de interface de

usuário, como botões, caixas de texto, layouts, containers, etc. Cada
componente pode ser facilmente arrastado para a área de preview,
 automaticamente o código fonte da tela será atualizado com o
componente adicionado; component tree (árvores de
componentes): exibe a hierarquia da interface de usuário construída;
preview (previsão do aplicativo): uma previsão de como será exibido
em um dispositivo, a interface de usuário que está sendo construída, é
visualizada em inúmeras resoluções de tela e pode-se alternar entre as
orientações portrait e landscape; properties (propriedades): exibe as
propriedades de um elemento da árvore de componentes que podem
ser alteradas.

Toda interface de usuário é definida pela combinação de componentes View e

Viewgroup.
Os componentes classificados como View são componentes básicos para criação de
interface de usuário. Os componentes View são listados na ferramenta de paleta na
visão design do Android Studio, mencionada anteriormente. A plataforma Android
possui como base componentes de View especiais, que são classificados como
widgets.
Os widgets mais comuns em interface de usuário são: TextView (componente para
exibir texto na tela), ImageView (componente para exibir imagem na tela), Button
(componente para exibir um botão na tela), EditText (componente para exibir uma
de caixa texto).
Além destes widgets, a plataforma Android ainda conta três componentes para
organizar a disposição de dados na interface de usuário (GOOGLE, 2018):

ListView: organiza os dados passados em formato em uma lista vertical

com rolagem, ou seja, o listview recebe dados através de um array e
apresenta, na tela, os dados de cada elemento do array um embaixo do
outro;
GridView: organiza os dados passados em formato de tabela com
rolagem, ou seja, é possível configurar no componente como os dados
de cada elemento do array passado serão dispostos na tela. É possível
criar uma lista de elementos como no listview utilizando o GridView
desde que o desenvolvedor o configure com uma coluna.
 RecyclerView: é um novo widget surgido na API 21 do Android que vem
substituindo tanto o GridView e ListView nas interfaces de usuário, visto
que tem a flexibilidade de apresentar dados tanto em lista quanto em
formato tabela, possui melhor performance e menor consumo de
memória que os dois componentes mais antigos.

Os elementos View precisam ser agrupados para serem exibidos na tela. A

plataforma Android fornece componentes ViewGroup para esta finalidade. Existem
inúmeros componentes ViewGroup (também listados na ferramenta de paleta na
visão design do Android studio), os principais componentes ViewGroup são
(GOOGLE, 2018):

Linearlayout: alinha componentes View ou ViewGroup em formato de

linha ou de coluna na tela;
Gridlayout: alinha componentes View ou ViewGroup em formato de tabela
na tela;
Relativelayout: mais complexo e mais poderoso que os ViewGroup
mencionados anteriormente. Este componente alinha componentes
View ou ViewGroup de acordo com referência a outros componentes
posicionados na tela;
Constraintlayout: é considerado uma evolução ao componente
Relativelayout. Pois permite alinhar componentes View pelo
posicionamento relativo, mas é mais flexível e fácil de utilizar que o
Relativelayout.

Sendo assim, a interface de usuário de um aplicativo na plataforma Android é

formada por uma hierarquia de componentes View e ViewGroup. Na figura a seguir,
é apresentado um exemplo de organização destes dois componentes.
 Figura 12 - Exemplo de Hierarquia de uma tela. Fonte: Google (2018).

#PraCegoVer: Gráfico com retângulos hierárquicos, no qual os retângulos

distribuídos verticalmente e ligados por linhas representam a comunicação e a
hierarquia dos itens. O ViewGroup ocupa o primeiro nível do organograma (primeira
hierarquia). No segundo nível (segunda hierarquia) partindo do retângulo do
ViewGroup, sai uma linha que será dividida para se ligar a um ViewGroup e a dois
View. No terceiro nível do ViewGroup sai uma linha que será dividida para se ligar a
3 view.

Enfim, existem duas maneiras de construir a interface de usuário de uma aplicação

e elas se complementam. Ao editar o modelo de interface na aba design, o código é
alterado imediatamente e, ao atualizar o código XML na aba Text, o modelo é
atualizado, de acordo com o que foi alterado.

1.3.3 Gerando e executando a aplicação

Vamos verificar se está tudo correto com o projeto, compilando um apk e instalando
em um dispositivo. Acesse a opção Run (Executar) na barra de tarefas do Android
Studio, selecionando o primeiro item (run app) que compila e executa o aplicativo
desenvolvido.
Após o processo de compilação ocorrer com sucesso, o Android Studio solicitará a
escolha de um destino de implantação: um dispositivo móvel real ou um emulador
de dispositivo Android, conhecido como AVD (Android Virtual Device). Para a
execução da aplicação em um dispositivo real é necessário:

configurar o dispositivo para permitir depuração USB. O passo a

passo de como realizar esta configuração está disponível em
<https://developer.Android.com/studio/run/device?hl=pt-br
(https://developer.Android.com/studio/run/device?hl=pt-br)>
instalar driver USB de acordo com a fabricante do dispositivo. Todos
os passos para identificação e instalação do driver adequado é acessível na
página <https://developer.Android.com/studio/run/oem-usb?hl=pt-br
(https://developer.android.com/studio/run/oem-usb?hl=pt-br)>.

VOCÊ SABIA?
Uma das mais importantes ferramentas disponíveis no SDK é o Android Virtual
Device Manager (AVD Manager). Usando o AVD Manager, é possível criar dispositivos
móveis emulados (AVD) com as mais variadas características (CPU, memória,
resolução de tela, armazenamento, etc.) no ambiente de desenvolvimento. A
documentação explicando como funciona o AVD Manager pode ser acessada em
<https://developer.Android.com/studio/run/managing-avds?hl=pt-BR
(https://developer.Android.com/studio/run/managing-avds?hl=pt-BR)>.

O AVD Manager é uma ótima ferramenta para incrementar a qualidade da aplicação.

Pela ferramenta é possível emular o funcionamento da aplicação nos mais variados
tamanhos de tela e versões Android.

1.3.4 Monitorando a aplicação em tempo de execução

Pelo Android Studio é simples monitorar a execução das aplicações Android
durante o processo de desenvolvimento, pela ferramenta Logcat. Esta ferramenta,
por padrão, é localizada numa das abas do lado inferior esquerdo do Android
Studio.
Na barra de ferramentas da aba logcat (figura abaixo), é possível configurar qual
dispositivo a ser monitorado (no caso de estar rodando a aplicação em mais de um
dispositivo), quais tipos de mensagem devem ser exibidas (todas, info, error, etc.),
quais aplicações devem ser monitoradas.

Figura 13 - Monitorando a aplicação PrimeiroAplicativo. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela de execução do Logcat, campos para serem

selecionados: primeiro campo: Xiaomi MI 6 Android 8.0.0, segundo campo:
dtcom.com.br.primeiroaplicativo, terceiro campo: Verbose, quarto campo:
primeiroaplicativo, quarto campo: Regex, quinto campo: Show only select
application.

O logcat é uma ferramenta essencial no desenvolvimento de qualquer aplicação

Android nativa, visto que permite depurar a aplicação, permitindo que o
desenvolvedor encontre as causas de defeitos (bugs), por meio das mensagens
emitidas pela aplicação no console do logcat.
Finalmente, aprendemos a executar e monitorar nossa primeira aplicação Android!
Por enquanto, ainda não escrevemos nenhuma linha de código Java. Entraremos
em mais detalhes no próximo tópico.

1.4 Fundamentos do desenvolvimento

Android
Neste tópico, são apresentados os conceitos básicos necessários para a construção
de um aplicativo Android. Para auxiliar neste entendimento, é utilizado o caso do
projeto PrimeiroAplicativo, criado de forma automatizada no tópico anterior.
Entenderemos os componentes básicos envolvidos em uma aplicação Android e
como eles se relacionam por meio da análise de código fonte e arquivo de
configuração gerados.

1.4.1 Intents
O Android possui um mecanismo de troca de mensagens conhecido como Intents.
As Intents são mensagens assíncronas que são usadas para comunicação entre os
diversos processos rodando no sistema operacional. Ou seja, os diversos
aplicativos executados na plataforma Android, podem se comunicar e trocar dados
com o sistema operacional por meio das Intents.

VOCÊ QUER LER?

Para obter mais informações sobre este mecanismo de troca de mensagens na plataforma Android
denominada Intents, são apresentadas na página “Intents e Filtros de Intents” (GOOGLE, 2018).

Voltando ao projeto PrimeiroAplicativo de exemplo criado pelo Android Studio na

seção passada, a classe TelaPrincipalActivity é definida como Activity principal do
código destacado na figura anterior (Monitorando a aplicação PrimeiroAplicativo),
do AndroidManifest.xml:

Figura 14 - Definição da Activity principal. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela com as linhas de comando:

<activity android:name=“.TelaPrincipalActivity”>
<intent-filter>
<action android:name=“android.intent.action.MAIN” />
<category android:name=“ android.intent.category.LAUNCHER” />
<intent-filter>
<activity>

No trecho de código da figura acima, estamos registrando uma Activity com o nome
TelaPrincipalActvity. Perceba que temos um elemento neste arquivo chamado de
Intent-filter.

Pelos parâmetros Android.Intent.category.LAUNCHER e a ação

Android.Intent.action. MAIN, definimos qual Activity será a primeira a ser
carregada ao iniciar o aplicativo.
Logo, no trecho XML destacado, a função da tag Intent-filter é definir a
TelaPrincipalActivity como Activity principal e primeira a ser carregada.

1.4.2 Ciclo de Vida das atividades (instâncias de classes Activity)

Diferentemente de outros paradigmas de programação em que os aplicativos são
iniciados com um método “main”, os aplicativos Android iniciam o código em uma
instância de uma classe Activity (definida como Activity principal no arquivo
AndroidManifest.xml) chamando método “onCreate” que indica que a aplicação foi
inicializada, ou seja, o primeiro método a ser executado de uma aplicação Android
é o método onCreate() da Activity principal.
Uma Activity pode adquirir os seguintes estados (DEITEL; DEITEL; WALD, 2016):

ativa: uma atividade ativa é visível na tela e “tem o foco”, isto é, está no
primeiro plano. O usuário pode interagir com a atividade que está no
primeiro plano;
pausada: uma atividade pausada é visível na tela, mas não tem o
foco – como quando uma caixa de diálogo de alerta é exibida. Não é
possível interagir com a atividade pausada até que ela se torne ativa;
parada: uma atividade parada não é visível na tela, ou seja, ela está
em segundo plano.

Para cada mudança de estado da tela, existe um método da classe Activity que trata
esta mudança. Os métodos são (GOOGLE,2018):
 onCreate: como já foi mencionado, é acionado apenas quando a
Activity é criada; onStart: este método é executado logo após uma
Activity ter sido criada ou após ela ter sido reiniciada; onResume: o
método é executado acionado quando a Activity volta a ter foco;
onPause: o método é executado acionado quando a Activity perde o
foco, ou seja, a Activity será substituída por outra (pausada), ou existe um
componente de interface assumindo o foco (mensagem de diálogo);
onStop: o método é executado quando a Activity deixa de ser exibida
porque outra Activity assumiu o foco; onDestroy: o método é executado
sempre que a Activity esteja sendo destruída, ou seja, após a execução deste
método a plataforma limpará da memória a Activity.

O diagrama da figura abaixo ilustra como estão interligados estes estados.

Figura 15 - Ciclo de Vida das classes Activity. Fonte: GOOGLE (2018).

#PraCegoVer: O esquema mostra o ciclo de vida em forma de degraus, subindo até
atingir o topo e então começa a descer os degraus. Começa com um boneco verde
(símbolo do Android) que se conecta ao próximo passo (Created) através do
onCreate(), este se conecta com o Started (Visible) através do onStart(), que se
conecta com o Resumed (Visible) através do onResume(), aqui estamos no topo e
os degraus começam a descer, sendo o primeiro degrau Paused (partially visibe)
conectado pelo onPause() neste step pode-se voltar para o degrau anterior
Resumed (Visible) através do onResume(), ou descer mais um degrau Stopped
(hidden) atráves do onStop() e o último estágio do ciclo – terminando os degraus
temos o Destroyed, através do onDestroy().

Desta forma, a aplicação do projeto PrimeiroAplicativo, ao iniciar, deverá executar

o seguinte método definido na classe TelaPrincipalActivity destacado na figura
abaixo.

Figura 16 - Implementação da classe TelaPrincipalActivity. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela com as linhas de comando:

package dtcom.com.br.primeiroaplicativo; import ... public

class TelaPrincipalActivity extends AppCompatActivity {
@Override protected void onCreate (Bundle
savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_tela_principal);
}
}

O método onCreate é acionado pelo sistema Android que passa um argumento

Bundle contendo o estado salvo da atividade, ou seja, dados presentes na Activity.
A classe Bundle é uma classe utilitária para armazenar ou transportar dados entre
o sistema Android e as classes Activity. Utilizaremos bastante a classe Bundle em
nossas aplicações para transmitir dados entre instâncias Activity.

VOCÊ QUER LER?

A principal função deste argumento Bundle no método onCreate, é permitir que a Activity seja recriada
com o estado que ela tinha antes de ser destruída.

Utilizando o argumento savedInstanceState, é chamado o método onCreate da

classe pai que é obrigatório em todas classes Activity que sobrescrevem este
método.
A chamada de método setContentView apresentada é responsável por carregar a
Activity de acordo com interface de usuário definido no arquivo tela_principal.xml.
É importante atentar para a classe “R”. Cada arquivo na pasta res contém uma
referência na classe R, que é automaticamente gerada pelo Android Studio.
O arquivo "R.java" não deve ser modificado manualmente, mas é de suma
importância conhecê-lo. Pelas constantes, criadas automaticamente na classe R, é
que é feita a ligação entre os arquivos resources (layouts, drawables, etc.) com o
código Java.

1.4.3 Modelo de Permissões

Com a finalidade de propiciar privacidade aos usuários de aplicativos Android, uma
aplicação desta plataforma deve requisitar acesso explícito aos dados do usuário
(lista de contatos, SMS, e-mail, etc.), ou recursos do sistema operacional (acesso à
rede, câmera, etc.). As permissões do sistema são divididas em duas categorias
(GOOGLE, 2018):

permissões normais: não representam um risco direto à privacidade do

usuário. Um aplicativo que lista uma permissão normal em seu manifest,
o sistema a concede automaticamente;
 permissões perigosas: podem conceder ao aplicativo acesso aos dados
confidenciais do usuário. Se seu aplicativo lista uma permissão normal
em seu manifest, o sistema a concede automaticamente. Se você lista
uma permissão perigosa, o usuário precisa aprovar seu aplicativo
explicitamente.

O desenvolvedor deve requisitar permissões no AndroidManifest.xml utilizando o

elemento <uses-permission>. Por exemplo, no projeto PrimeiroAplicativo, caso o
aplicativo necessite de acesso ao cartão de memória do dispositivo, devemos
adicionar o elemento <uses-permission> antes do elemento <application>.
Podemos ver como fica o arquivo de manifest:

Figura 17 - Configurando requisição de permissão para leitura no cartão de memória. Fonte: elaborado
pelo autor, 2018.
#PraCegoVer: Linhas de comando com o elemento <uses-permission> antes do
elemento <application>

<manifest xmlns:android=”http://schemas.android.com/apk/res/android”
package=”dtcom.com.br.primeiroaplicativo”>
<uses-permission
android:name=”android.permission.READ_EXTERNAL_STORAGE”></uses
permission> <application
android:icon=”@mipmap/ic_launcher”
android:label=”PrimeiroAplicativo”
android:roundIcon=”@mipmap/ic_launcher_round”
android:supportsRtl=”true”
android:theme=”@style/AppTheme”>
<activity android:name=”. TelaPrincipalActivity”>
<intente-filter>
<action android:name=”android.intent.action.MAIN” />
<category android:name=”android.intent.category.LAUNCHER” />
</intente-filter>
</activity>
</application>
</manifest>

A partir da API 23 (Android Marshmallow), a plataforma Android solicita permissão

a um recurso em tempo de execução, ou seja, no momento que o usuário for utilizar
pela primeira vez um determinado recurso. Assim, para aplicações com versões
recentes do Android (versões posteriores a API 23), além de configurar a requisição
de permissão no arquivo AndroidManifest.xml (como mostrado na figura anterior).
Deve-se utilizar o método Java estático requestPermission da classe ActivityCompat,
sempre que for verificado que o aplicativo não possui permissão para um
determinado recurso.

VOCÊ QUER LER?

Mais detalhes sobre o modelo de permissões do Android e mais exemplos de requisições de permissão
ao sistema Android, podem ser encontrados na página “Permissões do sistema” (GOOGLE, 2018),
disponível em <https://developer.android.com/guide/topics/security/permissions
(https://developer.android.com/guide/topics/security/permissions)>.

Enfim, compreendemos os elementos fundamentais de uma aplicação Android.

Estes são elementos muito importantes e que estarão presentes na maioria das
suas futuras aplicações.
Síntese
Chegamos ao final do capítulo e já podemos criar e executar uma aplicação móvel.
Vimos que o universo de dispositivos móveis é vasto e existem inúmeras
possibilidades plataformas, ferramentas, técnicas, boas práticas e ferramentas
envolvidas na criação de aplicativos móveis. Este capítulo, então, apresentou
fundamentos práticos da programação para dispositivos móveis pela plataforma
Android, utilizando as ferramentas oficiais de desenvolvimento.
Neste capítulo, você teve a oportunidade de:

listar as principais características dos dispositivos móveis e quais são

os principais desafios ao desenvolver aplicações neste universo;
acompanhar o processo de evolução dos dispositivos móveis, com
foco nos smartphones; identificar as principais plataformas móveis,
presentes no mercado, e quais as suas principais características; refletir
sobre as abordagens de desenvolvimento utilizadas para a implementação
de aplicações móveis analisar os elementos de uma arquitetura de solução
móvel; projetar a interface de usuário, usando padrões e princípios
utilizados no mercado;
compreender como expor um projeto de aplicativo sem necessidade
de codificá-lo, pela técnica de prototipação; iniciar e executar uma
implementação de um aplicativo móvel Android; compreender a estrutura
de diretórios de aplicativos Android; entender a implementação de
interface de usuário no Android Studio; compreender conceitos básicos
do desenvolvimento de aplicativos, como ciclo de vida das telas da
aplicação baseadas em Activity, Intent (utilizada para troca de mensagens
entre processos) e requisição de permissões.
 Projeto
APP MOBILE

O fenômeno internet tornou-se comercial a partir de meados da década de 1980.

Porém, no início dos anos 1990, houve um crescimento no desenvolvimento das
tecnologias para comunicação móvel, como satélite, wireless etc. Com o passar dos
tempos, houve um popularização dessas tecnologias, essa popularização torna o
acesso às informações remotas mais fáceis ao usuário através de aplicações móveis.

Paralelamente, a queda dos preços dos dispositivos móveis

como tablet e smartphones , bem como a evolução desses dispositivos em termos de
processamento e capacidade de memória, propicia o acesso às informações
da internet a qualquer usuário. Nesse contexto de acesso de qualquer lugar e móvel,
têm-se os fundamentos da computação móvel ou mobile.

O Brasil, por exemplo, em um relatório digital em 2019, subiu em 0,7% na sua

população e com relação ao uso de dispositivos móveis, um aumento 10 milhões, um
crescimento de 7,2% em relação ao relatório do ano de 2018. Em relação às mídias
sociais, há mais de 140 milhões de usuários ativos. A penetração da internet atingiu
70%, acima da média global de 57%. Mais de 149 milhões, dos quase 212 milhões de
habitantes do país, são usuários de internet. Cerca de 85% dos usuários de internet
no Brasil navegam na web todos os dias. Aproximadamente, 61% usam serviços
bancários móveis e 89% fazem buscas por serviços na web. 6% de todos os
brasileiros são usuários de internet móvel (DATAREPORTAL, 2019).

Com esse crescimento de uso de dispositivos móveis, o usuário passa a ver o mundo
com os olhos de suas necessidades. Essas necessidades geram novas aplicações que
atendam o objetivo do usuário e cria novos conceitos como vender serviços e não
produto. Essa mudança de conceito determina uma mudança fundamental para os
desenvolvedores de aplicações, o conhecimento do negócio.

Antes, a visão para desenvolvimento de uma aplicação era praticamente uma visão
sistêmica, hoje, essa visão muda. Devido às necessidades do usuário, a visão
sistêmica passa para uma visão das necessidades do usuário. Esse usuário que é
desconhecido para a maioria das empresas e esse desconhecimento gera um grau
de desafios ou barreiras que o desenvolvedor tem de enfrentar.

Num ambiente escolar, diversas necessidades podem ser atendidas através de

serviços por meio de uma aplicação móvel tanto para a escola quanto para o
professor e o próprio aluno. Pense num desenvolvimento de uma aplicação móvel
que contemple as necessidades de uma escola de ensino médio com serviços
disponíveis para a administração da escola, o professor e aluno.

Vamos Praticar

Convido você a pensar, analisar e descrever quais são os desafios atuais e futuros
que um desenvolvedor de aplicações móveis do século 21 deve enfrentar no
desenvolvimento de uma aplicação móvel para um ambiente escolar. Compartilhe
no fórum da disciplina o seu ponto de vista num texto discorrido com,
aproximadamente, 15 linhas problematizando a importância do levantamento dos
desafios/barreiras para entendimento dos pontos positivos e negativos no
processo de criação da aplicação.
 COMPUTAÇÃO PARA
DISPOSITIVOS MÓVEIS
CAPÍTULO 2 - QUAIS RECURSOS E
APIS
DO SISTEMA ANDROID PODEMOS
UTILIZAR PARA TORNAR NOSSA
INTERFACE DE USUÁRIO DINÂMICA?
Fernando Skackauskas Dias

INICIAR

Introdução
A tecnologia dos dispositivos móveis tem avançado consideravelmente nos últimos
anos. Novos aparelhos com recursos inéditos, interfaces cada vez mais amigáveis e
disponibilidade de novos serviços, dentre outras inovações, estão dominando o
mercado. Diante deste panorama, os cientistas da computação se encontram
diante de grandes desafios.
Nesse contexto, o sistema operacional Android foi desenvolvido com o objetivo de
se tornar um sistema aberto, englobando diversas novas funcionalidades. Por ser
um sistema aberto, significa que diferentes desenvolvedores podem atuar
diretamente no sistema operacional. Portanto, podemos questionar: quais são os
recursos e aplicativos do sistema Android que podem ser utilizados? Como
melhorar a interface do usuário, tornando-a mais dinâmica? Como utilizar os seus
recursos de forma a desenvolver aplicativos com melhor qualidade?
O sistema operacional Android foi desenvolvido por um consórcio de empresas,
sendo que, além de ser um sistema aberto, ele detém outras vantagens como, por
exemplo, o fato de várias marcas de dispositivos móveis o utilizarem como SO e a
possibilidade de ter acesso a vários so wares por meio do serviço de distribuição
digital de aplicativos.
Este capítulo é focado nos recursos e padrões de programação do sistema
operacional Android. Vamos entender como é feita a persistência de arquivos,
como funciona o banco de dados SQLite e os provedores de conteúdo, como é o
processamento XML e como são identificadas as formas de acesso à rede. Por fim,
será apresentado o padrão de desenvolvimento JSON e a ferramenta Retrofit.
Acompanhe com atenção e bons estudos!

2.1 Sistemas de arquivo e acesso à rede

A grande maioria dos sistemas precisa que seus dados fiquem armazenados em
algum dispositivo para posterior acesso. Esta quantidade de dados a serem
armazenados dependerá da natureza e do propósito do sistema. Mas, como esse
armazenamento de dados é controlado no sistema operacional de um dispositivo
móvel? Como o sistema operacional Android gerencia os dados que necessitam ser
armazenados?
Vamos entender, agora, sobre a persistência dos dados no sistema operacional
Android e quais são os seus principais comandos.
Mas, primeiro, vamos descrever o que é o Android. Conforme explicado por Pilar
(2013, p. 43) “o Android é uma plataforma móvel de código livre, baseada em Linux
desenvolvida pela Google, com o objetivo de operar em dispositivos com toque na
tela, como smartphones e tablets”. As principais características do Android são
(PILAR, 2013, p. 44):
 utilização de widgets: pequenos ícones que ficam na tela inicial, onde é possível
escolher entre seus aplicativos favoritos, tendo acesso a atualizações sem sair
da tela principal; tela de notificações: onde é possível visualizar em um só
lugar as notificações de novas ligações, mensagens e e-mails;
multitarefa: é possível executar diversos aplicativos ao mesmo tempo e
alternar a visualização entre eles; escrita por voz: possibilidade de escrever e-
mails, SMS e qualquer tipo de texto, através da voz;
compartilhamento de imagens: possibilidade de explorar, editar e
compartilhar rapidamente nas redes sociais as fotos tiradas direto do
celular;
compartilhar com o toque: compartilhamento de fotos e vídeos com outros
celulares com a mesma tecnologia, apenas encostando-os.
Também é possível parear dispositivos via bluetooth apenas encostando os
aparelhos;
Fotos panorâmicas de 360º: através do Photo Sphere é possível tirar fotos
panorâmicas de todo o seu redor e realizar upload do resultado direto para
o Google Maps, onde outros usuários poderão visualizá-la;
múltiplos usuários: nos tablets, é possível criar múltiplos usuários, cada um com
sua tela inicial, aplicativos e jogos.

Para que o dispositivo móvel possa executar todas as funcionalidades, é

fundamental que as informações sejam armazenadas e recuperadas com
eficiência. Vamos ver, a seguir, a demonstração da persistência de arquivos no
sistema operacional Android.

Persistência de arquivos e preferências

Para poder disponibilizar todas as funcionalidades, é necessário que os dados de
todas as aplicações sejam armazenados e recuperados, portanto, precisam ser
salvos. Os dispositivos podem guardar uma quantidade limitada de informações no
seu próprio armazenamento, porém, está restrito ao tamanho do espaço do
endereçamento virtual. Tanenbaum (2016, p. 181) explica que “para algumas
aplicações esse tamanho é adequado, mas, para outras, como reservas de
passagens aéreas, bancos ou sistemas corporativos, ele é pequeno demais”.
Outro problema relativo ao armazenamento é a perda das informações quando o
processo é concluído. Além destes problemas, o que ocorre é que vários processos
concorrentes precisam acessar a mesma informação ao mesmo tempo. A solução
encontrada é tornar a informação independente de qualquer processo.
Tanenbaum (2016, p. 181) descreve os três requisitos essenciais para o
armazenamento de informação por um longo prazo:

deve ser possível armazenar uma quantidade muito

grande de informações;
as informações devem sobreviver ao término do processo que as está
utilizando; múltiplos processos têm que ser capazes de acessá-las ao mesmo
tempo.

Portanto, as informações armazenadas em arquivos, devem ser persistentes, quer

dizer, não podem ser afetadas por uma criação ou término de qualquer processo.
Mas, como, no caso do Android, os dados podem ser salvos e serem persistentes?
O Android oferece várias opções de armazenamento dos dados persistentes de
aplicativos. Inicialmente, a escolha dependerá das necessidades do aplicativo, se
devem ser privados ou podem ser acessados por outros aplicativos. O Android
oferece quatro maneiras de armazenamento. Vamos ver quais são a seguir.

VOCÊ QUER LER?

Quer conhecer uma pesquisa que auxilia o diagnóstico e a pesquisa médica, baseada em mineração de
dados, utilizando interface Android? Este trabalho foi desenvolvido por Fernandes (2013). Para
conhecer, acesse: < http://hdl.handle.net/10923/3199 (http://hdl.handle.net/10923/3199)>.

Quando se desenvolvem aplicativos para dispositivos móveis, muitas vezes é

necessária a criação de um banco de dados, ou o armazenamento, quando há um
número reduzido de dados. Com este objetivo, o sistema operacional Android
oferece a classe SharePreferences. Inicialmente, a classe SharedPreference
possibilita salvar e recuperar pares de valor de dados primitivos. Ressaltando que
dados primitivos são dados booleanos, ponto flutuante, inteiros, inteiros longos e
strings.
A maneira de se recuperar os dados são duas. A primeira é o método
getSharedPreferences (string nome, int modo), que permite obter várias
preferências identificadas pelo nome que foi passado como parâmetro. O outro
método é o getPreferences (int modo), para se recuperar dados dentro de uma
mesma chave.
Outra forma possível de armazenamento no Android é o armazenamento interno
de dados, que podem ser salvos diretamente na memória do dispositivo. De forma
geral, outros aplicativos não têm permissão de acessar estes dados, a não ser o
próprio aplicativo que os criou. O que ocorre é que quando o aplicativo que
armazenou estes dados é desinstalado, os dados também são removidos. Os
métodos de programação que permitem manipular estas informações são:

openFileOutput(), com o nome do arquivo e o modo de

funcionamento para recuperar os dados armazenados. Para
escrever estes dados, se usa o método write() e o método close()
para encerrar o fluxo;
armazenamento externo. Quando o dispositivo é compatível com
o Android, ele comporta uma memória externa para salvar
arquivos, podendo ser uma mídia removível. É necessário executar
na classe Environment, o método getExternalStorageState() para
verificar se a mídia externa está disponível e o método
getExternalFilesDir(), para acessar o arquivo.

Banco de dados SQLite e provedores de conteúdo

O Android desenvolveu um banco de dados com código aberto de estrutura
relacional chamado SQLite. O SQLite é embutido em todos os dispositivos com o
sistema operacional Android, sendo que o desenvolvedor de aplicativos, para esta
plataforma, precisa somente definir as estruturas das tabelas e as operações que
serão realizadas. Uma das suas principais características é que o SQLite não
necessita que nenhum servidor SQL seja previamente instalado. Pois “SQLite é um
dos mecanismos de banco de dados mais amplamente distribuídos do mundo.
Cada fragmento deste aplicativo interage com um banco de dados SQLite por
intermédio da classe utilitária DatabaseConnector” (DEITEL; DEITEL; WALD, 2016,
p. 244). Ou seja, não é necessário fazer sua instalação e nem a configuração, visto
que todo o banco de dados fica em arquivo. Na verdade, o SQLite é uma biblioteca
em linguagem “C”, na qual ela mesma gerencia o banco.
Outra capacidade de armazenamento de dados do Android são os provedores de
conteúdo. Estes são objetos que tem a capacidade de armazenar os dados de forma
permanente, tornando-os disponíveis para que outras aplicações possam acessar.
O pacote Android.provider já fornece este provedor de conteúdo. O Android fornece
duas maneiras para que os seus dados se tornem públicos. Uma é a classe
ContentProvider. Mas, como é possível localizar um provedor de conteúdo?
Cada tipo de dado disponibilizado pode ser encontrado por uma URI (Uniform
Resource Identifier) diferente. Outra característica é que um mesmo provedor pode
disponibilizar vários tipos de dados, sendo que cada tipo tem um URI diferente.
Tem-se como exemplo:

Android.provider.contacts.Phones.CONTENT_URI

Observe que a classe é separada em quatro: a primeira parte indica que o dado é
fornecido por um determinado provedor de conteúdo; logo após, vem o
identificador do provedor de conteúdo; em seguida o tipo de dados; e, por fim, o
identificador de um determinado registro.

Processamento XmlPullParser
O XML (do inglês eXtensible Markup Language) é uma linguagem de marcação,
diferente das outras linguagens de programação, que corresponde a um agregado
de códigos para padronizar uma determinada sequência de dados, separando o
conteúdo do código. Ela foi desenvolvida originalmente para criar documentos, nos
quais os dados são organizados hierarquicamente. Vamos ver, a seguir, um
exemplo de um documento XML.
#PraCegoVer: Código: <aviso> <para>Fernando data= “18/06/2018”</para>
<de>Juliana</de> <cabecalho>Lembrete</cabecalho> <corpo>É necessário fazer
as correções no documento</corpo> </aviso>

A primeira linha do documento, <?xml version="1.0"?>, é uma declaração XML e é

necessário que seja incluída, pois define a versão XML do documento. No exemplo,
está sendo especificada a versão 1.0 da XML.

A linha <aviso>, define o primeiro elemento do documento, o elemento raiz.

Estas quatro linhas definem os quatro elementos filhos da raiz (para, de, cabeçalho e
corpo).
Por fim, última linha, </aviso>, define o fim do elemento raiz.

VOCÊ QUER LER?

O artigo “Sistema de recomendação baseado na localização e perfil utilizando a plataforma Android”
(MACK, 2010) mostra como projetar um aplicativo no sistema operacional Android, para que os usuários
recebam recomendações de estabelecimentos comerciais que fazem parte de uma determinada
categoria, utilizando a posição geográfica do usuário. Para ler o trabalho completo, acesse: <
http://hdl.handle.net/10183/28328 (http://hdl.handle.net/10183/28328)>.

No caso do sistema operacional Android, o XML contido nele, pode ser de um dos
seguintes tipos: DOM, SAX e PullParser. O PullParser é uma interface que permite
criar implementações do XML. Existem diferentes tipos de parser, dependendo dos
recursos. Um deles é o analisador de não-validação, conforme a especificação XML
1.0, quando FEATURE_PROCESS_DOCDECL está definido como verdadeiro. Por
outro lado, quando FEATURE_PROCESS_DOCDECL é falso, o analisador se
comporta como sendo uma validação não compatível com XML 1.0 sob a condição
de que nenhum DOCDECL esteja presente em documentos XML.
Este modo de operação destina-se a ambientes restritos, como o J2ME ou JME. JME
significa “Java Platform, Micro Edition”, oferecendo mais robustez e flexibilidade
para aplicativos que são executados em dispositivos móveis e integrados, como
celulares, dispositivos de mídia digital e impressoras. Utilizandose o método next()
é possível recuperar o valor de um determinado evento e

compará-lo às constantes dos eventos da classe que está sendo executada. Cada
elemento que foi encontrado tem um nome, valor de texto e um conjunto opcional
de atributos.

Acesso à rede
O sistema operacional Android engloba uma série de funcionalidades, como o
acesso à rede. Neste caso, existe a solução Android Samba Client (SMB) que permite
acessar arquivos externos ao dispositivo móvel. Portanto, qualquer dispositivo
móvel que utilizar o Android pode acessar, por exemplo, partições do Windows.

Formato JSON
JSON – do inglês JavaScript Object Notation – é uma estrutura que tem por objetivo
representar os dados. Ela foi desenvolvida para ter um formato mais leve e simples
de troca de dados. O Android fornece quatro classes diferentes para manipular
dados JSON. Essas classes são: JSONArray, JSONObject, JSONStringer e
JSONTokenizer. Existe uma vantagem ao se utilizar a classe JSON, que é a
possibilidade de acessar as aplicações web no sistema operacional Android, sendo
que no XML é necessário encontrar uma solução para integração, como baixar um
leitor de XML. Comparando-se o XML e JSON, um arquivo XML é mais “burocrático”
de ser escrito do que o JSON. Por exemplo, se formos representar uma pessoa com
os atributos “nome” e “idade”, em XML, ficaria no seguinte formato:

<pessoa>
<nome>Nawarian Níckolas</nome>
<idade>20</idade>
</pessoa>

Se for representado em JSON, ficaria da seguinte maneira:

{
"nome": "Nawarian Níckolas",
"idade": 20
}

Portanto, o XML possui uma capacidade descritiva muito

alta e, consequentemente, pode alcançar níveis de complexidade muito altos.

Retrofit para acesso a serviços REST

Os aplicativos de dispositivos móveis precisam se conectar com outros aparelhos
para receber e enviar dados. O HTTP – sigla de HyperText Transfer Protocol (que
significa Protocolo de Transferência de Hipertexto) – é um protocolo que efetua a
transferência de dados entre computadores em rede. E como é realizada esta
transferência no sistema operacional Android?
O sistema operacional Android oferece a biblioteca retrofit, que permite ao
desenvolvedor realizar qualquer tipo de comunicação, via HTTP, de forma bastante
amigável. Tendo sido desenvolvida em Java, com o objetivo de criar uma
solicitação HTTP, o modelo REST (REpresentational State Transfer) representa a
possibilidade para a criação de web services, cujas principais diferenças em relação
ao modelo tradicional estão na utilização semântica dos métodos HTTP (GET,
POST, PUT e DELETE) (SUBONIS, 2017).
Portanto, esta biblioteca do Android processa a resposta HTTP de uma API REST. O
REST Client é a biblioteca Retrofit que é usada no lado do cliente (Android) para
fazer uma solicitação HTTP para a API REST, o que seria o nosso caso.
Uma API REST define um conjunto de funções, nas quais os desenvolvedores
podem executar solicitações e receber respostas, via protocolo HTTP, como GET e
POST. Também pode-se dizer que uma API RESTful é uma interface de programa de
aplicativo (API, em inglês: Application Programming Interface) que usa solicitações
HTTP para dados GET, PUT, POST e DELETE.

Desenvolvimento de aplicativo utilizando SQLite

Vamos demonstrar, a seguir, a criação de um aplicativo CRUD (criação, consulta,
alteração e exclusão) para o controle de livros de uma biblioteca, utilizando o
banco de dados interno ao Android, o SQLite.
Os programadores Deitel, Deitel e Wald (2016) definem o SQLite como um banco de
dados no modelo relacional, com código de acesso livre. O sistema operacional
Android permite criar quantos bancos de dados forem necessários, sendo
acessados e visualizados somente pelo próprio aplicativo.
É necessário utilizar uma API de acesso ao banco de dados SQLite, que já é um
componente do pacote SDK. Assim, duas classes serão utilizadas para a criação do
banco de dados, via aplicação (DEITEL; DEITEL; WALD, 2016):

SQLiteDatabase: nesta classe, estão os métodos de manipulação dos

dados no banco;
SQLiteOpenHelper: esta é a classe responsável pela criação do banco
e por seu versionamento.

Vamos ver como fica na figura a seguir.

Figura 1 - Criação de uma classe para a criação do banco de dados de um aplicativo desenvolvido em Android.
Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela com o código:

import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
/**
* Created by Fernando Skackauskas Dias – 2018.
*/
public class CriaBanco extends SQLiteOpenHelper {
@Override
Public void onCreate(SQLiteDatabase db){
}

@Override
public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) {

}
}
O código apresentado acima foi desenvolvido na ferramenta Android Studio, na
qual foi feita a prototipação dos métodos. É necessário implementar dois métodos
para que o aplicativo funcione corretamente:

onCreate(): este é o método implementado no momento em que a

aplicação cria o banco de dados pela primeira vez. Ele deve conter
todas as diretrizes de criação e inserção de dados inicial do banco;
onUpgrade(): este é o método que atualiza o banco de dados com
as alterações sofridas pelas informações estruturais.

O objeto principal e db da classe SQLite, o método onUpgrade(), tem como objetivo

atualizar as informações. Ele recebe dois parâmetros: a versão antiga da tabela e
uma nova versão, para onde deverá ser feito o upgrade. Assim será criada uma
tabela de cadastro com os campos: id, título, autor e editora. Na figura a seguir, é
mostrado o código com o método onUpgrade(), com o comando SQL que deleta a
tabela, caso ela exista, para depois, invocar o método onCreate() e recriar a tabela
com as alterações feitas.
 Figura 2 - Criação de uma classe para desenvolver a estrutura com os campos do banco de dados de um
aplicativo em Android. Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela com o código:

import android.database.sqlite.SQLiteDatabase;
import android.database.sqlite.SQLiteOpenHelper;
/**
* Created by Fernando Skackauskas Dias – 2018.
*/
public class CriaBanco extends SQLiteOpenHelper {
private static final String NOME_BANCO = “banco.db”;
private static final String TABELA = “livros”; private static
final String ID = “id”; private static final String TITULO =
“titulo”; private static final String AUTOR = “autor”; private
static final String EDITORA = “editora”; private static final
int VERSAO = 1;

@Override
public void onCreate(SQLiteDatabase db){ String
sql = “CREATE TABLE”+TABELA+“{“
+ ID + “integer primary key autoincrement,”
+ TITULO + “text,”
+ AUTOR + “text,”
+ EDITORA + “text,”
+ “}”;
db.execSQL(sql);
}
Public CriaBanco(Context context){
super(context, NOEM_BANCO,null,VERSAO);
}

@Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int

newVersion) { db.execSQL(“DROP TABLE IF EXISTS” + TABELA);
onCreate(db);
}
}

Para criar uma Activity é necessário estender a classe Activity, ou uma de suas
implementações como AppCompatActivity ou ListActivity. Isso tem como objetivo
fazer com que a classe herde todas as características das Activities, senão ela seria
somente uma classe do Java. Temos um exemplo a seguir.
#PraCegoVer: Print da tela com o código:

public class MainActivity extends AppCompatActivity {

@Override protected void onCreate(Bundle
savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
}
}

Na figura a seguir, podemos ver a tela do Android Studio, na qual é possível criar a
interface de entrada de dados.
Figura 3 - Tela do Android Studio, onde é possível elaborar a interface do usuário descrevendo os campos a
serem exibidos no aplicativo. Fonte: Elaborada pelo autor, 2018, adaptada da tela do Preview do Android
Studio.

#PraCegoVer: Desenho de um celular, além dos campos: Layout, Widgets. Na tela do

celular tem uma faixa azul no topo da tela escrito Overdraw.

Agora, o arquivo XML do layout no Android Studio, no qual, o usuário insere as

informações.
Figura 4 - Código XML do layout do Insert de um aplicativo desenvolvido em Android, utilizando o banco de
dados nativo SQLite. Fonte: elaborada pelo autor, adaptada da tela do Preview do Android Studio, 2018.

#PraCegoVer: Print da tela com o código:

<RelativeLayout
xmlns?android=“http://schemas.android.com/apk/res/android”
xmlns:tools=“http://schemas.android.com/tools”
android:layout_width=”match_parent” android:layout_height=”match_parent”
android:paddingLe =”@dimen/activity_horizontal_margin”
android:paddingRight=”@dimen/activity_horizontal_margin”
android:paddingTop=”@dimen/activity_vertical_margin”
android:paddingBottom=”@dimen/activity_vertical_margin”
tools:context=“.Inicial” android:id=“@+id/Inser”/

<TextView android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:textAppearence=“?android:attr/textAppearanceMedium
” android:text=“Titulo:” android:id=“@+id/TextView”
android:layout_marginTop=“47dp”
android:layout_alignParentTop=“true”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true” />
<EditView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:id=“@+id/editText”
android:layout_below=“@+id/textView”
android:layout_alignParentLe =“true”
android:layout_alignParentRight=“true”
android:layout_alignParentEnd=“true” />

<TextView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:textAppearence=“?android:attr/textAppearanceMedium
” android:text=“Autor:” android:id=“@+id/TextView2”
android:layout_below=“@+id/editText”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true”
android:layout_marginTop=“51dp” />

<EditView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:id=“@+id/editText2”
android:layout_below=“@+id/textView2”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true”
android:layout_alignRight=“@+id/editText”
android:layout_alignEnd=“@+id/editText” />

<TextView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:textAppearence=“?android:attr/textAppearanceMedium
” android:text=“Editora:”

android:id=“@+id/TextView3”
android:layout_below=“@+id/editText2”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true”
android:layout_marginTop=“64dp” />
<EditView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:id=“@+id/editText3”
android:layout_below=“@+id/textView3”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true”
android:layout_alignRight=“@+id/editText2”
android:layout_alignEnd=“@+id/editText2” />

<Button
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:text=“Cadastrar”
android:id=“@+id/button”
android:layout_below=“@+id/editText3”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true”
android:layout_marginTop=“72dp”
android:layout_alignRight=“@+id/editText3”
android:layout_alignEnd=“@+id/editText3”
/>

<TextView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:textAppearence=“?android:attr/textAppearanceMedium
” android:id=“@+id/TextView4”
android:layout_alignParentBottom=“true”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true” />

</RelativeLayout>

É possível ver na figura a seguir, como fica representada a interface do aplicativo

em um dispositivo móvel.
 Figura 5 - Layout do cadastro de
livro de um aplicativo desenvolvido em Android, utilizando o banco de dados nativo SQLite e a ferramenta
Android Studio. Fonte: Elaborada pelo autor, adaptada de Fenton one, Shutterstock, 2018.

#PraCegoVer: Desenho de um celular com os campos Título, Autor e Editora para

serem preeenchidos e embaixo o botão cadastrar.

O código ainda não apresenta nenhuma funcionalidade, pois não foi programado
internamente ao Activity que fará o controle. Existem duas classes contidas no
código: a classe Activity, cujo objetivo é controlar a interface, e a classe
BancoController, cujo objetivo é manter o controle das operações no banco de
dados.
A classe BancoController faz o controle das manipulações no banco de dados, e é
necessária para a execução do aplicativo. O atributo banco é repassado na
instanciação do construtor das classes. De forma semelhante, o resultado do
método getWritableDatabase() é passado ao atributo db. Esta ação faz a
comunicação ao sistema operacional Android para a leitura e manipulação dos
dados. Para a inserção dos dados, o método insert() recebe a tabela de dados ao
final, encerrando a conexão.
Na figura a seguir, são demonstradas as classes BancoController e InsereDado.
 Figura 6 - Classes de inserção de dados em Android, utilizando o banco de dados nativo SQLite e a
ferramenta Android Studio. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Print da tela com o código:

pubic class BancoController{

private SQLiteDatabase db; private
CriaBanco banco;

public BancoController(Context context){ banco

= new CriaBanco(context);
}

Public String insereDado(String titulo, String autor, String editora) {

ContentValue valores; Long
resultado;

db = banco.getWritableDatabase();
valores = new ContentValue();
valores.put(CriaBanco.TITULO, titulo);
valores.put(CriaBanco.AUTOR, autor);
valores.put(CriaBanco.EDITORA, editora);

resultado = db.insert(CriaBanco. TABELA, null, valores); db.close();

if (resulado ==-1)
return “Erro ao inserir registro”; else
return “Registro Inserido com sucesso”;
}
}

public class ClassInsereDado extends Activity{

@Override protected void onCreate (Bundle

savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_inicial);

Buttom botao = (Button)findViewById(R.id.button); botao.setonClickListener(new

View.onClickListenner() {
@Override
public void onClick(View v) {
BancoController crud = new BancoController(getBaseContext());
EditText titulo = (EditText)findViewById(R.id.editText);
EditText autor = (EditText)findViewById(R.id.editText2);
EditText editora = (EditText)findViewById(R.id.editText3);
String tituloString = titulo.getText().toString();
String autorString = autor.getText().toString();
String editoraString = editora.getText().toString();
String resultado;

resultado = crud.insereDado(tituloString,autorString,editoraString);
Toast.makeText(getApplicationContext(),resultado, Toast.LENGTH_LONG).show();
}
}};
}
}

Para fazer a consulta aos dados, precisamos criar a interface, que apresenta um
ListView, que é um arquivo de XML de layout para sua estilização, como é mostrado
na figura a seguir.

Figura 7 - Código da Interface do usuário de consulta desenvolvido com o banco de dados SQLite e a
ferramenta Android Studio. Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela com o código:

<RelativeLayout xmlns?android=http://schemas.android.com/apk/res/android
xmlns:tools=http://schemas.android.com/tools
android:layout_width=”match_parent”
android:layout_height=”match_parent”
android:paddingLe =”@dimen/activity_horizontal_margin”
android:paddingRight=”@dimen/activity_horizontal_margin”
android:paddingTop=”@dimen/activity_vertical_margin”
android:paddingBottom=”@dimen/activity_vertical_margin”
tools:context=”br.com.home.bancodedados.Consulta”>

<ListView
android:layout_width=“wrap_content”
android:layout_height=“wrap_content”
android:id=“@+id/listView”
android:layout_alignParentLe =“true”
android:layout_alignParentStart=“true” />
</RelativeLayout>
O resultado da criação do layout pode ser conferido na figura a seguir.
 Figura 8 - Layout de consulta de
livro de um aplicativo desenvolvido em Android, utilizando o banco de dados nativo SQLite e a ferramenta
Android Studio. Fonte: Elaborada pelo autor, adaptada de Fenton one, Shutterstock, 2018.

#PraCegoVer: Desenho de um celular com os campos Item 1 Subitem 1, embaixo

Item 2 Subitem 2, embaixo Item 3 Subitem 3, Item 4 Subitem 4, Item 5 Subitem 5,
Item 6.
Neste exemplo, foi possível entender o desenvolvimento de um aplicativo Android,
com as funcionalidades de inclusão e consulta, utilizando o banco de dados nativo
SQLite e a ferramenta Android Studio.
2.2 Processamento assíncrono
m determinadas situações, pode ser necessário que mais de um processo seja
executado simultaneamente. Isto se chama processo assíncrono. Para isso, os
processos são realizados simultaneamente, sem a necessidade que um termine
para outro ser executado. Como esta função é executada em dispositivos móveis?
Como o Android trata os processamentos assíncronos? A seguir, serão
apresentados os processamentos assíncronos do sistema operacional Android.

Processamento com Handlers, AsyncTasks e Loaders

Nos dispositivos móveis, é possível realizar processos que são executados ao
mesmo tempo, de duas formas: pelo paralelismo ou pelo pseudoparalelismo. Um
processo é realizado em paralelo, se houver mais de um núcleo no processador,
sendo que cada processo é realizado em um núcleo. Caso seja realizado mais de um
processo em um núcleo, ocorrerá o pseudoparalelismo. Este procedimento
escalona e processa parte de cada tarefa por vez. O time-slice tem a função de retirar
parte de cada processo e executar a parte de outro colocando no final de uma fila
de processos que estão prontos para serem executados. No Android são utilizados
os threads, que permitem a criação de linhas de execução a serem processadas em
paralelo.

VOCÊ SABIA?
Como os smartphones usam uma arquitetura de so ware semelhante à dos PCs, eles
tem as mesmas vulnerabilidades, mas a diferença é que seus recursos são limitados
e impedem a integração de soluções avançadas de monitoramento de segurança.
No artigo “Secloud: a cloud-based comprehensive and lightweight security solution for
smartphones”, o pesquisador Zonous e seus colaboradores (2013) propõem a
Secloud, uma solução de segurança baseada em nuvem, para dispositivos
smartphone, demonstrando o uso dos recursos do sistema operacional Android:
<https://www.sciencedirect.com/science/article/pii/S016740481300031X
(https://www.sciencedirect.com/science/article/pii/S016740481300031X)>.
A atualização da interface gráfica, a partir das informações processadas, precisa de
handlers e, para isso, a classe AsyncTask foi criada. Ela permite que esses processos
rodem em segundo plano, a fim de atualizar os dados na Interface. Deitel, Deitel e
Wald (2016, p. 245), descrevem o processo da seguinte forma:

Quando precisarmos dos resultados de uma operação de banco de dados na

thread da interface gráfica, vamos usar uma subclasse de AsyncTask (pacote
Android.os) para efetuar a operação em uma thread e receber os resultados
na thread da interface. Os detalhes da criação e manipulação de threads são
tratados pela classe AsyncTask, assim como a comunicação dos resultados
de AsyncTask para a thread da interface gráfica do usuário.

Assim, vemos que a classe AsyncTask tem a função de encapsular a criação das
funções threads e handler. A criação da classe é feita pela ação
AsyncTask<Parâmetro, Progresso, Resultado>, na qual os parâmetros passados são
o tipo de dados, o Progresso e o retorno da thread (Resultado). A classe AsyncTask
compreende outros métodos sobrescritos que são o onPreExecute (antes de se
iniciar a thread), o método doInBackground (processamento em paralelo e
background, para processamentos pesados), o método onPostExecute (retorno do
doInBackground) e onProgressUpdate (percentual do download para a interface)
(DEITEL; DEITEL; WALD, 2016).

Serviços no Android
Simões e Pereira (2014) explicam que serviço é uma parte de um aplicativo, com
operação mais pesada e que não interage com a interface. Um serviço é iniciado por
um determinado componente do aplicativo, sendo executado em segundo plano,
mesmo havendo alteração entre os aplicativos pelo usuário (DEITEL; DEITEL; WALD,
2016). Conforme descrito por Simões e Pereira (2014), pode ter duas formas:

iniciado. A iniciação de um serviço é realizada pelo método

startService(), ficando em execução em segundo plano, mesmo que o
componente que o iniciou seja cancelado. Quando a operação for
concluída, o serviço deverá ser interrompido; vinculado. Um
serviço é "vinculado" quando um componente do aplicativo chama
 bindService() para vinculá-lo. Um serviço vinculado oferece uma
interface servidor-cliente que permite que os componentes interajam
com a interface, enviem solicitações, obtenham resultados, mesmo
em processos com Comunicação Interprocessual (IPC). Um serviço
vinculado permanece em execução somente enquanto outro
componente do aplicativo estiver vinculado a ele. Vários
componentes podem ser vinculados ao serviço de uma só vez, mas
quando todos desfizerem o vínculo, o serviço será destruído.

Assim, um serviço iniciado é o que permanece em execução indefinidamente em

segundo plano, mas pode também permitir a vinculação, sendo que este serviço
permanece em execução, enquanto outro componente estiver associado a ele.

VOCÊ SABIA?
O modelo de programação assíncrona é comumente usado em sistemas móveis e
ambientes web 2.0. Porém, usam algoritmos que são de magnitude de desempenho
e espaço ineficiente, em comparação com os detectores de dados convencionais.
Pensando nisso, o pesquisador Hsiao e seus colaboradores (2017) resolveram
identificar e abordar dois problemas importantes no raciocínio sobre a causalidade
entre eventos assíncronos. Eles propõem uma nova classe chamada AsyncClock,
que resolve esse problema, explicitamente rastreando eventos causalmente
precedentes.
Se o aplicativo for iniciado ou vinculado, outros componentes do aplicativo
poderão usar o serviço, da mesma forma que qualquer componente poderá usar
uma atividade — iniciando com uma Intent. Portanto, é possível declarar o serviço
como privado, no arquivo do manifest, e bloquear o acesso de outros aplicativos.

Download de imagens com o Google Glide

O Google Glide é um aplicativo que permite que usuários troquem mensagens de
vídeo em tempo real, bastante útil quando incorporado ao uso corporativo ou,
mesmo, pessoal.
 VOCÊ O CONHECE?
Sundar Pichai é o atual CEO da Google, que adquiriu o sistema operacional Android Inc, em agosto de
2005. Em 2004, ele liderou na Google, o gerenciamento de produtos como o Google Chrome e Chrome
OS e, com o passar do tempo, começou a liderar outros projetos, como o sistema operacional Android.
Leia mais no artigo escrito por Griffith (2015), disponível em
<https://www.pcmag.com/article2/0,2817,2489388,00.asp
(https://www.pcmag.com/article2/0,2817,2489388,00.asp)>.

Conforme exposto por Goovaerts (2016), o Google Glide permitirá que usuários
façam e recebam chamadas por Bluetooth e escutem mensagens de áudio e vídeo,
por meio de aplicativos. O Glide é uma biblioteca do Image Loader para Android,
desenvolvida e recomendada pela Google. Ele foi usado em muitos projetos de
código aberto da Google, incluindo o aplicativo oficial Google I / O 2014. Ele fornece
suporte a GIF animado e lida com o carregamento / armazenamento de imagens.
Glide é uma biblioteca de carregamento de imagens rápida e eficiente para Android,
focada em rolagem suave. O Glide oferece uma API fácil de usar, um pipeline de
decodificação de recursos e extensíveis e um conjunto automático de recursos.
Glide suporta busca, decodificação e exibição de fotos de vídeo, imagens e GIFs
animados. O Glide inclui uma API flexível, que permite aos desenvolvedores
conectar-se a praticamente qualquer pilha de rede. Por padrão, o Glide usa uma
pilha baseada em HttpUrlConnection, mas também inclui bibliotecas de utilitários
no projeto Volley da Google ou na biblioteca OkHttp da Square. O Glide leva em
consideração dois aspectos principais do desempenho do carregamento de
imagens no Android:

a velocidade na qual as imagens podem ser decodificadas; o

montante de resíduos ocorridos durante a decodificação de
imagens.

Para que os usuários tenham uma ótima experiência com um aplicativo, as imagens
não devem aparecer apenas rapidamente, mas devem também fazê-lo sem causar
muita interferência e engasgos com a entrada e saída do thread principal, ou com o
excesso de coleta de lixo.
O Glide realiza várias etapas para garantir que o carregamento de imagens seja o
mais rápido e suave possível no Android:

a redução de escala e o armazenamento em cache inteligentes e

automáticos minimizam os tempos de sobrecarga e decodificação
do armazenamento.
a reutilização agressiva de recursos, como matrizes de bytes e
bitmaps, minimiza as dispendiosas coletas de lixo e a
fragmentação de heap.
a integração profunda do ciclo de vida garante que apenas as
solicitações para fragmentos e atividades ativos sejam priorizadas,
e que os aplicativos liberem recursos, quando necessário, para
evitar serem eliminados, quando estão em segundo plano.

O foco principal do Glide é tornar a rolagem, de qualquer tipo de lista de imagens,

o mais suave e rápida possível, mas o Glide também é eficaz em quase todos os
casos em que você precisa buscar, redimensionar e exibir uma imagem remota.

2.3 Receptores e notificações

A forma como as informações são recebidas e notificadas nos diversos sistemas
operacionais são diferenciadas. Como o sistema operacional Android efetua as
notificações para a interface do usuário?
Vamos acompanhar agora como o Android trabalha com os receptores e
notificações no seu sistema operacional.

JobScheduler
O componente JobScheduler tem como objetivo planejar os processos, para tornar
o processamento mais eficiente, inclusive reduzindo o consumo de energia. Neste
sentido, são criadas classes lógicas para o gerenciamento dos sinais. É criada,
também, a classe SynAdapater para executar tarefas em background, tornando
mais ágeis os processos em execução. O JobScheduler não consegue ter o controle
dos serviços escalonados, sendo que o espaço de intervalo de execução é definido
pelos métodos setPeriodic(), setBackoffCriteria() e setOverrideDeadline().
Para Meike (2016, p. 155), “a maior motivação para a criação do JobScheduler é um
controle mais refinado do agendamento das tarefas assíncronas [...] a arquitetura
do JobSchedule é um modelo que está entre as classes sync-adapter e
AlarmManager”. Quando se processa o JobScheduler, são necessárias três etapas:
tornar a tarefa acessível pelo JobScheduler, agendar a tarefa e implementar o
agendamento.

BroadcastReceiver
Um BroadcastReceiver é um componente que responde aos eventos de
transmissão em todo o sistema. Muitas transmissões são originadas do próprio
sistema, como uma transmissão anunciando que a tela foi desligada ou a bateria
está fraca. Os aplicativos também podem iniciar transmissões para permitir que
outros aplicativos saibam que alguns dados foram baixados para o dispositivo e
estão disponíveis para serem usados. Embora os receptores de transmissão não
exibam, necessariamente, uma interface de usuário, eles podem criar uma
notificação de barra de status para alertar o usuário de algum evento de
transmissão. O mais comum porém, é que um receptor de broadcast seja apenas
um canal para outros componentes e tenha o objetivo de fazer uma quantidade
mínima de trabalho. Um receptor de broadcast é implementado como uma
subclasse de BroadcastReceiver e cada broadcast é entregue como um objeto
Intent.

Notificações no Android
No sistema operacional Android, uma notificação significa uma mensagem enviada
ao usuário, de uma forma normal. Estas notificações são realizadas por meio de um
ícone. O armazenamento destas notificações é gerenciado pelo próprio sistema
operacional Android, sendo que o usuário do sistema pode ter acesso a este
repositório. As classes que são utilizadas são o objeto NotificationCompat.Builder(),
para notificar as ações, o método NotificationCompat.Builder.build(), para criar a
notificação, e o método NotificationManager.notifiy(), para emitir a notificação.
Interface avançada do usuário
A interface com o usuário de um dispositivo móvel tem se desenvolvido de maneira
rápida e com recursos cada vez mais avançados. No sistema operacional Android
diversas novas funcionalidades foram criadas para atender de forma mais eficiente
às mais variadas demandas dos seus usuários.

Drag and drop, drawables, parcelables, styles, themes e widgets

Com a estrutura de trabalho de arrastar e soltar (drag and drop) do Android é
possível permitir que usuários movam dados de uma visão para outra no layout
atual, usando um gesto gráfico de arrastar e soltar. A estrutura de trabalho contém
uma classe de eventos de arrastar, e métodos e classes auxiliares.
Embora a estrutura de trabalho seja projetada principalmente para movimentação
de dados, é possível usá-la para outras ações de interface com o usuário. Por
exemplo, pode-se criar um aplicativo que mistura cores, quando o usuário arrasta
um ícone colorido sobre outro ícone.
É possível criar um objeto de evento de arrastar (“listening”) de uma classe que
programe a classe View.OnDragListener. O objeto do evento de arrastar para uma
visão é definido com o método setOnDragListener(). Cada objeto também tem um
método de retorno de chamada onDragEvent(). Ambos estão descritos em mais
detalhes.
Estilos e temas no Android permitem separar os detalhes do design de seu
aplicativo da estrutura e do comportamento da interface do usuário, semelhante
ao CSS (Cascading Style Sheets), no design da web. Um estilo é uma coleção de
atributos que especificam a aparência de uma única visão. Um estilo pode
especificar atributos como cor da fonte, tamanho da fonte, cor do plano de fundo e
muito mais.
Um tema é um tipo de estilo aplicado a uma hierarquia inteira de aplicativos,
atividades ou visualizações, não apenas uma visualização individual. Quando se
aplica seu estilo como tema, todas as visualizações no aplicativo se aplicam a cada
atributo de estilo que ele suporta. Os temas também podem aplicar estilos a
elementos que não são de visualização, como a barra de status e o plano de fundo
da janela. Estilos e temas são declarados em um arquivo de recurso de estilo
chamado styles.xml.
Quando é necessário exibir imagens estáticas em um aplicativo Android, poderá ser
usada a classe Drawable e suas subclasses para desenhar formas e imagens. A
Drawable é uma abstração geral para algo que pode ser desenhado. As várias
subclasses ajudam com cenários específicos de imagem e pode estendê-las para
definir seus próprios objetos, que se comportam de maneiras únicas. Existem duas
maneiras de definir e instanciar um Drawable, além de se usar os construtores de
classe:

acrescentar um recurso de imagem (um arquivo de bitmap)

salvo em seu projeto; acrescentar um recurso XML que define as
propriedades drawable.

No sistema operacional Android é possível adicionar gráficos ao aplicativo

referenciando um arquivo de imagem dos recursos do seu projeto. Os tipos de
arquivos suportados são PNG, JPG e GIF. Ícones de aplicativos, logotipos e outros
elementos gráficos, como os usados em jogos, são adequados para essa técnica.
Para usar um recurso de imagem, é necessário adicionar o arquivo ao diretório
drawable do projeto. Uma vez no projeto, pode-se referenciar o recurso de imagem
do código ou seu layout XML.

VOCÊ QUER VER?

Na palestra de Ygor Barbosa (Mobile Engineer da Nubank Brasil) e Thales Machado (So ware Engineer da
Nubank Brasil) (2017), você pode conhecer a experiência dos dois desenvolvedores com a arquitetura
dos aplicativos Android, na Conferência Android Dev de 2017. Para assistir acesse
<https://www.youtube.com/watch?v=Vgbe52XJkNU (https://www.youtube.com/watch?
v=Vgbe52XJkNU)>.

Parcelables e os Bundles são objetos que devem ser usados nos limites do processo,
como nas transações IPC/Binder, entre as atividades, com o objetivo de armazenar
o estado transitório nas alterações de configuração. O Bundle é um
armazenamento de chave/valor para objetos especializados, usado para passar
dados para componentes do Android. Se for preciso passar os objetos de cliente via
Bundle, é necessário implementar a Parcelable interface.
A Parcelable é a implementação do Android do Java Serializable que assume a
estrutura de processamento. Dessa forma, um Parcelable pode ser processado de
forma relativamente rápida, comparada com a serialização Java padrão. Para
permitir que o objeto seja analisado para outro componente, é preciso
implementar a Android.os.Parcelableinterface. Ele também fornece um método
final estático chamado CREATOR, que deve implementar a
Parcelable.Creatorinterface. “O objeto Parcelable é um objeto que implementa
uma API específica que requer dois métodos: o describeContent() e o writeParcel()”
(MEIKE, 2016, p. 116).
O sistema operacional Android oferece as funcionalidades de widgets, que são
pequenos aplicativos dispostos na tela inicial, que tornam o acesso mais rápido às
informações como previsão do tempo, hora e agenda, sem que seja necessário abrir
o aplicativo correspondente..

Composição e customização de views

Um conjunto de serviços para desenvolvimento, ou SDK (So ware Development Kits),

faz parte do sistema operacional Android para a construção dos componentes da
interface. Estes componentes podem ser widgets ou layouts. As classes View e
ViewGroup são responsáveis por construir os componentes. Em meio a estes
componentes, estão os já conhecidos em outras plataformas como Button,
TextView, EditText, ListView, CheckBox, RadioButton e ImageView.

Resource selectors
Os dispositivos Android vêm em uma variedade de configurações diferentes de
tamanho, densidade de pixels da tela, configurações de idioma, etc. O Android
suporta a seleção automática de recursos que se ajustam à configuração do
dispositivo. Para isso, o sistema fornece recursos diferentes em subpastas
predefinidas no diretório. O nome do sufixo de uma subpasta define a configuração
do dispositivo para a qual ela é válida, por exemplo, orientação, resolução ou
idiomas.
Temos, como exemplo, as telas de dispositivos Android, que são diferentes em
termos de resolução e em termos de densidade dos pixels na tela. No caso de
diferentes densidades de tela, o mesmo comprimento de um componente de
interface do usuário consiste em uma quantidade diferente de pixels. Por exemplo,
se o desenvolvedor especificar os pixels diretamente, poderá obter um
determinado resultado em um dispositivo com um número relativamente pequeno
de pixels. Por esta razão, é necessário fornecer recursos gráficos, por exemplo, os
ícones da barra de ação e laucher em diferentes resoluções. Isso pode ser feito
usando qualificadores de recursos com base na densidade de pixel. É possível usar
a densidade como qualificador de recurso. O Android suporta as seguintes seleções:
a linha de base é de 160 pontos por polegada (ppp). Se, por exemplo, o dispositivo
Android tiver 320 dpi, o drawable do drawable-hdpi será selecionado.

Uso de animações
As animações podem adicionar dicas visuais que avisam os usuários sobre o que
está acontecendo no aplicativo. Eles são especialmente úteis quando a interface do
usuário muda de estado, como quando novos carregamentos de conteúdo ou
novas ações ficam disponíveis. As animações também adicionam uma aparência
elegante ao aplicativo, o que proporciona maior qualidade.
O Property Animation é um framework disponível no Android e foi desenvolvido com
o objetivo de fornecer mais robustez e controle, ao desenvolver animações. O
Property Animation permite que qualquer objeto seja animado, seja este visível na
interface ou não. O funcionamento do Property Animation parte do princípio de que
é possível animar qualquer atributo de um objeto por um período de tempo, como
também definir as características importantes:

duração: o tempo total de execução da animação que, se não

alterado, permanece com o tempo default de 300ms;
interpolação do tempo: como os valores da animação serão
calculados em função do tempo.

O Android dispõe de várias interpolações que não passam de fórmulas, que podem
ser copiadas e modificadas, para satisfazer o objeto do aplicativo.
 CASO
Uma empresa de gestão de projetos percebeu que, um dos maiores problemas que
enfrentava, era devido aos atrasos no acompanhamento das tarefas dos projetos. Os
gestores de projetos tinham problemas de acompanhar o desenvolvimento e entrega
de todas as tarefas. Para contornar a situação, a empresa desenvolveu um aplicativo em
Android com a API 21, conhecida como o Android Lollipop. O Google forneceu um novo
componente conhecido como JobScheduler API, para lidar com esse mesmo cenário. A
JobScheduler API realiza uma operação para o aplicativo quando um conjunto de
condições predefinidas é atendido. Além disso, a JobScheduler é capaz de agrupar
várias tarefas para serem executadas juntas. Isso permite que o aplicativo execute e
informe a tarefa determinada, para que os gestores de projetos possam resolver os
problemas de acompanhamento.

O Android inclui diferentes APIs (API é um conjunto de rotinas e padrões de

programação para acesso a um aplicativo de so ware, ou plataforma, baseado na
web) de animação, dependendo do tipo de animação que se deseja. Portanto, essa
página fornece uma visão geral das diferentes maneiras de adicionar movimento à
interface do usuário. Quando se deseja animar um gráfico de bitmap, como um
ícone ou uma ilustração, deve usar as APIs de animação desenhados. Geralmente,
essas animações são definidas estaticamente com um recurso drawable, mas
também pode definir o comportamento da animação no tempo de execução.

Síntese
Compreendemos, neste capítulo, como utilizar e implantar os recursos e APIs do
sistema Android, de forma a tornar a interface de usuário mais dinâmica. Foi visto
como o sistema operacional Android oferece classes que permitem o acesso à rede,
ao armazenamento de dados e como fazer a persistência de dados. Ao implantar
um aplicativo em um dispositivo móvel, verificamos a importância dos
processamentos assíncronos e as notificações, agregando à interface, melhores
funcionalidades para o usuário.
Neste capítulo, você teve a oportunidade de:
 compreender e aplicar as principais classes e métodos de
armazenamento e manipulação de dados por meio do SQlite, o
processamento XmlPullParser, o formato JSON e a ferramenta Retrofit;
demonstrar e executar processamentos assíncronos utilizando
handlers e AsuncTaksas, e as manipulações de imagens e serviços no
sistema operacional Android utilizando o Google Glide;
identificar o serviço de agendamento e notificações por meio do
JobSchedulere BroadcastReceiver;
prender a utilizar os recursos de interface do Android como o drag and
drop, drawables, pacelables, styles, themes e widgets, com a
possibilidade de criar animações e o resource selectors.

Projeto
INTERFACE ANDROID
Segundo relatórios publicados a respeito da Internet pelas empresas “We are social”
e “ Hootsuite” em 2018, esses revelam que já passam de 4 bilhões de usuários de
Internet ao redor do mundo. Mais da metade da população mundial plugados na
Internet. O relatório aponta que mais de 1 bilhão de usuários se tornaram ativos na
Internet em 2017.

Esse crescimento de usuários online tem sido impulsionado por suas questões: o
barateamento dos smartphones, atualmente consegue-se comprar smartphones
com preços mais acessíveis e de ótima qualidade, e novos planos de dados providos
pelas operadoras de telefonia. As operadoras agregam valores aos serviços por
custo reduzido, como uso de redes sociais sem custos e telefonia sem custos ao
usuário, inclusive interurbana.

Esses números segundo o relatório impressionam pois são mais de 4 bilhões de

usuários na Internet, cerca de 3 bilhões de usuários em redes sociais e 5 bilhões de
aparelhos móveis como smartphones.

Nesse contexto digital, uma nova era se apresenta para o mundo computacional.
Novos desafios, novas tecnologias e inovações. Segundo dados do Comitê Gestor da
Internet Brasil, o brasileiro fica cerca de 9 horas e 14 minutos conectados por dia na
Internet, sendo o terceiro no mundo, atrás somente de Tailândia e Filipinas. Esse
tempo distribuído em entretenimento, trabalho e estudos (G1, 2018).

Todo esse acesso é realizado através de aplicações móveis, via http ou app mobile, e
a comunicação interativa por meio de telas. As telas são as interfaces da aplicação
através do qual o usuário interage com o sistema. Essas interfaces devem ser
usáveis, interativas e possuir elementos que atendam às necessidades dos usuários
como botões, imagens, banners, menus, links etc. Uma interface mal projetada pode
causar insatisfação ao usuário por não conseguir alcançar seus objetivos ao usar o
produto, mas ao contrário, uma interface bem planejada faz com que o usuário
consiga obter boas experiências de uso, manuseio fácil e eficiente.

No processo de desenvolvimento de uma interface de usuário, critérios devem ser

adotados relativos a necessidade do negócio e as necessidades do usuário. Muitas
vezes Application Programming Interface (APIs) devem ser utilizadas para melhor
atender a determinados requisitos, por exemplo, uso de API de mapas para serviços
de logísticas ou API para tratar sensores de próprio smartphones.

Ignorar o planejamento da Interface com usuário pode ser uma tomada de decisão
que resulta na rejeição da aplicação. Características como facilidade de manutenção,
fidelização de uso pelo cliente, trazer bons experiências ao usuário, tornando a
aplicação parte de dia a dia são resultados de uma interface bem planejada. Em
resumo, o usuário precisa alcançar seus objetivos de forma simples, eficiente,
através de fácil uso de uma interface.

Vamos Praticar
Convido você a pensar e fazer uma análise conceitual de um planejamento de
uma interface para um sistema específico de delivery de comidas para um
restaurante de comidas veganas. Faça uma análise de quais elementos de telas
comporiam a Interface do usuário e quais API poderiam ser usadas e sua
funcionalidade por meio de serviços que a aplicação poderia oferecer ao
usuário. Compartilhe no fórum da disciplina o seu ponto de vista. Faça esse
compartilhamento através de um texto detalhando a sua análise.
 COMPUTAÇÃO PARA
DISPOSITIVOS MÓVEIS
CAPÍTULO 3 - COMO PODEMOS
CONSTRUIR APLICATIVOS DE
QUALIDADE?
Fernando Skackauskas Dias

INICIAR

Introdução
Com a tendência cada vez mais forte de desenvolver aplicativos para dispositivos
móveis, para os mais diversos fins, o mercado passa a ser mais exigente com
qualidade, o que exige critérios mais elevados de boa interação, funcionalidades
inteligentes, alto desempenho, conectividade com as mais diversas plataformas e
com outros aplicativos. Para atender a essas exigências, os sistemas operacionais
são desenvolvidos com classes e componentes para serem utilizadas como
recursos nos aplicativos.
Estes recursos concentram utilidades, como ferramentas para depuração e testes,
que auxiliam os desenvolvedores a construírem aplicativos com maior agilidade e
robustez. Outra função dos SOs dispositivos móveis tem como objetivo analisar o
desempenho e a automatização na construção de aplicativos.
Neste capítulo, vamos entender o Databinding do SO Android, permitindo ao
desenvolvedor escrever layouts declarativos. Vamos aprender, também, a usar os
padrões MVP (Model-View-Presenter) e MVVM (Model-View-ViewModel) e o
componente Dagger2, e demonstrar como utilizar as ferramentas de teste e
depuração como o JUnit, Espresso e Robotium. Será mostrado como realizar a
análise de desempenho por meio de ferramentas de análise. Por fim, serão
mostradas as ferramentas de automatização de construção como o Gradle e
Jenkins.
Acompanhe com atenção e bons estudos!

3.1 Padrões de projeto

Vamos começar entendendo que padrão de projeto é uma solução reutilizável, ou
seja, um modelo e não uma solução implantada. Com o crescimento das aplicações
móveis, e da concorrência entre eles, a busca por qualidade, manutenibilidade e
clareza do código, se tornou essencial. Segundo Barbosa (2013, p. 11) “é preciso
aplicar padrões de projeto para programação de aplicativos para esses
dispositivos, seja eles: Symbian, iOS (sistema operacional da Apple), Android ou
Windows Phone”.
Mas, como é possível adotar padrões de projeto para aplicativos móveis? Quais os
padrões disponíveis? Como utilizar os padrões de projeto para dispositivos móveis?
Eles são utilizados por muitas empresas que buscam implantar novos projetos de
so ware ou melhorar os antigos. Um padrão de projeto pode ser implantado em
qualquer linguagem ou plataforma de desenvolvimento.

3.1.1 Databinding
O Android oferece suporte para escrever layouts declarativos, usando o
Databinding, também, chamado de vinculação de dados. Databinding permite
sincronizar a interface de usuário com o modelo de aplicativo e a lógica. Para Lee
(et al., 2005), isso minimiza o código necessário do aplicativo para se conectar aos
elementos da interface do usuário.
O uso de Databinding requer alterações nos arquivos de layout. Eles iniciam com
uma tarefa raiz, seguido de um elemento data e um elemento de visão. Os
elementos de dados descrevem os dados que estão disponíveis para ligação. O
elemento de visão contém sua hierarquia semelhante aos arquivos de layout, que
não são usados com Databinding.
As referências aos elementos de dados ou expressões dentro do layout são gravadas
nas propriedades do atributo usando o @{}ou @={}. Na figura a seguir, é
demonstrada a estrutura de vinculação de dados no Databinding.

Figura 1 - Modelo de Databinding do sistema operacional Android, indicando os módulos e suas

correlações. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta três quadros, um do lado do outro. O primeiro é: Destino

da ligação de dados e dentro dele tem um quadrado cinza claro escrito:
Propriedades dependentes. O terceiro é: Fonte de dados e dentro dele tem um
quadrado cinza claro escrito: Propriedades. O segundo é: Objetos de vinculação e
abaixo tem ligação direta com a seta apontando do terceiro quadro para o primeiro;
embaixo tem Ligação dupla com seta de via dupla entre o primeiro e o terceiro
quadro; embaixo tem ligação inversa com a seta apontando do primeiro para o
terceiro quadro; embaixo tem Sentido único com a seta apontando do terceiro para
o primeiro quadro.

A Databinding do Android gera uma classe “Binding”, com base nesse layout. Esta
classe contém todas as ligações das propriedades de layout, isto é, a variável
definida para as visualizações correspondentes. Ele também fornece as classes
“setters” geradas para seus elementos de dados, a partir do layout. O nome da
classe gerada é baseado no nome do arquivo de layout. Este nome é convertido e é
adicionado a ele. Por exemplo, se o arquivo de layout for chamado
activity_main.xml(), o método generate() será chamada ActivityMainBinding, sendo
possível incrementar o layout e conectar o modelo por meio dessa classe.
Portanto, a vinculação de dados é construída com a ideia de usar dados de um
objeto Java para definir atributos em seus layouts, e essa é a medida em que é
muito utilizado. Isto permite que se defina a lógica de visualização
independentemente do Android Framework.

3.1.2 Aplicabilidade da arquitetura MVP ou MVVM

O padrão MVP (Model-View-Presenter) é um derivativo do conhecido MVC
(ModelView-Controller), que tem sido importante para o desenvolvimento de
aplicativos Android. O padrão MVP permite separar a camada de apresentação da
camada lógica, de modo que as informações sobre como a interface funciona são
separadas de como será representada a tela. Inicialmente, o padrão MVP teria essa
mesma lógica, podendo ter visões completamente diferentes e intercambiáveis.

VOCÊ SABIA?
Os aplicativos móveis, que incluem calendários, navegadores e mapas interativos,
fazem parte da vida da maioria das pessoas hoje em dia. A maioria dos aplicativos
móveis é de usuário único; e eles não permitem a colaboração síncrona entre os
usuários. A colaboração móvel permite que vários usuários em diversos locais
combinem sinergicamente suas contribuições de maneira conveniente.

Os pesquisadores Pichiliani e Hirata (2014) investigaram o potencial de criar

aplicativos colaborativos com base em aplicativos móveis de usuário único. Neste
trabalho foi proposta uma técnica de adaptação, baseada na reutilização de SDKs
(So ware Development Kits) de fabricantes para criar aplicativos protótipos
multiusuários. Leia mais em <https://
(https://link.springer.com/article/10.1007/s11036-014-0512-0)link
(https://link.springer.com/article/10.1007/s11036-014-0512-
0).springer.com/article/10.1007/s11036-014-0512-0
(https://link.springer.com/article/10.1007/s11036-014-0512-0)>.
É fundamental esclarecer que o MVP não é um padrão de arquitetura, ele é
responsável apenas pela camada de apresentação. Mas, como recomendam Deitel,
Deitel e Wald (2016), é sempre melhor usá-lo para sua arquitetura, que não o usar
de forma alguma. No Android, temos um problema decorrente do fato de as
atividades do Android serem intimamente associadas aos mecanismos de acesso à
interface e aos dados. Podemos encontrar exemplos extremos como o componente
CursorAdapter, que combina adaptadores, que são parte da visão, com cursores,
algo que deve ser relegado às profundezas da camada de acesso a dados. A seguir
é demonstrado o modelo MVP:

Figura 2 - Modelo MVP do sistema operacional Android, indicando os módulos e suas correlações. Fonte:
Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta três quadros, um no topo e dois embaixo um do lado do

outro. O primeiro no topo é o quadro Modelo: - Estado das aplicações
encapsuladas; - Resposta aos estados das pesquisas; - Mostra as funcionalidades
da aplicação. O quadro abaixo e a esquerda é o quadro Visão: - Processamento do
modelo; - Pedido de alteração do modelo; -Envia ações do usuário ao controlador.
Do lado deste é o quadro Apresentação: - Define o comportamento da aplicação;
Mapeia as ações da alteração do modelo. O quadro Apresentação se conecta ao
quadro Modelo com uma seta e escrita: Alteração de estado. O quadro
apresentação se conecta ao quadro Visão com uma seta escrita: Seleção da visão.
O quadro visão se conecta ao quadro Apresentação com uma seta pontilhada e
escrita: Solicitação do usuário.

Para que uma aplicação seja facilmente extensível e sustentável, é necessário

definir camadas separadas. O que faremos se, em vez de recuperar os mesmos
dados de um banco de dados, precisarmos fazer isso de um serviço da web?
Seria preciso refazer toda a parte de apresentação do aplicativo, denominada visão
pelo MVP. O MVP torna as visualizações independentes da fonte de dados. O
aplicativo é dividido em, pelo menos, três camadas diferentes, o que permite testá-
las independentemente. Com o MVP, pode-se tirar a maior parte da lógica das
atividades para que possa testá-la sem usar testes de instrumentação.
Existem muitas variações do MVP e todas podem ajustar a ideia do padrão às
necessidades de desenvolvimento de cada aplicativo. O modelo varia dependendo
basicamente da quantidade de funcionalidades do aplicativo. A visão é responsável
por habilitar ou desabilitar uma barra de progresso, ou deveria ser feita pelo
módulo apresentador? E qual módulo decide quais ações devem ser mostradas na
barra de ação?
Por outro lado, temos o MVVM (Model-View-ViewModel). À primeira vista, o MVVM
parece semelhante ao padrão Model-View-Presenter, porque ambos fazem o
trabalho de abstrair o estado e o comportamento da visão.
O Modelo de Apresentação abstrai uma visualização independente de uma
plataforma específica de interface com o usuário, enquanto o padrão MVVM foi
criado para simplificar a programação orientada a eventos das interfaces com o
usuário. Na figura a seguir, é demonstrado o modelo MVVM.

Figura 3 - Representação do modelo MVVM (Model-View-ViewModel), mostrando a relação entre os

módulos e suas vinculações. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta três quadros laranjas, um do lado do outro. O primeiro é

o quadro Visão, embaixo dele está escrito Interface; o Segundo é o quadro
VisãoModelo, embaixo dele está escrito Apresentação lógica; o Terceiro é o quadro
Modelo, embaixo dele está escrito Modelo de negócio de dados. O primeiro e o
segundo quadro estão ligados através de uma seta dupla escrito: Vinculação de
dados e outra seta dupla escrito: Comandos. O segundo quadro está ligado ao
primeiro por uma seta escrito: Notificações. O segundo quadro está ligado ao
terceiro por uma seta e o terceiro quadro está ligado ao segundo por uma uma seta.

Se o padrão do MVP significava que o módulo de apresentação estava ligado

diretamente à visualização, demonstrando o que exibir, no MVVM, o ViewModel
expõe fluxos de eventos, aos quais, o módulo visão pode se associar. Assim, o
ViewModel não precisa mais manter uma referência ao módulo visão, como o
módulo de apresentação. Isso também significa que todas as interfaces que o
padrão MVP requer agora, são descartadas. As visões também notificam ao
ViewModel sobre diferentes ações. Portanto, o padrão MVVM suporta interação de
dados bidirecional entre View e ViewModel e há um relacionamento de “muitos
para um” entre View e ViewModel. View tem uma referência ao ViewModel, mas o
ViewModel não possui informações sobre o View.

3.1.3 Injeção de dependência pela ferramenta Dagger 2

Muitos aplicativos Android dependem da instanciação de objetos que, geralmente,
exigem outras dependências. Por exemplo, um cliente do aplicativo Twitter pode
ser criado usando uma biblioteca de rede, como o Retrofit. Para usar essa
biblioteca, talvez seja necessário adicionar bibliotecas de serialização, como o
Gson. Além disso, as classes que implantam a autenticação ou o armazenamento
em cache podem exigir o acesso a preferências compartilhadas ou outro
armazenamento comum, exigindo sua instanciação em primeiro e a criação de uma
cadeia de dependência.
Para esta situação, o Dagger 2 analisa as dependências e gera o código para ajudar
a conectá-las. Embora existam outras estruturas de injeção de dependência em
Java, muitas delas sofreram limitações ao depender de XML, ou exigiram a
validação de problemas de dependência em tempo de execução, ou ainda,
incorreram em penalidades de desempenho durante a inicialização. O Dagger 2
baseia-se puramente na utilização de processadores de anotação Java e
verificações em tempo de compilação para analisar e verificar dependências. É
considerado um dos frameworks de injeção de dependência mais eficientes
construídos (LEE et al., 2005).
Por fim, o Dagger 2 é um dos frameworks de código aberto que gera ainda muitas
dúvidas. Mas por que é melhor que os outros?
Atualmente, é a única estrutura que gera código-fonte totalmente rastreável em
Java, que imita o código que o usuário pode escrever à mão. Isso significa que não
há componente oculto na construção do gráfico de dependências. O Dagger 2 é
menos dinâmico do que os outros, mas a simplicidade e o desempenho do código
gerado estão no mesmo nível do código escrito à mão, tornando-o, portanto,
melhor que os outros.
O Dagger 2 analisa as dependências e gera o código para conectá-las. Embora
existam outras estruturas de injeção de dependência de Java, muitas delas
sofreram limitações ao depender de XML, exigiram a validação de problemas de
dependência em tempo de execução ou incorreram em penalidades de
desempenho durante a inicialização. O Dagger 2 baseia-se puramente na utilização
de processadores de anotação Java e verificações em tempo de compilação para
analisar e verificar dependências. É considerado um dos frameworks de injeção de
dependência mais eficientes construídos. O Dagger 2 simplifica o acesso a
instâncias compartilhadas, fornecendo uma maneira simples de obter referências
a estas instâncias. O Dagger 2 também oferece uma configuração fácil, como
também é mais fácil executar os testes de unidade e integração.

3.2 Testes e depuração

Para o processo de desenvolvimento de aplicativos para dispositivos móveis, uma
das fases mais importantes é a fase de teste de depuração. Isto garante a entrega
de aplicativos com o mínimo de erros e com boa qualidade. Como é possível realizar
testes e depuração de forma automatizada nos sistemas operacionais disponíveis
nos aplicativos móveis? Quais são as ferramentas disponíveis? Quais são os
procedimentos necessários?
Vamos ver a seguir, como é possível realizar testes e depuração em aplicativos
móveis.

3.2.1 Testes unitários pela ferramenta JUnit

JUnit é uma biblioteca de código aberto com o propósito de escrever e executar
casos de teste para programas Java e, também, para aplicativos que executam em
dispositivos móveis. No caso de programas Java, quando o foco são aplicações
web, o JUnit é usado para testar o aplicativo sem o servidor. Este framework
constrói uma relação entre desenvolvimento e processo de teste.
O teste unitário é um método de teste de so ware usado para testar unidades
individuais do código-fonte, para determinar se elas estão adequadas para uso. O
objetivo é escrever código para cada função ou método não trivial. Ele permite que
seja possível verificar, com relativa rapidez, se a última alteração no código causa
regressão, isto é, se novos erros aparecem na parte do programa que já foi testada
e facilita a identificação e a eliminação desses erros. Ou seja, os testes são métodos
que verificam a eficiência do seu código. Mas como exatamente isso tudo funciona?
O teste é considerado concluído se nenhum erro for encontrado. E para vários tipos
de verificações, são usados métodos suplementares.
Existem dois tipos de testes unitários no sistema operacional Android:

testes de unidade local: são executados usando apenas a JVM. Eles

servem para experimentar a lógica de negócios que não está interagindo
com o sistema operacional; testes de unidade instrumentados: são
usados para provar a lógica interconectada com a API do Android. Eles são
executados no dispositivo físico/emulador e, portanto, levam mais tempo
do que os testes locais.

A seguir, vamos listar as vantagens de se utilizar o JUnit. A primeira é o teste

automatizado:

a automação rápida executa casos de teste de forma significativamente

mais rápida do que recursos humanos;
menos investimento em recursos humanos: os casos de teste são
executados usando a ferramenta de automação, o que reduz a
quantidade de testes;
mais confiável: os testes de automação executam precisamente a
mesma operação, sempre que são executados; programável: os
testadores podem programar testes sofisticados para trazer informações
relevantes e diferentes.
O framework JUnit possui um conjunto de métodos básicos:

void assertEquals (esperado, atual) - verifica se os dois primitivos/

objetos, são iguais;
void assertTrue (condition) - verifica se uma condição é verdadeira;
void assertFalse (condition) - verifica se uma condição é falsa; void
assertNotNull (object) - verifica se um objeto não é nulo; void
assertNull (object) - verifica se um objeto é nulo;
void assertSame (esperado, atual) - testa se duas referências de objeto
apontam para o mesmo objeto;
void assertNotSame (inesperado, real) - testa se duas referências
de objetos não apontam para o mesmo objeto; void
assertArrayEquals (expectedArray, actualArray) - testa se dois vetores
são iguais entre si.

Assim, percebemos que os testes realizados pela ferramenta JUnit permitem

detectar uma série de possíveis erros de código do aplicativo, de forma
automatizada e confiável.

3.2.2 Analisar testes de interface do usuário com as ferramentas

Espresso e Robotium
O Robotium é uma extensão da estrutura de teste do Android e foi criado para
facilitar a criação de testes de interface do usuário para aplicativos Android. Os
testes permitem que se definam casos de teste nas atividades do Android. Na figura
a seguir, podemos ver a hierarquia de funcionalidades do Robotium.
Figura 4 - Vantagens hierarquizadas do Robotium no sistema operacional Android. Fonte: Elaborado pelo
autor, 2018.

#PraCegoVer: Apresenta uma pirâmide hierárquica de cor laranja,composta por 5

níveis. No topo está escrito: Alta performace; no nível abaixo está escrito: Maior
cobertura de testes; no nível abaixo está escrito: Integração de multiplas atividades;
no nível abaixo está escrito: Integração com IDE; no nível abaixo (último nível - base
da pirâmide) está escrito: Testes de casos simples.

O Robotium se baseia nas principais bibliotecas de testes de integração do Android,

mas fornece uma camada "extra" no topo para facilitar o teste com o Solodriver. O
Solodrive permite definir valores em campos de entrada, clicar nos botões e obter
resultados de outros componentes da interface do usuário. Os métodos da classe
JUnits Assert podem ser usados para verificar esses resultados. Portanto, o objeto
Solo pode ser usado nos métodos para obter e definir valores dos componentes da
interface do usuário.
O Espresso é uma biblioteca de teste de instrumentação, construída com o objetivo
de realizar testes de interface do usuário (parte da Biblioteca de suporte a testes do
Android), permitindo criar testes automatizados para seu aplicativo Android. Os
testes são executados em dispositivos ou emuladores reais (são testes baseados
em instrumentação) e se comportam como se um usuário real estivesse usando o
aplicativo (DEITEL; DEITEL; WALD, 2016).

VOCÊ SABIA?
No artigo dos pesquisadores Pinto e Araújo (2016), podemos acompanhar um estudo
de caso para testes automatizados com frameworks de código aberto em aplicativos
móveis em sistema operacional Android, no nível de unidade e interface de sistema.
O estudo demonstra uma análise crítica de cada ferramenta. Leia mais em
<https://seer.cesjf.br/index.php/cesi/article/view/922
(https://seer.cesjf.br/index.php/cesi/article/view/922)>.

Sendo uma ferramenta simples e extensível, o Espresso permite a sincronização

automática de ações de teste com a interface do usuário do aplicativo, fornecendo
as informações sobre falhas, tornando-se uma opção para testes de interface do
usuário. Para vários pesquisadores, como Deitel, Deitel e Wald (2016), o Espresso é
considerado um substituto completo do Robotium.
Por fim, no caso do Espresso, a API principal é reduzida e fácil de aprender, mas
permanece aberta para personalização. O Espresso testa as expectativas,
interações e afirmações do estado sem a interação de conteúdo, infraestrutura
personalizada ou detalhes complicados de implementação. Os testes do Expresso
são executados de forma otimizada e rápida. Ele permite que deixe as
sincronizações, pausas e pesquisas enquanto manipula e confirma a interface do
usuário do aplicativo, quando está parado.

3.2.3 Android Debug Bridge

O Android Debug Bridge (ADB) é um programa cliente-servidor usado no
desenvolvimento de aplicativos Android. O Android Debug Bridge faz parte do
Android SDK e é composto de três componentes: um cliente, um daemon e um
servidor. Ele é usado para gerenciar uma instância de emulador ou um dispositivo
Android real.
Além do Android SDK, do qual a depuração do Android faz parte, os requisitos
básicos de uma configuração de desenvolvimento do Android são um computador
que cumpre os requisitos mínimos do sistema para executar o Android SDK e, na
maioria dos casos, um dispositivo Android. Na linguagem de desenvolvimento de
so ware, o computador mencionado é conhecido como a máquina de
desenvolvimento. O componente cliente do Android Debug Bridge é executado na
máquina de desenvolvimento. Ele pode ser chamado a partir do prompt de
comando, usando o comando adb. Há também outras ferramentas que podem criar
clientes adb, como o plug-in ADT (Android Development Tools) e o DDMS (Dalvik
Debug Monitor Service). O daemon ADB, por outro lado, é executado como um
processo de segundo plano em uma instância de emulador ou no próprio
dispositivo. Na figura a seguir, podemos visualizar a estrutura do Android Debug
Bridge.

Figura 5 - Estrutura e componentes do Android Debug Bridge do sistema operacional Android. Fonte:
Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta um quadro laranja à esquerda escrito: Modelo: - Cliente,

Servidor; Componentes: - Cliente, - Servidor, - Processo em segundo plano;
Comandos: - Shell, - Logeat, - Instalação. A direira em cinza tem um quadro central
escrito Servidor e conectado à ele sai uma linha horizontal à esquerda que que liga
a uma linha vertical ligando-o a no topo um cículo cinza escrito Cliente 1, ligando
no meio a um cilindro cinza claro escrito ADB, ligando abaixo a um círculo cinza
escrito Cliente 2. O quadro central Servidor também é conectado por uma linha
horizontal à direita que liga a uma linha vertical ligando-o a no topo um quadro
cinza escrito Processo em segundo plano 1, ligando no meio a um quadro cinza
escrito Processo em segundo plano 2, ligando abaixo a um quadro cinza escrito
Processo em segundo plano 3.

Finalmente, o componente servidor do ADB, que também é executado na máquina

de desenvolvimento, mas apenas em segundo plano, se encarrega de gerenciar a
comunicação entre o cliente ADB e o daemon ADB. Quando o Android Debug Bridge
está ativo, o usuário pode emitir comandos adb, para interagir com uma ou mais
instâncias do emulador.
O adb também pode executar várias instâncias do cliente adb, que podem ser
usadas para controlar todas as instâncias de emuladores existentes. Uma forma de
se usar o Android Debug Bridge é instalar o plug-in do ADT no IDE do Eclipse
(Integrated Development Environment). Dessa forma, o desenvolvedor não
precisaria inserir comandos por meio do prompt de comando. O usuário pode emitir
comandos adb para interagir com uma ou mais instâncias de emulador.

3.3 Análise de performance

O nível de eficiência de um aplicativo está relacionado ao uso dos recursos de forma
eficaz, à sua confiabilidade e ao nível de manutenibilidade do código. Podese
considerar que estas variáveis estão relacionadas ao requisito de performance de
um aplicativo. Isto significa a relação que existe, entre o tempo gasto para
processar as funções, e a quantidade de processamentos realizados para executar
o so ware.
Essas características não são percebidas pelos usuários de forma direta, mas o
resultado final do uso do sistema será percebido como um todo, sendo mais ou
menos eficiente. Nos aplicativos de dispositivos móveis, este requisito é ainda mais
crítico, devido às limitações de processamento e memória (DEITEL; DEITEL;
WALD, 2016).
 VOCÊ QUER LER?
No artigo escrito por Zhao (et al., 2016), foi proposta uma nova solução de serviço de middleware que
supera as desvantagens do uso da abordagem pré-cache, a tecnologia PrecAche do sistema Android. O
método proposto usa HTML para projetar a interface do aplicativo e armazenar separadamente o Page
Framework e o Page Data. O artigo mostra como foi criado um novo middleware de páginas da web, o
Version Flags, para indicar se o PF e o PD estão vencidos. Os resultados experimentais representam que
a abordagem proposta pode melhorar a eficiência de execução, bem como reduzir os custos de rede,
que podem ser amplamente utilizados em sistemas distribuídos, baseados em nuvem. Leia o artigo
completo em: < https://www.sciencedirect.com/science/article/pii/S0167739X15001806
(https://www.sciencedirect.com/science/article/pii/S0167739X15001806)>.

Considerando isso tudo, como é possível executar a análise de desempenho de

aplicativos de dispositivos móveis? Como são realizadas tais análises? Quais as
ferramentas disponíveis?
Nos dispositivos móveis, requisitos como eficiência do código são um ponto
fundamental que merece tratamento diferenciado. Isto se deve ao fato de que
conexões com componentes externos, como banco de dados e aplicativos externos
executados em background, mudam de comportamento e eficiência, dependendo
do dispositivo móvel no qual o aplicativo está instalado.

3.3.1 Identificação de gargalos de performance por meio de

ferramentas de análise
Inicialmente, um dos principais gargalos de um aplicativo é o tempo de inicialização
do aplicativo, de acordo com Deitel, Deitel e Wald (2016), sendo uma métrica crítica
que todo desenvolvedor deve monitorar com cuidado. Existe uma série de
limitações nos dispositivos móveis, como a capacidade de armazenamento ou
processamento limitado. Neste sentido, a conectividade entre dispositivos pode
ser uma alternativa para estas limitações, podendo serem empregadas tecnologias
de comunicação como HTTP, Socket TCP, Socket UDP e WebService, outras
exclusivas do mundo móvel, como SMS e MMS.
O que ocorre é que um longo tempo de inicialização criará muito atrito entre o
usuário e sua utilização do aplicativo. Isso é particularmente verdadeiro, quando se
trata de aplicativos que devem ser usados rapidamente. Por exemplo, um usuário
acessaria regularmente um aplicativo de transporte público se precisar de 15
segundos cada vez que quiser usá-lo?
Existem alguns aplicativos que oferecem funcionalidades para este tipo de serviço,
vamos listar a seguir.

Nimbledroid é um serviço gratuito dedicado para medir a duração de

inicialização do aplicativo Android. O principal valor agregado deste
serviço é a medida do tempo de inicialização em um dispositivo real e
seu monitoramento a médio / longo prazo.
O AndroidDevMetrics é uma ferramenta incorporável diretamente no
seu aplicativo (a versão de depuração). Ele fornecerá várias informações
relacionadas ao desempenho, como: tempo de execução dos métodos
do ciclo de vida da atividade, duração da instanciação do objeto Dagger
2.

No quadro a seguir, podemos entender as vantagens e desvantagens do

AndroidDevMetrics.

Figura 6 - Vantagens e desvantagens da ferramenta de análise AndroidDevMetrics do sistema operacional

Android. Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta uma tabela onde a primeira linha é laranja e está escrito
no meio da linha: AndroidDevMetries, embaixo dessa linha tem-se duas colunas
uma encostada na outra. Na primeira coluna está escrito Vantagens: -Fácil
integração, - Existência de métricas para várias atividades. Na segunda coluna está
escrito desvantagens: - Métricas somente para poucos métodos, - Não há
mecanismo de armazenamento das métricas.
Agora, vamos ver quais as ferramentas que tratam da otimização do desempenho
da interface do usuário de um aplicativo, e como são utilizadas.
Existem muitas ferramentas que podem ajudar na identificação de problemas de
interface do usuário e fornecer informações sobre os motivos do problema de
desempenho.

Visualizador overdraw: Esta ferramenta está disponível diretamente nas

"opções do desenvolvedor" do dispositivo Android. É necessário apenas
habilitar o campo "Debug GPU overdraw". Serão exibidas muitas cores
sobrepostas na tela. Cada uma dessas cores informa quantas vezes a
área correspondente foi retirada pela GPU. Uma cor transparente/ azul/
verde, corresponde a um baixo número de overdraw (respectivamente 0,
1 e 2), uma cor vermelha corresponde a um número de overdraw “alto”
(3 ou 4).
Traceview: quando é necessário fazer uma análise mais avançada, como
por exemplo, fornecendo representações gráficas de logs de rastreio. É
possível gerar os registros, instrumentando o código com a
Debugclasse. Esse método de rastreamento é muito preciso, porque é
possível especificar exatamente onde, no código, se deseja iniciar e
parar o registro de dados de rastreamento. O Traceview faz parte do
conjunto de ferramentas do Monitor de dispositivos Android fornecido
pelo Android Studio.
Logcat: pode parecer ser a ferramenta mais rudimentar, mas os
resultados de logcats às vezes podem ser úteis para ter uma breve ideia
de eventuais problemas de desempenho no aplicativo. O monitor do
logcat tem como objetivo exibir as mensagens de alerta em tempo real,
como, por exemplo, limpeza de memória. É possível criar filtros
determinando quais informações devem ser exibidas, os níveis de
prioridade e a busca pelo registro. O monitor exibe somente a saída de
registro referente à execução mais recente do aplicativo. Quando um
aplicativo aciona uma exceção, o monitor do logcat exibe uma
mensagem, após o rastreamento de pilha, de que contém links para o
código. Esse recurso auxilia na correção de erros e melhora o
funcionamento do aplicativo.
Portanto, é fundamental identificar os gargalos e a análise de desempenho dos
aplicativos, pois um alto tempo de resposta, pode prejudicar o desempenho do
aplicativo. Como, por exemplo, tem-se o Traceview como um visualizador gráfico
para logs de execução que se cria usando a Debugclasse para registrar informações
de rastreamento do código. O Traceview pode ajudar a depurar seu aplicativo e a
analisar seu desempenho. Quando tiver um arquivo de log de rastreio (gerado ao
incluir código de rastreio no aplicativo), poderá fazer com que Traceview carregue
os arquivos de log e exiba os dados em uma janela para visualizar seu aplicativo em
dois painéis: um painel de cronograma – que descreve quando cada thread e
método foi iniciado e interrompido –, e um painel de perfil – que fornece um resumo
do que aconteceu dentro de um método.

3.3.2 Memória e otimização da performance

A memória de acesso aleatório (RAM) é um recurso importante em qualquer
ambiente de desenvolvimento de so ware, mas é ainda mais valiosa em um sistema
operacional móvel, no qual a memória física é frequentemente restrita. Embora o
Android Runtime (ART) e a máquina virtual Dalvik executem a coleta de lixo de
rotina, isso não significa que se possa ignorar quando e onde seu aplicativo aloca e
libera memória. É necessário, ainda, evitar a introdução de vazamentos de
memória, geralmente causados por manter referências de objetos em variáveis de
membros estáticos e liberar quaisquer referências no momento apropriado,
conforme definido por retornos de chamada de ciclo de vida.
Os dispositivos Android têm menos energia que os desktops ou notebooks padrão.
Especialmente em dispositivos anteriores ao Android 5.0, é necessário evitar o
acionamento do coletor de lixo da Java Virtual Machine. Isso resulta em um
congelamento do tempo de execução do Android por cerca de 200 ms. Este pode
ser um atraso notável, se o usuário estiver, por exemplo, rolando uma lista.
Deve-se evitar a criação de objetos desnecessários, sendo aconselhável reutilizar os
objetos, por exemplo, evitando criar objetos em loops ou no onDraw(), que é o
método de exibição personalizada.
Por outro lado, o Android fornece estruturas de dados que são mais eficientes para
mapear valores para outros objetos. Outro fator importante de otimização é
quando não é necessário acessar os campos de um objeto, o melhor é torná-lo um
método estático. As invocações serão cerca de 15% a 20% mais rápidas. Uma
observação importante sobre a otimização é usar a sintaxe aprimorada do loop
“for”. O “for” loop aprimorado (também conhecido como loop "for-each") pode ser
usado para coleções que implementam a “Iterable” interface e para matrizes. Um
iterador é alocado para fazer chamadas de interface para hasNext() e next(). Com
um ArrayList, um loop contado escrito à mão é cerca de três vezes mais rápido, mas
para outras coleções a sintaxe aprimorada do loop for será exatamente equivalente
ao uso explícito do iterador.

3.4 Ferramentas de automatização de

builds
O conceito fundamental de um build significa que as tarefas de compilação,
empacotamento e testes (sejam unitários ou de interface), as coletas de métricas,
validações de código e a verificação de dependências, como também a geração de
relatórios e documentação são realizadas como um processo, que poderia ser
melhorado se fosse realizado de forma automática. Isto torna a tarefa de
desenvolvimento mais ágil e com menor índice de erro. Como é possível fazer a
automatização de builds em aplicativos móveis? Quais são as ferramentas
disponíveis? Como executar o build no sistema operacional Android? Estas
questões serão discutidas a seguir.

3.4.1 Processo de building do Android com o Gradle

O sistema de criação do Android Studio é baseado no Gradle, e o plug-in do Android
para o Gradle adiciona vários recursos específicos para a criação de aplicativos para
Android. Embora o plug-in do Android seja normalmente atualizado na etapa de
bloqueio com o Android Studio, o plug-in (e o restante do sistema Gradle) pode ser
executado independentemente do Android Studio e ser atualizado separadamente.

VOCÊ QUER VER?

Na palestra de Felipe Lima (So ware Engineer da Airbnb), você pode conhecer a evolução do
desenvolvimento Android no serviço Airbnb. A palestra foi proferida na Conferência Android Dev de
2017. Para assistir acesse <https://www.youtube.com/watch?v=StyOQUWPClE
(https://www.youtube.com/watch?v=StyOQUWPClE)>.
O Gradle é disponibilizado pelo sistema operacional Android. Ele tem a função de
automatizar o processamento de build de forma avançada. Ele une a flexibilidade
do Ant e executa o processamento de dependências do Maven. O Android ANT SDK
permite que os desenvolvedores conectem aplicativos Android a dispositivos ANT.
Ele é fornecido para permitir que você se conecte a dispositivos proprietários e
construa topologias complexas utilizando recursos ANT avançados, como a
varredura em segundo plano e aplicativos de telefone celular. Portanto, permite
que os aplicativos se estendam a todos os fornecedores de smartphones sem
fragmentação nas versões do Android.
Já O Plug-in do Android Maven é usado para criar aplicativos para o sistema
operacional Android, podendo criar bibliotecas para serem usadas no formato
legado APKLIB usando o Apache Maven. Enquanto os formatos de construção do
Maven utilizam arquivos XML para a configuração do build, os arquivos de build do
Gradle são escritos na linguagem Groovy. Neste sentido, pelo fato de serem
baseados em script, os arquivos do Gradle permitem que nos arquivos de
configuração sejam desenvolvidas tarefas de programação. Além disto, o Gradle
tem um sistema de plug-ins que fazem a adição de novas funcionalidades.

3.4.2 Processo de building automatizado com o Jenkins

Jenkins é um servidor ou ferramenta de Integração Contínua (CI) que é escrito em
Java. Ele fornece serviços de Integração Contínua para desenvolvimento de so
ware, que podem ser iniciados via linha de comando ou servidor de aplicativos da
web.
O Jenkins suporta a criação e teste automáticos de aplicativos Android. Para criar
um trabalho de construção no Jenkins, é necessário ter uma configuração de
construção funcional. O conjunto de ferramentas do Android gera
automaticamente um arquivo de criação Gradle válido, que pode ser usado no
Jenkins.

VOCÊ O CONHECE?
O criador do Java, James Gosling, quando adolescente, teve a ideia de criar um pequeno intérprete para
resolver um problema em um projeto de análise de dados em que estava trabalhando na época. Ao longo
dos anos, como aluno de pós-graduação e na Sun, como criador de Java e da Java Virtual
Machine, ele usou variações dessa solução. Leia mais sobre o criador do Java no artigo escrito por
Allman (2004), disponível em <https://queue.acm.org/detail.cfm?id=1017013
(https://queue.acm.org/detail.cfm?id=1017013)>.

Na prática de Integração Contínua (CI), os desenvolvedores devem integrar o

código em repositório, para compartilhamento constante.
É o processo de executar os testes em uma máquina que não seja a do
desenvolvedor, automaticamente, quando é enviado um novo código para o
repositório de origem. Na figura a seguir é mostrada a Integração Contínua no
sistema operacional Android.

Figura 7 - Estrutura da Integração Contínua do processo automatizado utilizando a ferramenta Jenkins.

Fonte: Elaborado pelo autor, 2018.

#PraCegoVer: Apresenta uma estrutura dividida em duas partes em formato de

retangulo na horizontal um em cima e um embaixo. O primeiro retângulo (em cima)
é a Integração Contínua, dentro dele começa com uma seta apontada para frente
para um quadro laranja escrito Integração, em seguida uma seta apontada para
frente para um quadro laranja escrito Construção, em seguida uma seta apontada
para frente para um quadro laranja escrito Tests, em seguida uma seta apontada
para frente para um quadro laranja escrito Controle de Qualidade, em seguida uma
seta apontada para frente para um quadro laranja escrito Distribuição. Do quadro
distribuição sai uma seta que aponta para o início do retângulo embaixo, esse
retângulo é chamado de Entrega contínua e dentro dele tem-se o quadro laranja
escrito Validação e em seguida uma seta apontada para frente para um quadro
laranja escrito Publicação e em seguida uma seta cinza aponta para frente até o
final deste retêngulo.

Nesse tipo de procedimento, há uma enorme vantagem de saber se todos os

trabalhos (projeto configurado no Jenkins) funcionam corretamente ou não. E
também é possível obter feedback rápido. O feedback rápido é muito importante,
assim sempre saberá, logo depois de ter sido interrompida ou finalizada a
compilação. No console serão recebidas as mensagens de log detalhadas. A partir
disso, se saberá qual foi a razão da falha no trabalho e também poderá saber como
pode reverter isso.

CASO
O mercado consumidor está cada vez mais exigente com relação aos aplicativos para
dispositivos móveis e suas funcionalidades e, para não perder oportunidades, as
empresas devem estar atentas para o que o público espera, a fim de atender a essas
demandas. Um grande escritório de advocacia percebeu um nicho de utilização de
aplicativos: a capacidade de realizar as sessões de conciliação de processos
virtualmente. Para isto, a empresa solicitou o desenvolvimento de um aplicativo que
permite que as partes envolvidas no processo, possam fazer uma videoconferência,
utilizando o aplicativo no dispositivo móvel. Isto agiliza as decisões, as torna mais
eficientes e reduz custos de deslocamento para as partes envolvidas e os advogados.
Quando se faz as alterações manualmente, é mais complexo analisar o impacto das
alterações no código. Por isso, será difícil descobrir quais alterações introduziram
o problema. Mas quando o Jenkins é configurado para rodar automaticamente em
cada envio de código para o repositório, é sempre fácil saber o que e, quem,
introduziu o problema (DEITEL, DEITEL; WALD, 2016). Na lista a seguir, podemos ver
algumas das razões pelas quais é preciso automatizar o teste e as integrações de
build.
 O tempo do desenvolvedor é concentrado no trabalho que importa:
a maior parte do trabalho, como integração e teste, é gerenciada por
sistemas automatizados de criação e teste.
A qualidade do so ware é aprimorada: os problemas são detectados e
resolvidos quase imediatamente, o que mantém o so ware em um
estado em que ele pode ser liberado a qualquer momento com
segurança.
Torna o desenvolvimento mais rápido: a maior parte do trabalho de
integração é automatizada. Por isso, os problemas de integração são
menores. Isso economiza tempo e dinheiro ao longo da vida útil de um
projeto.

O Sistema de Construção Contínua pode incluir ferramentas como Jenkins,

Bamboo ou Cruise Control. O Bamboo tem melhor suporte a interface do usuário,
mas não é uma ferramenta gratuita. O Jenkins é uma ferramenta de código aberto,
mais fácil de configurar e também possui uma comunidade de desenvolvimento de
plug-ins muito ativa, que o torna favorecido. Vantagens do Jenkins:

Jenkins é uma ferramenta de código aberto com muito apoio de sua

comunidade;
a instalação é mais fácil;
tem mais de 1000 plug-ins para facilitar o trabalho; é fácil criar um novo
plug-in Jenkins, se não houver um disponível; é uma ferramenta que
está escrita em Java. Por isso, pode ser portável para quase todas as
principais plataformas.

Portanto, existem ferramentas muito interessantes para tornar o processo de

desenvolvimento e implantação de aplicativos de forma automatizada, tornando o
trabalho mais profissional, com melhores recursos e bom nível de produto final.
Síntese
Aprendemos aqui, como desenvolver aplicativos com qualidade para dispositivos
móveis no sistema operacional Android. É muito importante para os
desenvolvedores utilizarem padrões de projeto específicos para aplicativos em
dispositivos móveis, como o MVC e MVVM, pois estes padrões garantem a eficiência
da arquitetura do so ware. É também muito relevante saber utilizar os testes,
depuração e a análise de desempenho, juntamente com a criação automática de
códigos, pois estas atividades mantêm o nível de qualidade dos aplicativos. Neste
capítulo, você teve a oportunidade de:
utilizar os padrões de projeto por meio do Databinding, arquitetura MVP
e MVVM e Dagger 2.
aplicar os testes e depuração por meio de testes unitários utilizando
ferramentas JUnit, Robotium e Espresso.
identificar os gargalos de desempenho utilizando ferramentas de análise
e otimização de desempenho.
utilizar ferramentas de automatização para desenvolver aplicativos mais
eficientes por meio das ferramentas Gradle e Jenkins.

Projeto

FERRAMENTAS DE AUTOMAÇÃO

Um projeto de software é um projeto ‘não concluído’. Esse fato é justificado nas

constantes evoluções que resultam em manutenções do sistema ao longo de sua
existência. Isso ocorre devido a evolução constante, as necessidades do clientes e a
melhoria de sua qualidade.

No desenvolvimento de uma aplicação móvel, a arquitetura de software é um ponto

crítico. A preocupação da arquitetura de software é com a organização estrutural
dos componentes gerais do sistema. Entre as fases no processo de desenvolvimento
de um sistema voltada a dispositivos móveis, na parte inicial está o projeto de
arquitetura de software. Com a evolução da tecnologia e o surgimento de novas
plataformas de desenvolvimento, como as plataformas web e mobile, novas
necessidades de arquitetura surgiram. Dentre as novas arquiteturas está o modelo
MVC. O acrônimo MVC faz referência a Model (M), View (V) e Controller ©, conforme
a Figura 3.1.
Figura 3.1 - Modelo MVC

Os objetivos dos padrões são impor uma estrutura geral para um sistema de
software ou subsistema que é apropriado para o problema que o sistema ou
subsistema está resolvendo; esclarecer as intenções do designer sobre a
organização do sistema ou subsistema; fornecer um paradigma que ajudará a
estabelecer e manter a consistência interna; permitir a verificação e análise
apropriadas; preservar informações sobre a estrutura para referência durante
posterior manutenção (SHAW, 1996).

O modelo de arquitetura MVC possui uma dinâmica simples, todas as requisições da

aplicação são direcionadas para a camada Controller, que acessa a camada Model
para processar a requisição e, por fim, exibe o resultado da camada View. Esse
padrão separa as camadas de apresentação, lógica, negócio e gerenciamento do
fluxo da aplicação, aumentando as capacidades de reutilização e de manutenção do
projeto (LUCIANO; ALVES, 2011).

A camada Model representa o modelo de dados armazenados que serão

visualizados pelo usuário por meio da camada View. As operações CRUD (create,
read, update, delete) são executadas nessa camada.

Já a camada View representa as telas da aplicação. Nessa camada, os usuários

podem interagir com a aplicação e visualizar os dados manipulados pelo sistema.
Podemos dizer que a camada View é a apresentação da aplicação.

Por fim, a camada Controller é responsável pelo gerenciamento de todo o fluxo da

aplicação. Ela faz a comunicação lógica entre a camada Model e View.

A arquitetura de software modelo MVC é utilizada em padrões de projeto de

software, mas esse modelo envolve mais da arquitetura de uma aplicação do
qualquer modelo típico utilizado para um projeto (LAMIM, 2012). Dessa forma, o uso
de um padrão descreve como o sistema está organizado em um conjunto de
componentes de comunicação.

Vamos Praticar
Convidamos você a pensar, analisar e descrever a importância do uso de um
framework no desenvolvimento de um sistema para dispositivos móveis.
Reforçamos a necessidade do planejamento do projeto na definição adequada da
arquitetura de software. Compartilhe no fórum da disciplina o seu ponto de vista
por meio de texto de aproximadamente 15 linhas. Problematizando a importância
do uso do modelo, explore as vantagens do uso do padrão escolhido, mas também
pontue seus pontos negativos. Lembre-se que há outros padrões de arquitetura,
por exemplo, o modelo em camadas.
 COMPUTAÇÃO PARA
DISPOSITIVOS MÓVEIS
CAPÍTULO 4 - COMO APRIMORAR
NOSSO APLICATIVO COM AS APIS DA
GOOGLE?
Fernando Skackauskas Dias

INICIAR

Introdução
É notório o grande avanço dos aplicativos nos dispositivos móveis, as novas
funcionalidades, a usabilidade e capacidade de comunicação e interação com
outros dispositivos e componentes. As tecnologias de geolocalização e
mapeamento estão levando à criação de aplicativos que atendem às necessidades
de diversas empresas e usuários, que, há poucos anos, eram inimagináveis. Nesse
contexto, os serviços em nuvem também estão cada vez mais presentes no dia a
dia. O Android tem inserido, dentre as suas possibilidades, a interação com os
serviços cloud, como a execução de backup e serviços de mensagens por meio de
APIs. E como a API trabalha? Por que as APIs são tão importantes para os
desenvolvedores?
Uma API (Application Programming Interface, ou, em português, Interface de
Programação de Aplicativos) trata do conjunto de aplicações que permitem a
construção de uma interface inteligente. Ou seja, a API é o motor dos aplicativos,
pois ela é quem faz a ligação de todos os recursos necessários para que um so ware
funcione de forma correta para o usuário. A empresa Google oferece várias APIs,
sendo que um dos principais destaques é o Google Maps. Este é um serviço gratuito,
que pode ser utilizado em qualquer aplicativo de dispositivo móvel. Mas como
utilizar o Google Maps em aplicativos?
Neste capítulo, vamos entender como o Android utiliza a geolocalização e o
mapeamento, por meio do Google Maps. Estudaremos o Android e a utilização dos
serviços em nuvens, como o Android Data Backup, o Firebase e o Cloud, do Service
Manager, e as funcionalidades de sensores e toque. Por fim será demonstrada a
construção de um so ware para aplicativo, utilizando as funcionalidades do
Android.
Vamos estudar com atenção!

4.1 Geolocalização e mapas

A geolocalização é um conjunto integrado de hardware, so ware e processos, que
fornecem a localização baseada em coordenadas geográficas. A geolocalização
utiliza, de forma geral, o Sistema de Posicionamento Global (GPS). A posição
geográfica pode ser exibida em mapas virtuais e, dependendo do nível de
detalhamento das coordenadas, pode-se chegar até a um determinado endereço
completo.
Além do GPS, a geolocalização também pode ser identificada por meio de um
endereço IP, endereço de controle de acesso à mídia (MAC), sistemas de
radiofrequência (RF), dados EXIF (Exchangeable Image File Format) e outros
sistemas de posicionamento sem fio. Conforme explicado por Felipe e Dias (2014,
p. 2), “a latitude e longitude são disponíveis através da página via JavaScript, que
por sua vez, pode ser enviada a um servidor web e fazer coisas como encontrar
locais ao seu redor ou mostrar sua posição em um mapa”. Uma das grandes
utilidades da geolocalização é a capacidade de exibir, em tempo real, o
posicionamento geográfico em mapas digitais. Esta possibilidade tem sido
utilizada por vários aplicativos para controle de tráfego, auxílio para a locomoção
em vias públicas e diversas funcionalidades adicionais.
 VOCÊ QUER LER?
Um ramo da área de automação que tem crescido consideravelmente é a automação residencial. Com a
evolução tecnológica da eletrônica e da Realidade Virtual, a automação residencial tem se tornado mais
acessível, possibilitando conforto para uma maior quantidade de pessoas. Fernandes e Barbosa (2017)
desenvolveram um trabalho que tem como objetivo, apresentar o desenvolvimento de um sistema de
Automação Residencial e Realidade Virtual utilizando o dispositivo Myo, e também uma versão mobile
em Android, unindo as áreas da saúde, engenharia e tecnologia. Leia mais em
<http://www.enacomp.com.br/2017/docs/Anais_Enacomp2017.pdf
(http://www.enacomp.com.br/2017/docs/Anais_Enacomp2017.pdf)>.

Com as possibilidades que se abrem a partir da geolocalização, surgem muitos

questionamentos para motivar os trabalhos: como é possível utilizar as
funcionalidades de geolocalização em dispositivos móveis? Quais as ferramentas
de dispositivos móveis que auxiliam no desenvolvimento de aplicativos de
geolocalização e mapas? Como o sistema operacional Android fornece os
componentes para a geolocalização e mapeamento?
Para começar a responder essas questões, vamos fazer observações sobre o
Android. Deitel, Deitel e Wald (2016, p. 3) apontam que “uma vantagem de
desenvolver aplicativos Android é a sua fraqueza (ou grau de abertura) da
plataforma. O sistema operacional é de código-fonte aberto e gratuito”.
A seguir serão mostrados e analisados os componentes, classes e bibliotecas
disponíveis para a implantação de aplicativos em dispositivos móveis, com a
utilização da geolocalização e mapas interativos.

4.1.1 Location API

Os aplicativos baseados em localização e mapas oferecem uma experiência
atraente em dispositivos móveis. É possível criar esses recursos no seu aplicativo
usando as classes do android.location e a API do Google Maps para Android. O
componente central da estrutura de localização é o LocationManager do sistema,
que fornece APIs para determinar a localização e o porte do dispositivo subjacente
(se disponível).
Como com outros serviços do sistema, não se instancia um LocationManager
diretamente. Em vez disso, é solicitada uma instância do sistema chamando
getSystemService(). O método retorna um identificador para uma nova instância
LocationManager. Depois que o aplicativo obter um LocationManager, será possível
realizar:

consulta à lista de todas as instâncias do LocationProvider, para

determinar o último local do usuário conhecido;
registrar ou cancelar o registro de atualizações periódicas da
localização atual do usuário de um provedor de localização;
registrar ou cancelar o registro, para que um dado seja acionado se o
dispositivo estiver dentro de uma determinada proximidade
(especificada por raio em metros) de uma determinada
latitude/longitude.

O API do Google Maps, disponível para o sistema operacional Android, possibilita

incluir mapas aos aplicativos residentes no dispositivo. O API tem a capacidade de
interagir diretamente com os servidores do Google Maps, permitindo fazer o
download das informações de geolocalização, exibição de mapas virtuais e acesso
aos mapas por meio de toque. É possível, também, incluir marcadores e manipular
as visualizações específicas de uma determinada área do mapa.

VOCÊ SABIA?
Os deficientes visuais encontram enormes desafios no seu dia a dia, como a
limitação para perceber o entorno dos objetos e para aquisição de produtos. Para
promover a autonomia dos deficientes visuais, foi desenvolvida uma solução na área
de Engenharia Elétrica, para aparelhos Android, que orienta o usuário por meio da
tecnologia Near Field Communication. Leia mais no artigo escrito por Lamas e Souza
(2016):
<https://periodicos.ufsc.br/index.php/extensio/article/view/18070221.2016v13n24
p37
(https://periodicos.ufsc.br/index.php/extensio/article/view/18070221.2016v13n24p
37)>.
A API do Google Maps disponibiliza a classe principal MapView. Esta classe tem
como função exibir, em um determinado mapa, as coordenadas e dados oriundos
do Google Maps. É possível fazer o zoom no mapa virtual pelo toque, inclusive
interagindo com mapas adicionais, oferecendo os elementos de interface para o
usuário. O aplicativo também pode usar a classe MapView para controlar o mapa
de forma programática e desenhar várias sobreposições na parte superior do mapa.
Conforme demonstrado por Murukannaiah e Singh (2015), utilizando-se o MapView,
um lugar deriva seu significado do espaço físico, das atividades ou do contexto
social de um usuário. Dessa maneira, o local pode facilitar uma melhor experiência
do usuário em comparação com a representação tradicional de localização, que
são coordenadas espaciais.

VOCÊ O CONHECE?
Quando a Google comprou o Android, Nick Sears, cofundador, esperava o desenvolvimento de um
sistema operacional avançado, como, por exemplo, câmeras digitais. No entanto, houve uma grande
reviravolta com as tecnologias que vieram a seguir. Quer ler mais sobre o cofundador do Android? Leia
no artigo escrito por Moliane e Almeida (2016): <https://docplayer.com.br/54762841-Art-e-dalvik-
emdispositivos-android.html (https://docplayer.com.br/54762841-Art-e-dalvik-em-
dispositivosandroid.html)>.

As APIs do Google Maps para Android não estão incluídas na plataforma Android,
mas estão disponíveis em qualquer dispositivo com o Google Play Store,
executando o Android 2.2 ou superior, por meio dos serviços do Google Play.
Portanto, para integrar o Google Maps ao aplicativo, é necessário instalar as
bibliotecas do Google Play Services para o Android SDK.
4.1.2 Google Maps API
É possível para os desenvolvedores de aplicativos para dispositivos móveis
incorporarem as diversas funcionalidades disponíveis pelo Google Maps nas
páginas web ou obter informações do Google Maps. Isto torna o resultado do
aplicativo mais personalizado. Neste sentido, a Google oferece um conjunto de
interfaces de programação de aplicativos (APIs) desenvolvidas, que permitem a
comunicação com o Google Services e sua integração a outros serviços. Exemplos
disso incluem: pesquisa, Gmail, tradutor ou Google Maps. Aplicativos de terceiros
podem usar essas APIs para aproveitar ou ampliar a funcionalidade dos serviços
existentes.
As APIs fornecem funcionalidades como análise, aprendizado de máquina como um
serviço (a API de previsão) ou acesso a dados do usuário (quando a permissão para
ler os dados é fornecida). Outro exemplo importante é um mapa do Google
incorporado em um site, que pode ser obtido usando a API de mapas estáticos, a
API do Google Places ou a API do Google Earth.

VOCÊ QUER LER?

Veja como foi desenvolvida uma aplicação em Android, utilizando um sistema de localização geográfica,
para determinar pontos turísticos na cidade de Curitiba, a fim de facilitar o trânsito dos turistas (EGGEA,
2013). Leia mais em:
<http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/2484/1/CT_TECJAVMOV_I_2012_10.pdf
(http://repositorio.roca.utfpr.edu.br/jspui/bitstream/1/2484/1/CT_TECJAVMOV_I_2012_10.pdf)>.

O Google Apps Script é uma plataforma em JavaScript baseada em nuvem, que

permite aos desenvolvedores escrever scripts que podem manipular APIs de
serviços, como Calendário, Documentos, Drive, Gmail e Planilhas, e criar facilmente
complementos para esses serviços com aplicativos baseados no navegador
Chrome. As funcionalidades mais comuns são:

o registro do usuário é, geralmente, feito por meio do login do

Google+, que permite que os usuários façam login em serviços de
terceiros com a conta do Google+, usando a API do Google+. Isso está
disponível no Android, iOS ou em JavaScript;
os aplicativos do Google Drive são vários aplicativos da web
(geralmente de terceiros) que funcionam usando a Google Drive API; a
pesquisa personalizada permite que os desenvolvedores da web
forneçam uma pesquisa em seu próprio site incorporando uma caixa
de pesquisa personalizada e usando a API de pesquisa personalizada;
 os aplicativos do Google App Engine, são aplicativos da web que são
executados no Google App Engine, que é uma plataforma de
computação em nuvem de plataforma como serviço (PaaS), que
permite que os desenvolvedores da web executem seus websites nos
data centers do Google;
os gadgets são mini-aplicativos criados em HTML, JavaScript, Flash e
Silverlight, que podem ser incorporados em páginas da web e outros
aplicativos. Eles podem ser executados em vários sites e produtos.

O Google Loader é uma biblioteca JavaScript que permite que os desenvolvedores

da web carreguem facilmente outras APIs JavaScript fornecidas pela Google e por
outros desenvolvedores de bibliotecas populares. O Google Loader fornece um
método JavaScript para carregar uma API específica (também chamada de
módulo), no qual, configurações adicionais podem ser especificadas, como versão
da API, idioma, localização, pacotes selecionados, retorno de chamada de carga e
outros parâmetros específicos de uma API específica.

4.2 Serviços em nuvem

Os serviços em nuvem indicam inúmeros recursos de TI, que estão disponíveis na
internet. Esta expressão também engloba a oferta de serviços para a seleção,
implantação e gerenciamento constante de vários recursos. Os serviços de
computação em nuvem abrangem muitos recursos que um provedor de serviços
oferece aos clientes pela internet, como o armazenamento e processamento de
dados em um servidor online. A nuvem “permite que uma grande diversidade de
dispositivos (tablets, celulares, notebooks e desktops), possa acessar e executar
esses recursos, sendo necessário somente o acesso à internet e um mecanismo
padronizado, que por sua vez pode ser um navegador que necessita poucos
recursos computacionais” (VANDRESEN; MAGALHÃES, 2013, p. 1).
As características dos serviços em nuvem incluem autoprovisionamento e
elasticidade; ou seja, os clientes podem provisionar serviços sob demanda e
desligá-los, quando não forem mais necessários. Além disso, os clientes geralmente
assinam serviços em nuvem, por exemplo, em um acordo de cobrança mensal, para
não ser necessário pagar por licenças de so ware. Em muitas transações, essa
abordagem torna uma tecnologia baseada em nuvem uma despesa operacional,
em vez de uma despesa de capital (VANDRESEN; MAGALHÃES, 2013).
A tecnologia em nuvem oferece para os desenvolvedores, organizações e usuários
o acesso a diversos so wares, armazenamento e demais funcionalidades de
infraestrutura de TI sem nenhum custo de manutenção e atualização.
O uso de serviços em nuvem tornou-se estreitamente associado a ofertas comuns
de nuvem, como so ware como serviço (SaaS), plataforma como serviço (PaaS), e
infraestrutura como serviço (IaaS), baseados em nuvem (VANDRESEN; MAGALHÃES,
2013).
Neste sentido, como o sistema operacional Android utiliza os serviços em nuvem?
Quais são as funcionalidades? Como são incorporados aos aplicativos? Estas
questões serão exploradas a seguir.

4.2.1 Android data backup

O backup automático para aplicativos faz a cópia automática de aplicativos, que é
executado no Android 6.0 (nível 23 da API) ou posterior. O Android preserva os
dados do aplicativo fazendo o upload para o Google Drive do usuário, no qual ele é
protegido pelas credenciais da Conta do Google. A quantidade de dados é limitada
a 25 MB por usuário do seu aplicativo e não há custos para armazenar dados de
backup. O aplicativo pode personalizar o processo de backup ou desativar os
backups.
Por padrão, o backup automático inclui arquivos na maioria dos diretórios
atribuídos ao aplicativo pelo sistema:

arquivos de preferências compartilhados;

arquivos salvos no armazenamento interno do aplicativo, acessado por
getFilesDir() ou getDir();
arquivos no diretório retornado por getDatabasePath(), que também
inclui arquivos criados com a classe SQLiteOpenHelper; arquivos no
armazenamento externo, no diretório retornado por
getExternalFilesDir().
O backup exclui arquivos em diretórios retornados por getCacheDir(),
getCodeCacheDir(), ou getNoBackupFilesDir(). Os arquivos salvos nesses locais são
necessários apenas temporariamente ou são intencionalmente excluídos das
operações de backup.

4.2.2 Firebase
O Firebase é um API da Google que tem como objetivo enviar mensagens de
notificações e dados de forma confiável. O Firebase é um Firmware Cloud Messaging
(FCM), no qual é possível, por exemplo, executar uma notificação no aplicativo do
usuário informando que e-mail, ou outros dados, estão disponíveis.
Portanto, é possível enviar mensagens de notificação para fazer a interação entre
usuários. O pré-requisito para configurar o Firebase é, pelo menos, ter uma conta
do Google para entrar no sistema.

4.2.3 Cloud to Device Message e Google Cloud Messaging

O Android Cloud para mensagens de dispositivo (comumente chamado de
mensagens em nuvem para dispositivos) ou C2DM, é um serviço de notificação
móvel extinto que foi desenvolvido pela Google e substituído pelo serviço Google
Cloud Messaging. Ele permitiu que os desenvolvedores enviassem dados de
servidores para aplicativos Android e extensões do Chrome. O C2DM foi lançado
originalmente em 2010, e estava disponível a partir da versão 2.2 do Android.
Em 27 de junho de 2012, a Google revelou o serviço do Google Cloud Messaging para
substituir o C2DM, citando melhorias na autenticação e, na entrega, novos pontos
da API e parâmetros de mensagens, a remoção de limites de taxa da API e de
tamanhos máximos de mensagens.
O Google Cloud Messaging é um serviço gratuito que permite aos desenvolvedores
enviar mensagens entre servidores e aplicativos clientes. Isso inclui mensagens
downstream de servidores para aplicativos clientes e mensagens upstream de
aplicativos clientes para servidores. Por exemplo, uma mensagem poderia informar
um aplicativo cliente de que há novos dados a serem buscados no servidor, como
no caso de uma notificação de "novo e-mail". Como mensagens instantâneas, uma
mensagem do GCM pode transferir até 4 kbytes para o aplicativo cliente. O serviço
GCM lida com todos os aspectos de enfileiramento de mensagens e entrega para o
aplicativo cliente de destino.
 VOCÊ SABIA?
Existe uma ciência chamada de “ciência do contexto”, que leva em consideração
todo o entorno e contexto, no qual o usuário está inserido. Baseando-se na ciência
do contexto, foi desenvolvido o aplicativo Acessibility, que tem como função
disponibilizar informações que auxiliam a locomoção de usuários portadores de
necessidades especiais (SANTOS, et al., 2015). Você por se aprofundar neste assunto
çlendo o artigo “Dispositivos móveis e usuários cegos: recomendações de
acessibilidade em discussão” (MACHADO; MACHADO; CONFORTO, 2014): <
http://www.tise.cl/volumen10/TISE2014/tise2014_submission_231.pdf
(http://www.tise.cl/volumen10/TISE2014/tise2014_submission_231.pdf)>.

A suspensão oficial do serviço C2DM se deu em agosto de 2012, pouco depois de

anunciar o serviço do Google Cloud Messaging. A Google, então, publicou
documentação para orientar os desenvolvedores de aplicativos a migrar do C2DM
para o novo serviço.
A migração para o serviço exigiu mudanças no SDK e no código, bem como a
liberação de uma atualização de aplicativo para o repositório de publicação (como
o Google Play) para download e atualização. O C2DM e o serviço do Google Cloud
Messaging não eram interoperáveis entre si; não era possível enviar solicitações de
dados usando um serviço para ser recebido e processado, no aplicativo cliente,
usando o outro. A migração também exigia que alterações fossem feitas no servidor
de terceiros, operado pelo desenvolvedor (dependendo da complexidade e do caso
de uso em relação aos dados enviados).

4.3 Sensores e toque

Um sensor de toque é um tipo de equipamento que captura e grava o toque físico
em um dispositivo. Ele permite que um dispositivo ou objeto detecte o toque,
geralmente por um usuário ou operador humano. Um sensor de toque também
pode ser chamado de detector de toque.
Ao contrário de um botão ou outro controle mais manual, os sensores de toque são
mais sensíveis e geralmente respondem de maneira diferente a vários tipos de
toque, como tocar ou arrastar. Os sensores de toque são usados em dispositivos de
tecnologia de consumo, como smartphones e tablets. Normalmente, os sensores
de toque são usados como um meio de receber informações do usuário. Para que
se possam extrair ao máximo as funcionalidades de sensores e toques, é necessária
uma estrutura com câmera, sensores de movimento e presença posicionados
estrategicamente no ambiente (SOUZA, 2012).
Cada traço físico que um sensor de toque grava é enviado para uma unidade de
processamento/so ware, que o processa de acordo. Por exemplo, ao navegar por
um smartphone ou usar um aplicativo, o sensor de toque captura os toques
humanos ou a pressão aplicada na tela. Com o sistema operacional Android utiliza
estes recursos? Como é possível implantar nos aplicativos? Quais são os seus
componentes? Estas questões serão vistas a seguir.

4.3.1 Câmera API

A estrutura do Android inclui suporte para vários recursos de câmeras disponíveis
nos dispositivos, permitindo que se capturem fotos e vídeos em aplicativos. Será
realizada uma abordagem sobre a captura de imagens e vídeos, descrevendo as
aplicações de câmera personalizadas para os usuários.
Antes de ativar o aplicativo para usar câmeras em dispositivos Android, deve-se
considerar algumas perguntas sobre como seu aplicativo pretende usar esse
recurso de hardware.

Requisito da câmera: o uso de câmera é um requisito fundamental

para determinados aplicativos, sendo uma condição necessária para a
instalação. Nesse caso, deve-se declarar o requisito de câmera.
Imagem rápida ou câmera personalizada: como o aplicativo
usará a câmera?
Armazenamento: as imagens ou vídeos de seu aplicativo devem ser
visíveis apenas para o aplicativo ou compartilhados, para que outros
aplicativos, como o Gallery ou outras mídias e aplicativos sociais,
possam usá-los? É desejável que as fotos e os vídeos estejam
disponíveis, mesmo se o aplicativo for desinstalado?

O framework Android suporta a captura de imagens e vídeos pela

android.hardware.camera2. Aqui estão as classes relevantes:
 Android.hardware.camera2. Este pacote é a principal API para
controlar câmeras de dispositivos. Pode ser usado para tirar fotos ou
gravar vídeos, quando estiver sendo criado um aplicativo de câmera;
SurfaceView. Esta classe é usada para apresentar uma prévia da
câmera ao vivo para o usuário;
MediaRecorder. Esta classe é usada para gravar vídeos da câmera.

A Câmera API 2.0 é uma nova API que permite um controle muito melhor por
aplicativos e aumenta o desempenho da câmera. A Câmera API 2.0 é rápida o
suficiente para aproveitar a resolução total do sensor. Isso significa que uma
fotografia computacional como essa deve ser muito mais barata em dispositivos
Android. A nova API também permite um controle muito mais refinado do sensor,
lente e flash por quadro individual.

4.3.2 Acesso a sensores disponíveis

A maioria dos dispositivos com Android possui sensores integrados que medem
movimento, orientação e várias condições ambientais. Esses sensores são capazes
de fornecer dados brutos com alta precisão e são úteis, se desejamos monitorar o
movimento ou o posicionamento tridimensional do dispositivo, ou desejamos
monitorar alterações no ambiente próximo a um dispositivo. Tem-se como
exemplo um aplicativo que é capaz de rastrear o sensor de gravidade de um
dispositivo móvel para que possa ler e inferir gestos e movimentos do usuário,
como a inclinação, oscilação ou rotação do aparelho. De forma semelhante, um
determinado aplicativo pode ter a capacidade de utilizar os sensores de
temperatura e umidade para informar para o usuário, como também o dispositivo
tem a capacidade de usar sensores de campo geomagnético para expor uma
bússola.
A plataforma Android suporta três grandes categorias de sensores (DEITEL; DEITEL;
WALD, 2016, p. 200):

sensores de movimento: medem forças de aceleração e forças de

rotação ao longo de três eixos. Esta categoria inclui acelerômetros,
sensores de gravidade, giroscópios e sensores vetoriais rotacionais;
sensores ambientais: medem vários parâmetros ambientais, como
 temperatura e pressão do ar ambiente, iluminação e umidade. Esta
categoria inclui barômetros, fotômetros e termômetros; sensores de
posição: medem a posição física de um dispositivo. Esta categoria
inclui sensores de orientação e magnetômetros.

Pode-se acessar sensores disponíveis no dispositivo e adquirir dados brutos do

sensor usando a estrutura do sensor Android. A estrutura do sensor fornece várias
classes e interfaces que ajudam a executar uma ampla variedade de tarefas
relacionadas ao sensor. Por exemplo, pode-se usar a estrutura do sensor para fazer
o seguinte:

determinar quais sensores estão disponíveis em um dispositivo;

determinar os recursos de um sensor individual, como o alcance
máximo, o fabricante, os requisitos de energia e a resolução;
adquirir dados brutos do sensor e definir a taxa mínima na qual você
adquire os dados do sensor; registrar e cancelar o registro dos
eventos do sensor, que monitoram as alterações do sensor.
A estrutura do sensor Android permite acessar vários tipos de sensores. Alguns
desses sensores são baseados em hardware e alguns são baseados em so ware. Os
sensores baseados em hardware são componentes físicos incorporados em um
aparelho ou tablet. Eles derivam seus dados medindo diretamente propriedades
ambientais específicas, como aceleração, força do campo geomagnético ou
alteração angular. Os sensores baseados em so ware não são dispositivos físicos,
embora imitem sensores baseados em hardware. Os sensores baseados em so ware
obtêm seus dados de um ou mais dos sensores baseados em hardware e, às vezes,
são chamados de sensores virtuais ou sensores sintéticos. O sensor de aceleração
linear e o sensor de gravidade são exemplos de sensores baseados em so ware
Alguns dispositivos com Android possuem todos os tipos de sensores. Por exemplo,
a maioria dos aparelhos e tablets possui um acelerômetro e um magnetômetro,
mas poucos aparelhos possuem barômetros ou termômetros. Além disso, um
dispositivo pode ter mais de um sensor de um determinado tipo. Por exemplo, um
dispositivo pode ter dois sensores de gravidade, cada um com um intervalo
diferente.
4.3.3 Single e multittoque
Seja uma interface de máquina humana (HMI) compatível com smartphone, tablet
ou touch, alguns dispositivos com tela sensível ao toque são compatíveis, enquanto
outros suportam multitoque. O princípio básico por trás dessas duas tecnologias é
o mesmo: apoiar a entrada do usuário por meio do toque. No entanto, existem
algumas diferenças fundamentais entre o toque único e o multitoque que
discutiremos hoje.
Durante os primeiros anos da tecnologia touchscreen, os dispositivos eram
limitados estritamente a funções de toque único. O toque único faz jus ao seu nome,
suportando a entrada a partir de um único toque. Por exemplo, um toque no ícone
com o dedo indicador para abrir o aplicativo em um smartphone, que é uma função
de toque único, pois usa um único toque.

VOCÊ QUER VER?

Na palestra Produtividade Ninja no Android Studio, o desenvolvedor Ramon Rabello (2017) (Android So
ware Engineer Senior na Colab.re), dá dicas para usar o Android Studio de forma mais eficaz e ampliar
sua produtividade. Para assistir acesse <https://www.youtube.com/watch?v=3V8pkvNCAKM
(https://www.youtube.com/watch?v=3V8pkvNCAKM)>.

Isso não é necessariamente ruim, mas não oferece muito, em termos de

versatilidade e expansão, em mais entradas de comando. Concedido, os usuários
poderiam executar rápidos toques duplos para acionar um comando diferente. Ao
contrário do toque único, o multitoque suporta o uso de dois ou mais comandos
simultâneos baseados em toque. Um exemplo de função multitoque é o recurso
pinch-to-zoom, que é encontrado em muitos smartphones e tablets. Se quiser
aumentar o zoom, basta apertar a tela para dentro usando dois dedos. Se quiser
diminuir o zoom, basta executar o movimento oposto, movendo para fora. Recursos
como esse não são encontrados em dispositivos de toque único, simplesmente
porque não podem registrar dois pontos de contato simultâneos.
As funções de toque único e multitoque podem ser encontradas em dispositivos
resistivos e capacitivos. Os dispositivos touchscreen resistivos identificam o ponto
de contato do operador apertando as camadas superior e inferior juntas. Eles são
menos sensíveis, mas podem ser usados com ou sem uma caneta. Dispositivos
touchscreen capacitivos, por outro lado, identificam o ponto de toque com base na
carga elétrica criada pelo operador. O corpo humano produz uma quantidade
pequena, mas perceptível de eletricidade. E quando pressiona o dedo contra a
superfície de um dispositivo capacitivo, ele capta essa carga para determinar
exatamente onde tocou.

4.3.4 Reconhecimento de gestos

O reconhecimento de gestos é a interpretação matemática de um movimento
humano por um dispositivo de computação.
O reconhecimento de gestos, acompanhado de reconhecimento facial, de voz,
rastreamento ocular e reconhecimento de movimentos labiais são componentes
do que os desenvolvedores chamam de interface de usuário perceptual (PUI). O
objetivo do PUI é aumentar a eficiência e a facilidade de uso do design lógico
subjacente de um programa armazenado, uma disciplina de design conhecida
como usabilidade.
Na computação pessoal, os gestos são mais usados para comandos de entrada.
Reconhecer os gestos como entrada, permite que os computadores sejam mais
acessíveis para os deficientes físicos e torne a interação mais natural em um
ambiente de jogos ou realidade virtual em 3D.
Gestos de mão e corpo podem ser amplificados por um controlador que contém
acelerômetros e giroscópios para detectar inclinação, rotação e aceleração de
movimento – ou o dispositivo de computação pode ser equipado com uma câmera
para que o so ware no dispositivo possa reconhecer e interpretar gestos específicos.
Uma onda feita com a mão, por exemplo, pode terminar o programa.
Além dos desafios técnicos da implementação do reconhecimento de gestos,
também existem desafios sociais. Os gestos devem ser simples, intuitivos e
universalmente aceitáveis. O estudo de gestos e outros tipos não verbais de
comunicação é conhecido como cinesiologia.
4.4 Projeto de aplicativo
Agora, vamos entender como se desenvolve um projeto em Android com
geolocalização. O objetivo do projeto é mostrar como recuperar a localização atual
de um usuário e exibi-lo com um marcador em um mapa no dispositivo móvel.
Segundo Lee, Schneider e Schell (2005, p. 100), ao se desenvolver aplicativos para
dispositivos móveis, “cada objeto representa uma entidade em um cenário do dia
a dia de aplicação”. Neste projeto, é importante identificar quais serão os objetos.
O Android tem duas maneiras básicas para determinar a localização de um usuário.
A primeira é usar as APIs de localização incorporadas, que estão disponíveis desde
que o Android foi introduzido pela primeira vez. Eles ainda funcionam, mas não tão
bem quanto as APIs de localização mais recentes agrupadas conhecidas como
Google Play Services. A API de serviços de localização do Google, parte do Google
Play Services, fornece uma estrutura de alto nível mais poderosa que automatiza
tarefas como a escolha do provedor de localização e o gerenciamento de energia.
Os Serviços de Localização também fornecem novos recursos, como detecção de
atividades, que não estão disponíveis na API do framework. Os desenvolvedores
que usam a API de estrutura, bem como os desenvolvedores que agora adicionam
reconhecimento de local aos aplicativos, devem considerar seriamente o uso da API
de serviços de localização.
CASO
O desenvolvimento de aplicativos para dispositivos móveis, tem atingido as mais
diversas áreas e atividades profissionais. Na área da saúde, o prontuário médico é um
documento elaborado pelo profissional, e é uma ferramenta fundamental para seu
trabalho. No prontuário são apresentados, de forma organizada e concisa, todos os
dados relativos ao paciente, como seu histórico familiar, anamnese, descrição e
evolução de sintomas e exames, além das indicações de tratamentos e prescrições.
Neste sentido, foi proposto por um grupo de pesquisadores (SANTOS et al., 2017), um
modelo de Prontuário Eletrônico Único do Paciente. Esta é uma proposta para
manipular a dispersão de dados dos prontuários sem ter que mobilizar grandes volumes
de dados em atendimentos. Assim, esse modelo fornece níveis de informação, nos quais
se destaca a síntese que concentra as informações relevantes para os atendimentos.
Este modelo é disponível em dispositivos móveis e um middleware para negociar as
transações entre eles.
A Google disponibiliza seus APIs por meio do Google Play Services, que é um pacote
que oferece diversos recursos para serem implantados nos aplicativos
desenvolvidos no sistema operacional Android. Eles são instalados na maioria dos
dispositivos e executados no Android 2.3 e superiores.
A primeira tarefa a fazer é executar o download do SDK do Google Play Services
usando o SDK Manager.
A seguir, deve ser criado um modelo de projeto disponível no Android Studio. A
seguir, vamos acompanhar a demonstração de Deitel (2016) de como instalar o
Android Studio de forma fácil. O modelo "Atividade do Google Maps" gera um
código para localização que facilitará o desenvolvimento.

Criar um novo projeto ("EuEstouAqui").

Selecionar "Telefone e tablet" como forma.
Selecionar a "Atividade do Google Maps" como o modelo da atividade
e concluir a criação do projeto.

Na figura a seguir vemos a tela de criação inicial do projeto no Android Studio.

Figura 1 - O modelo de atividade do Google Maps da ferramenta Android Studio para criação de
aplicativos. Fonte: Elaborada pelo autor, 2018, na ferramenta Android Studio.
#PraCegoVer: Print da tela do Android Studio contém no topo uma faixa verde
escrito: Add na activity to Mobile, abaixo da faixa verde do lado esquerdo tem um
pedaço em branco escrito Add No Activity; do lado à direita a tela de um celular em
branco e no topo dessa tela representa o browser e embaixo dele está escrito Blank
Activity; do lado desta tela à direita tem outra tela de celular e dentro dela tem no
topo uma faixa representando o browser e embaixo o desenho de uma linha
pontilhada azul claro que faz o contorno da borda da tela em branco e embaixo
desta tela está escrito Blank Activity with Fragment. Do lado desta tela à direita tem
outra tela de celular com faixas onduladas intercalando azul escuro com azul claro
(cor de fundo da tela do celular) e no topo desta tela tem uma faixa representando
o browser, do lado direito, tem um símbolo branco quadrado, onde cada
extremidade desse quadrado é uma seta apontando de dentro para fora do
quadrado, uma linha branca no meio da tela inclinada para a esquerda cruza a tela
na diagonal e abaixo desta tela está escrito Fullscreen Activity; do lado desta tela à
direita tem outra tela de celular preta e dentro dela tem uma quadrado azul com
um quadrado amarelo no meio da tela escrito Ad, embaixo desta tela de celular está
escrito Google AdMob Ad s Activity. Abaixo dessas telas tem-se mais 5 telas de
celular, à primeira tela à direita tem no topo uma linha representando o browser e
embaixo o desenho de uma mapa e de um localizador em vemelho e abaixo dessa
tela está escrito Google Maps Activity; do lado desta tela à direita tem outra tela de
celular onde dentro dela no topo tem uma linha representando um browser e
abaixo o símbolo do google play que é uma peça de quebra cabeça com o encaixe
do lado esquerdo da peça e uma parte a ser encaixada no topo dela, está peça é
colorida, com uma parte verde claro, outra azul claro, outra vermelho e a outra
laranja, abaixo desta tela de celular está escrito Google Play Service Activity; do lado
desta tela à direita tem outra tela de celular e dentro dela tem uma tela onde no
topo tem uma barra representando o browser e embaixo tem dois campos um para
digitar email e embaixo um para digitar a senha e embaixo um botão, embaixo da
tela está escrito Login Activity; do lado desta tela à direita tem outra tela de celular
mas virada na horizontal e dentro dela tem uma faixa cinza à esquerda com
algumas linhas brancas onduladas (representando escritas) e do lado tem um
quadro branco e embaixo dele algumas linhas brancas onduladas (representando
escritas), embaixo desta tela está ecrito Master / Detail Flow; do lado desta tela à
direita tem outra tela de celular e dentro dela tem no topo uma barra
representando um browser e embaixo do lado esquerdo tem uma faixa cinza
algumas linhas brancas onduladas (representando escritas) e do lado direito tela
em branco.

Em seguida, é necessário criar uma chave API do Google Maps para configurar o
Google Play Services. Esta chave é obtida clicando-se no endereço:
<https://console.developers.google.com/flows/enableapi?
apiid=maps_android_backend&keyType=CLIENT_SIDE_ANDROID&r=17:8A:66:F5:C
7:FF:50:E3:77:FB:79:8A:79:3F:30:43:FC:D6:CE:61%3
(https://console.developers.google.com/flows/enableapi?
apiid=maps_android_backend&keyType=CLIENT_SIDE_ANDROID&r=17:8A:66:F5:C
7:FF:50:E3:77:FB:79:8A:79:3F:30:43:FC:D6:CE:61%3)>.

É necessário acessar este link e se inscrever em uma chave da API do Google Maps.
Não há custo para se inscrever e, quando receber uma chave desse site, você deve
voltar a esse arquivo e substituir YOUR_KEY_HERE pela nova chave.
Para demonstrar o processo, fizemos capturas de tela, que podem ser usadas como
referência.

1. Selecione ‘Criar um novo projeto’ e clique em ‘Continuar’, conforme figura a

seguir:

Figura 2 - Criação de novo projeto do Google Maps console developers Google do Google API – etapa 1.
Fonte: Elaborada pelo autor, 2018 na ferramenta Google API.

#PraCegoVer: Print da tela de criação de um novo projeto escrito:

Register your application for Google Maps Android API v2 in Google Developers
Console
Google Developers Console allows you to manage your application and monitor API
usage
SELECT A PROJETO WHERE YOUR APPLICATION WILL BE REGISTERED
You can use one project to manage all of your applications, or you can create a
different project for each application
Opção selecionada: Create a new project e abaixo um botão azul escrito Continue.

2. A criação do novo projeto leva alguns segundos e ficará na tela que vemos
nafigura a seguir:

Figura 3 - Criação de novo projeto do Google Maps console developers Google do Google API – etapa 2.
Fonte: Elaborada pelo autor, 2018 na ferramenta Google API.

#PraCegoVer: Print da tela chamada Activities (1), abaixo escrito Create Project: My
Project e na frente o símbolo de carregando, abaixo escrito Create Project: My
Project e na frente o símbolo de tick verde, abaixo escrito Create Project: My Project
e na frente o símbolo de tick verde e abaixo escrito Create Project: My Project e na
frente o símbolo de tick verde.

3. Clique em ‘Criar’, para, finalmente, criar a chave de API, conforme aparece

nafigura a seguir.
 Figura 4 - Criação de novo projeto do Google Maps console developers Google do Google API – etapa 3.
Fonte: Elaborada pelo autor, 2018 na ferramenta Google API.

#PraCegoVer: Print da tela para criar, está escrito:

Create na Android key and configure allowed Android applications.

This key can be deployed in your Android Application.
API requests are sent directly from na Android application that matches one of the
certificate SHA1 fingerprints and package names listed below. You can disciver the
SHA1 fingerpoint of your developer certificate using the following command:
Keytool -list -v -keystore mystore.keystore
Learn more (escrito em azul)
ACCEPT REQUESTS FROM NA ANDROID APPLICATION WITH ONE OF THE
CERTIFICATE FINGERPRINTS AND PACKAGE NAMES LISTED BELOW
One SHA1 certificate fingerprint and package name (separated by a semicolor) per
line. Example:
45:B5:E4:6F:AD:0A:98:B4:02:66:2B:12:17:F2:56:26:E0;com.example Desenho
de um quadro branco e dentro dele escrito:
77:77: 77:77: 77:77: 77:77: 77:77: 77:77: 77:77: 77:77: 77:77:
77:77;teamtreehouse.com.iamhere
Abaixo dois botões um azul escrito Create e do lado um branco escrito Cancel.

4. Por fim, copiar e colar sua API KEY no aplicativo.

Figura 5 - Criação de novo projeto do Google Maps console developers Google do Google API – etapa 4.
Fonte: Elaborada pelo autor, 2018 na ferramenta Google API.

#PraCegoVer: Print da tela para criar, do lado esquerdo está escrito:

Public API access

Use of this key does not require any user action or consent, does not grant access to
any account information, and is not used for authorization.
Learn more(escrito em azul)
Botão azul escrito: Create new key
Do lado direito os campos, começando com a escrita: Key for Android applications,
embaixo tem os campos:
API KEY preenchido com AAAAAAAAAAAAA.umdUP3o3FfT1__DKxAus4g
ANDROID APPLICATIONS teamtreehouse.com.iamhere
ACTIVATION DATE Dec 18, 2014, 5:27:00 AM
ACTIVATED BY (you)

É necessário criar um arquivo “xml’ denominado google_maps_api.xml. O arquivo

(API) tem como função oferecer acesso seriado ao conteúdo de um documento XML
por meio de orientação a evento. É necessário criar este arquivo e substituir
YOUR_KEY_HERE pela nova chave.
 Figura 6 - Criação do arquivo google_maps_api.xml para o desenvolvimento do aplicativo de
geolocalização. Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela, com o código xml:

<resources>
<string name=“google_maps_key_instructions”
templateMergeStrategy=“replace”>
https://console.developers.google.com/flows/enableapi?
apiid=maps_android_backend&keyType=CLIENT_SI
DE_ANDROID&r=17:8A:66:F5:C7:FF:50:E3:77:FB:79:8A:79:3F:30:43:FC:D6:CE:61%3B
string in file:
--></string>
<string name=“google_maps_key” templateMergeStrategy=“preserve”>
YOUR_KEY_HERE </string> </resources>

Neste momento é necessário criar o arquivo build.gradle, que define o nome do

programa. Quando utilizamos o Android Studio, o processo de build completo é
feito a cada vez que você executa o Gradle para construir seus projetos ou módulos.
O build.gradle é definido como na figura a seguir.
 Figura 7 - Criação do arquivo build.gradle para desenvolvimento do aplicativo de geolocalização. Fonte:
Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela, com o código: apply

plugin: ‘com.android.application’

android{
compileSdkVersion 21
buildToolsVersion “21.0.2”

defaultConfig { applicationId
“EuEstouAqui” minSdk
Version 14 targetSdk Version
21 versionCode 1
versionName “1.0”
}
buildTypes { release { minifyEnabled false proguardFiles
getDefaultProguardFile(‘proguard-android.txt’).‘proguard-rules.pro’
}
}
}

dependencies {
compile fileTree(dir: ‘libs’.include: [‘*.jar’]) compile
‘com.android.support:appcompat-v7:21.0.2’ compile
‘com.google.android.gms:play-services:6.1.71’
}

Neste momento, é necessário iniciar o Gerenciador do SDK novamente e

selecionar uma das imagens do emulador (AVD), que usa as APIs da Google. Depois
de ter um dispositivo ou emulador apropriado para testar, executar o aplicativo e
verificar se o mapa é carregado. Em caso afirmativo, a nova chave de API é válida e
o projeto está pronto para ser implantado.
A seguir, para se obter o local atualizado, é necessário criar o arquivo
AndroidManifest.xml, como vemos na figura:
Figura 8 - Criação do arquivo AndroidManifest.xml para desenvolvimento do aplicativo de geolocalização.
Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela, com o código:

<manifest xmlns:android=http://scheas.android.com/apk/res/android
package=“teamtreehouse.com.iamhere”>

<uses-permission android:name=“android.permission.INTERNET” />

<uses-permission android:name=“android.permission.ACCESS_NETWORK_STATE”
/>
<uses-permission
android:name=“android.permission.WRITE_EXTERNAL_STORAGE” />
<uses-permission
android:name=“com.google.android.providers.gsf.permission.READ_GSERVICE”
/>
<uses-permission
android:name=“android.permission.ACCESS_COARSE_LOCATION” />
<uses-permission android:name=“android.permission.ACCESS_FINE_LOCATION”
/>

<application android:allowBackup=“true”
android:icon=“@drawable/ic_laucher”
android:label=“@string/app_name”
android:theme=“@style/AppTheme”
<meta-data
android:name=“com.google.android.gms.version”
android:value=“@integer/google_play_services_version” />
<meta-data
android:name=“com.google.android.maps.v2.API_KEY”
android:value=“@string/google_maps_key” />

<activity android:name=“.MapsActivity”
android:value=“@string/google_maps_key” />
<intent-filter>
<action android:name=“android.intent.action.MAIN” />

<category android:name=“android.intent.category.LAUNCHER” />

<intent-filter>
</activity>
</application>

</manifest>

Na sequência, é necessário verificar se o Google Play Services está disponível. Está

disponível, por padrão, na maioria dos dispositivos, mas se não for, deve-se solicitar
ao usuário que o instale, antes de usar o aplicativo. No código Java, isso é realizado
automaticamente. Podemos ver o arquivo MapsActivity.java na figura abaixo.
 Figura 9 - Criação do arquivo MapsActivity.java para desenvolvimento do aplicativo de geolocalização.
Fonte: Elaborada pelo autor, 2018.
#PraCegoVer: Print da tela, com o código:

Package EuEstouAqui;
import android.content.IntentSender; import
android.location.Location; import
android.os.Bundle; import
android.support.v4.app.FragmentActivity;
import android.util.Log;

import com.google.android.gms.common.ConnectionResult; import

com.google.android.gms.common.api.GoogleApiClient; import
com.google.android.gms.location.LocationListener; import
com.google.android.gms.location.LocationRequest; import
com.google.android.gms.location.LocationServices; import
com.google.android.gms.maps.CameraUpdateFactory; import
com.google.android.gms.maps.GoogleMap; import
com.google.android.gms.maps.SupportMapFragment; import
com.google.android.gms.maps.model.LatLng; import
com.google.android.gms.maps.model.MarkerOptions; public static final
String TAG = MapsActivity.class.getSimpleName(); private final static int
CONNECTION_FAILURE_RESOLUTION_REQUEST = 9000; private GoogleMap
mMap;

private GoogleApiClient mGoogleAiClient; private

LocationRequest mLocationRequest;

@Override
Protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_maps); setUpMapIfNeeded();
mGoogleApiClient = new GoogleApiClientBuilder(this)
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.addApi(LocationServices.API) .build();
// Create the LocationRequest object mLocationRequest
= LocatioRequest.create()
.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY)
.setInterval(10 * 1000)
.setFasterInterval(1 * 1000);
}

@Override
protected void onResume() {
super.onResume();
setUpMaplfNeeded();
mGoogleApiClient.connect();
}

@Override
protected void onPause() { super.onPause();

if (mGoogleApiClietn.isConnected()) {
LocationServices.FusedLocationApi.removeLocationUpdates(mGoogleApiClient.
This); mGoogleApiClient.disconnect();
}
}

Private void setUpMapIfNeeded() { if

(mMap == null) {
mMap = ((SupportMapFragment)
getSupportFragmentManager().findFragmentById(R.id.map))
.getMap();

if (mMap != null) { setUpMap();

}
}
}

private void setUpMap() {

mMap.addMarker(new MarkerOptions().position(new LatLng(0. 0)).title(“Marker”));
}

Private void handleNewLocation(Location location) {

Log.d(TAG.location.toString());

double currentLatitude = location.getLatitude(); double

currentLongitude = location.getLongitude();

LatLng latLng = new LatLng(currentLatitude, currentLongitude);

MarkerOptions options = new MarkerOptions()

.positio(latLng)
.title(“I am here!”);
mMap.addMarker(options);
mMap.moveCamera(CameraUpdateFactory.newLatLng(latLng));
}

@Override
Public void onConnected(Bundle bundle) {
Location location =
Location.Services.FusedLocation.Api.get.LastLocation(mGoogleApiClient);
if (location == null) {
LocationServices.FusedLocationApi.requestLocationUpdates(mGooogleApiClient,
mLocationRequest, this);

}
else {
handleNewLocation(location);
}
}

@Override
Public void onConnectionSuspended(int i) {

}
@Override
public void onConnectionFailed(Connection Result connectionResult)
{ if (connectionResult.hasResolution()) { try {
connectionResult.startResolutionForResult(this,
CONNECTION_FAILURE_RESOLUTION_REUEST);
} catch (IntentSender.SendIntentException e) { e.prinStack
Trace();
}
} else{
Log.i(TAG, “Location services connection failed with code ” +
connectionResult.getErrorCode());
}
}

@Override
public void onLocationChanged(Location location) { handleNewLocation(location);
}
}

mGoogleApiClient = new GoogleApiClient.Builder(this)

.addConnnectionCallback(this)
.addOnConnectionFailedListener(this)
.addApi(LocationServices.API)
.build();

Para compreender melhor o código é necessário fazer algumas observações. É

necessário usar o GoogleApiClient, que é o cliente mais recente do Google Play
Services, projetado para facilitar a configuração e o uso desta e de outras funções
do Google Play Services. “privado GoogleApiClient mGoogleApiClient;”.
É preciso de uma variável TAG, conforme a declaração: “public static final String
TAG = MapsActivity.class.getSimpleName ();”.
Agora é necessário inicializar o cliente na parte inferior do onCreate()método
MapActivity.
Agora, é necessário implementar os métodos no Android Studio, como demonstra
a figura abaixo.

Figura 10 - Implementação dos métodos para desenvolvimento do aplicativo de geolocalização. Utilização

da ferramenta Android Studio. Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: print da tela do Android Studio na primeira linha está escrito public
class MapsActivity extends FragmentActivity implements. Embaixo da palavra
public class tem uma caixa com 5 opções: a primeira Implement Methods
selecionada em azul, segunda Make ‘MapsActivity’ abstract, terceira Create
Subclass, quarta Create Test e quinta Make package-local. Embaixo dessa caixa tem
outra caixa maior com o título Select Methods to Implement, embaixo tem a barra
com 4 botões, o segundo está selecionado, tem um bolinha azul clara e
dentro dela a letra c; embaixo tem uma barra escrito
com.google.android.gms.api.GoogleApiClient com os itens
onConnected(Bundle):void e onConnectionSuspended(int): void, ambos
selecionados na cor azul; embaixo tem uma barra escrito
com.google.android.gms.common.api.GoogleApiClient com o item
onConnectionFailled(ConnectionResult):void selecionado na cor azul; no final da
caixa tem duas opções CopyJavaDoc (não selecionado) e Insert @Override
(selecionado) e na frente dois botões: Cancel na cor branco acinzentado e OK na cor
azul para seleção.

Finalmente, se executar o aplicativo para verificar, veremos um novo marcador, que

nos permite saber exatamente onde estamos, como mostra a figura a seguir.
 Figura 11 - Tela final do aplicativo Android de geolocalização, mostrando a localização atual do usuário.
Utilização da ferramenta Android Studio. Fonte: Elaborada pelo autor, 2018.

#PraCegoVer: Print da tela de um celular Android com o mapa do mundo, nesta

parte do mapa aparece a Greenland, a América do Norte, Central e do Sul e um
localizador da cor vermelha no nordeste do Brazil escrito Eu estou aqui.

O desenvolvimento de aplicativos utilizando o Android Studio permite criar

sistemas de forma bastante intuitiva e com alto grau de qualidade. As diversas
funcionalidades que as APIs Google oferecem, interagindo com os recursos nativos
do sistema operacional Android, tornam o desenvolvimento e implantação de
aplicativos bastante eficiente. Além dos métodos e operações das APIs da Google,
os serviços em nuvem podem ser integrados com os aplicativos, para serem
desenvolvidas novas operações, como o armazenamento em nuvem, a
comunicação por meio de mensagens, e a utilização de recursos avançados dos
serviços Google e do sistema Android.
Síntese
Compreendemos neste capítulo como é possível aprimorar os aplicativos
desenvolvidos para dispositivos móveis utilizando as APIs da Google. O Google
oferece uma série de funcionalidades que incrementam e elevam a qualidade dos
aplicativos, tornando-os mais eficientes e robustos, como geolocalização e serviços
na nuvem, que estão cada vez mais presentes em diversos aplicativos. Outras
funcionalidades oferecidas, com bastante requinte, são os sensores e toque, que
permitem uma interação inteligente e intuitiva com a interface dos usuários de
dispositivos móveis.
Neste capítulo, você teve a oportunidade de:
utilizar os recursos de geolocalização e o Google Maps;
conhecer os serviços em nuvens como Android Data Backup, Firebase e
Cloud Messaging; programar os recursos de sensores, touch e câmera,
bem como o
reconhecimento de gestos; desenvolver um aplicativo de
geolocalização utilizando o Android Studio.

Projeto

PROJETO DE APLICATIVO

No mundo do século XXI, o planejamento estratégico é determinante

para as empresas. O acesso à informação é um tópico relevante entre os vários
pontos no planejamento. Trabalhar a informação de forma correta, resulta em
diversos benefícios e melhorias para organização como a melhoria da comunicação
interna, segurança, excelência nos processos, aumento da produtividade, tomada de
decisão, entendimento do cliente, eficiência em alcançar os objetivos do
planejamento, etc.
Nesse contexto, a Tecnologia da Informação e Comunicação (TIC) torna-se uma
realidade no planejamento estratégico. Essa ferramenta proporciona às empresas
melhoria na gestão e apoio nos processos de tomada de decisões. O intuito
é proporcionar inovações que serão diferenciais competitivos no mercado com a
finalidade de agregar valor e otimizar as rotinas dos processos.

Num mercado competitivo, estar a frente dos concorrentes é um ganho

de competitividade. Esse ganho que empresas melhorem o processo de adaptação a
novas mudanças e as novas demandas do mercado, proporcionando fazer a
reengenharia de processos para ser mais assertiva nos
investimentos em específicas, no uso de tecnologias e na inovação de serviços.

Um desses paradigma está associada a internet dos Coisas (IoT). A internet das
coisas é conceito do presente e que estará fortemente sendo implementado no
futuro. A ideia é que todas as coisas (objetos) estejam conectados via internet e
enviando informações entre si. Essas informações são inputs (inseridas) no sistema
através de atuadores como sensores que captam informações do mundo externo,
processam, e tal forma, reagem ao mundo externo. Por exemplo, numa cidade
inteligente, smart city, a caixa de lixo pode mandar automaticamente uma
mensagem para o proprietário da casa solicitando que o saco de lixo esteja do lado
de fora às 15:45, pois será a hora que o caminhão de lixo estará passando para
recolher o saco.

Esse cenário só será possível, porque ao sair da base, caminhão envia mensagens
para todas as caixas de lixo, e as mesmas para seus respectivos donos. O caminhão,
a caixa de lixo e o dispositivo eletrônico do dono da residência, estão conectado via
Internet, resultando num único sistema.

Na Tecnologia da Informação e Comunicação (TIC), a IoT agregará valores a serviços

ofertados a clientes e empresas, tornando o mundo mais integrado e eficiente. Para
tal feito, outras tecnologias como Learning Machine, Big Data e Inteligência Artificial
(IA) estão sendo integrada a IoT a fim de tornar o sistema mais humanizado, e
portanto, menos robotizado (Pires et al, 2015).

Para Magrani (2018), exemplifica a IoT através de sistemas automatizados que

acendem as luzes e aquecem o jantar ao perceber que você está retornando do
trabalho para casa, pulseiras e palmilhas inteligentes que compartilham com seus
amigos o quanto o usuário andou a pé ou de bicicleta durante o dia na cidade ou
sensores que avisam automaticamente aos fazendeiros quando um animal está
doente ou prenhe. Todos esses exemplos são manifestações consideradas
tecnologias inovadoras associadas ao conceito que vem sendo construído de
internet das coisas.

Vamos Praticar

Agora é a hora de praticar. Após a leitura do texto sobre Internet das Coisas e a
importância dos sensores para captura de informação. Faço um convite a você a
pensar, analisar, e descrever a importância do uso dos sensores, existentes
principalmente nos smartphones, como um recurso de inovação de projeto de
uma aplicação móvel idealizada para resolver um problema proporcionando
melhorias (benefícios) a um usuário ou a uma empresa. Faço uma ressalva sobre a
necessidade compreensão do negócio para uma melhor eficiência do projeto com
uma solução inovadora. Compartilhe no fórum da disciplina o seu ponto de vista
com relação ao uso de recurso num texto discorrido de aproximadamente 15
linhas e problematizando a importância do mesmo, explore os benefícios
proporcionado pela aplicação ao usuário ou empresa. Lembre-se que o foco
está associado nas necessidades do usuário(empresa).