Greg Nudelman

Traduo
BrodTec.com
Novatec
All rights reserved. Authorized translation from the English language edition entitled Android Design Patterns
Copyright 2013 by John Wiley & Sons, Inc., Indianapolis, Indiana. Responsibility for the accuracy of the
translation rests solely with Novatec Editora Ltda and is not the responsibility of John Wiley & Sons, Inc. No
part of this book may be reproduced in any form without the written permission of the original copyright holder,
John Wiley & Sons Inc.
Todos os direitos reservados. Traduo autorizada da edio em ingls intitulada Android Design Patterns Copyright
2013 by John Wiley & Sons, Inc., Indianapolis, Indiana. A responsabilidade pela preciso da traduo exclusiva
da Novatec Editora Ltda e no de responsabilidade da John Wiley & Sons, Inc. Nenhuma parte deste livro pode
ser reproduzida em qualquer formato sem a autorizao por escrito do titular original do copyright, John Wiley
& Sons, Inc.
Novatec Editora Ltda. 2013.
Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. proibida a reproduo desta obra, mesmo
parcial, por qualquer processo, sem prvia autorizao, por escrito, do autor e da Editora.
Editor: Rubens Prates
Traduo: BrodTec.com
Reviso tcnica: Aurelio Jargas
Reviso gramatical: Cristiane Bernardi
Editorao eletrnica: Carolina Kuwabata
ISBN: 978-85-7522-358-1
Histrico de impresses:
Agosto/2013 Primeira edio
Novatec Editora Ltda.
Rua Lus Antnio dos Santos 110
02460-000 So Paulo, SP Brasil
Tel.: +55 11 2959-6529
Fax: +55 11 2950-8869
Email: novatec@novatec.com.br
Site: www.novatec.com.br
Twitter: twitter.com/novateceditora
Facebook: facebook.com/novatec
LinkedIn: linkedin.com/in/novatec
MP20130812
24
PARTE I
Princpios de UX e
consideraes sobre o
Android OS
Captulo 1 Projetando para o Android: um estudo de caso
Captulo 2 O que torna o Android diferente
Captulo 3 Fragmentao do Android
Captulo 4 Processo de projeto de aplicativos mveis
25
CAPTULO 1
Projetando para o Android: um
estudo de caso
Este livro sobre coisas que funcionam: padres de projeto. Os padres
de projeto deste livro so construdos com base nas recomendaes de
projetos ociais do Google Android, que indicam as melhores prticas
ao mesmo tempo em que atendem s complexidades envolvidas em
problemas reais de projetos. As recomendaes ociais do Android,
disponveis em http://developer.android.com/design/get-started/ui-overview.html,
so a sua base; este livro mostra como dar vida a essas recomendaes,
na forma de solues completas para desaos reais de projetos.
Neste captulo, apresento a base para os 58 padres (e os 12 antipa-
dres) que constam neste livro, por meio de um estudo de caso de um
aplicativo que poderia ser beneciado por um projeto mais renado a
aplicao AutoTrader. Os padres apropriados so referenciados em
cada seo deste captulo; sinta-se vontade para consultar as pginas
relevantes e explorar as solues de projeto mais detalhadamente.
Padres de Projeto para o Android
26
O aplicativo AutoTrader o tpico exemplo de um porte direto, quer dizer, ele ,
basicamente, uma aplicao do iOS que foi rpida e minimamente feita para traba-
lhar no Android. As sees a seguir mostram como remodelar esse aplicativo para o
Android 4.0+ (Ice Cream Sandwich). No ser coberta toda a aplicao, j que seria
excessivamente entediante escrever sobre isso (e seria um tdio ainda maior ler).
Ao invs disso, trs telas representativas sero discutidas: a tela principal com um
formulrio de busca, a tela com os resultados de busca e a tela de detalhamento do
item. Essas telas devem dar uma boa ideia de alguns aspectos nicos e interessantes
do projeto visual do Android e a navegao nele. Elas tambm sero uma introduo
para os padres de projeto de interao deste livro. Pense neste captulo como um
aperitivo do rico banquete de solues prticas que esperam por voc na parte II.
O cone de lanamento
O primeiro item a observar o cone de lanamento. A maioria das aplicaes que
so um porte direto do iOS negligenciam a essencial tarefa de remodelar esse cone.
O cone de lanamento do Android no limitado pelo formato quadrado com
bordas arredondadas do iOS. Os projetistas so encorajados a dar a seus cones
de lanamento para o Android um formato distinto de bordas. Observe os cones
usados para o Yelp e o Twitter na gura 1.1 (seus desenhistas souberam faz-lo).
Em contraste, o aplicativo AutoTrader, objeto deste estudo de caso, no recebeu a
dedicao devida para a personalizao de seu cone. Felizmente, essa , frequen-
temente, uma modicao simples. No caso do AutoTrader, uma remodelagem
sugerida est inclusa na gura 1.2. Voc poderia utilizar a letra A, emprestada do
aplicativo vindo do iOS, e remover seu preenchimento de fundo para criar uma
forma distinta. Voc no est limitado a usar alguma parte do logotipo original
por exemplo, o cone poderia ter o formato de um carro ou de um volante de
carro. Como o olho percebe mais prontamente o formato do cone quando ele
diferente do de outras aplicaes, os clientes do AutoTrader poderiam identicar
a aplicao mais rapidamente em uma longa lista.
Barras de aes e arquitetura de informao
Em geral, as barras de aes e suas respectivas funes formam a espinha dorsal
de uma aplicao, e so importantes em seu projeto global. Infelizmente, o pro-
jeto atual da aplicao AutoTrader deixa muito a desejar nesse quesito (e o que
torna este estudo matador).
27
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.1 Os cones de lanamento do Yelp e do Twitter possuem formatos
diferenciados.
Figura 1.2 O cone de lanamento original do AutoTrader no distintivo; assim, aqui
est um cone remodelado.
Antes
Repare na tela padro principal: a busca por um carro. A funo do menu que
recebe mais nfase Settings (conguraes), apresentada com destaque no can-
to superior direito (Fig. 1.3). Essa posio , indiscutivelmente, o segundo mais
importante e proeminente ponto na interface de usurio do dispositivo mvel
(o primeiro ponto mais proeminente o canto superior esquerdo, ocupado pelo
grande logotipo).
Padres de Projeto para o Android
28
Ainda que seja admirvel a tentativa de destaque da funo Settings, eu, infe-
lizmente, no consigo imaginar um caso de uso primrio ou secundrio que a
envolva. Especialmente porque o que est marcado como Settings no nada
mais do que um local reservado para banalidades legais, como a poltica de
privacidade, o contrato com o visitante e um boto para a comunicao atravs
de email dicilmente essa a funcionalidade essencial que a aplicao precisa
mostrar to proeminentemente!

Figura 1.3 O aplicativo AutoTrader enfatiza a intil funo Settings no projeto de sua
tela principal.
Em contraste com o super enfatizado boto Settings, as funes essenciais que
precisam ser utilizadas, aquelas relativas a encontrar carros, vendedores, a listar
e procurar, e s funes e buscas personalizadas do usurio (My AutoTrader),
esto escondidas na barra do menu de navegao, no antigo estilo do Android
2.3 (Fig. 1.4).
A prxima seo descreve como o aplicativo poderia ser remodelado, conforme as
diretrizes do Android 4.0, usando as barras de aes de forma efetiva e tornando
mais proeminentes as funes mais importantes.
29
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.4 O aplicativo AutoTrader coloca suas funes essenciais na barra do menu de
navegao, no estilo antigo, o que constitui um antipadro.
Depois
O primeiro conserto a ser feito no estilo dos botes. Os cantos arredondados
e chanfros devem ser, simplesmente, eliminados, e as funes identicadas por
palavras, como Settings, devem sair da barra de aes. No Android 4.0, as aes
presentes na barra de aes aparecem como cones e as aes do menu sobrepos-
to aparecem como texto. Mantendo esse esquema, a primeira sugesto levar
as funes do menu antigo para a barra de aes, como mostrado na gura 1.5.
Nessa verso, o boto Settings tornou-se o cone com o martelo e a chave inglesa, e
o menu de navegao inferior foi movido para o menu que se sobrepe tela na
barra de aes. O logotipo gigante da empresa foi substitudo por um do estilo
da barra de aes do Android 4.0 (combinando com o cone de lanamento no
formato da letra A) e o ttulo da tela. (Note que, de acordo com as diretrizes de
modelagem do Android, o ttulo da tela no deve exceder 50% da largura total
dela, o que no o caso aqui; isso apenas algo que voc deve ter em mente.)
Padres de Projeto para o Android
30
Figura 1.5 A verso 1 um porte direto para o Android 4.0, com conguraes e aes
no menu sobreposto.
Infelizmente, como discutido na seo Antes, essas mudanas no esto nem
prximas de serem sucientes. Essa remodelagem bsica lida com o porte da ar-
quitetura de informao para o Ice Cream Sandwich, mas no com as limitaes
da arquitetura da aplicao atual: funes chave, como a Find Dealers (encontrar
revendas) e My AutoTrader (opes e buscas personalizadas pelo usurio), ainda
esto escondidas, e o cone que substitui Settings, claramente, no de utilidade
alguma. Pior do que isso, a colocao do boto Settings na barra superior ir, de
fato, desencorajar a explorao do menu quando o cliente descobrir que essa
funo , basicamente, muito ruim. Isso enviar um forte sinal de que as demais
funes, escondidas no menu sobreposto, so ainda piores. E o design pode ser
mais aprimorado.
Uma abordagem possvel mover as funes Find Dealers e My AutoTrader para
a barra de aes superior e Settings para o menu sobreposto. A gura 1.6 mostra
como isso caria.
31
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.6 Na verso 2, as funes mais teis esto na barra de aes superior e a
funo Settings foi movida para o menu sobreposto.
Essa uma arquitetura de informao aceitvel e est de acordo com as reco-
mendaes para as verses Ice Cream Sandwich (4.0) e Jelly Bean (4.1) do sistema
operacional. Entretanto, isso aponta alguns desaos chave, da barra de aes, para
a implementao da especicao da interface de usurio atual. Por exemplo, na
maioria dos dispositivos, voc no pode ter mais que umas poucas funes na
barra de aes sem que isso tome mais que os 50% recomendados para o espao
disponvel. Alm disso, a colocao de mais aes em barras de aes adicionais
acaba roubando o espao vertical de que a aplicao precisa desesperadamente,
alm de gerar poluio visual e complexidade. Essa no uma considerao, que
possa ser, facilmente, descartada.
O desao principal cognitivo: nem toda ao pode ser, facilmente, representada
com apenas um cone. Por exemplo, na gura 1.6, utilizei ambos os cones originais,
Find Dealers e My AutoTrader. Mesmo que nenhum deles seja ruim, eles podem,
facilmente, ser interpretados de forma errada, assim como todos os cones con-
cebidos para representar aes complexas ou no usuais. Voc poderia remover
todos os cones e colocar todas as aes no menu sobreposto, mas essa soluo
tambm est longe de ser a ideal, j que ela exige que todos os itens do menu
sejam puramente texto. Quando voc usa apenas texto, perde o aspecto ldico que
Padres de Projeto para o Android
32
os cones trazem computao mvel, o que ao menos para mim o corao
da navegao mvel. Eu percebo, repetidas vezes, que o uso de cones e texto em
conjunto torna a navegao muito mais efetiva. Quando os clientes utilizam, pela
primeira vez, um aplicativo, eles dependem de ambos os aspectos da navegao.
Depois que o esto utilizando por algum tempo, o cone frequentemente oferece
a carga de informao suciente para garantir o reconhecimento da ao que ele
representa. E o Android? Oferece alguma forma de usar tanto cones como texto,
em conjunto?
Afortunadamente, a recente remodelagem do aplicativo Google Plus aponta a
forma de utilizar tanto cones como textos por meio do elemento Drawer (ga-
veta), como visto na gura 1.7. O Drawer e outros padres de navegao do tipo
de Canivete suo so abordados no captulo 13, Navegao; dessa forma, no
necessrio tratar deles aqui. Basta dizer que a interface de usurio do elemento
Drawer permite o uso tanto de cones como de texto o melhor de dois mundos.
Figura 1.7 O projeto do aplicativo Google Plus utiliza um menu Drawer que inclui
tanto texto como cones.
A especicao da interface de usurio do Android encoraja o uso do elemento
Drawer para a navegao de mais alto nvel, caso exista um nmero de visualiza-
es, no aplicativo, que no tenham uma relao direta entre si. Esse exatamente
33
Captulo 1

Projetando para o Android: um estudo de caso

o caso do AutoTrader. A rea Car Search da aplicao diferente das visualizaes
Find Dealer e My AutoTrader; assim, colocar essas funes de navegao de mais
alto nvel no menu Drawer (mostrado na verso 3 da remodelagem, na gura 1.8)
faz muito sentido. A funo Scan & Find relativa busca por automveis, ento,
faz sentido torn-la contextual visualizao Car Search. Ela acessada com um
simples toque na barra de aes. A funo intil (mas, como os advogados podem
argumentar, necessria) Settings a nica escondida no menu sobreposto; ela
no precisa ser acessada com apenas um toque e, por isso, escond-la a melhor
estratgia.
Figura 1.8 A verso 3 a recomendada para o aplicativo AutoTrader: uma
remodelagem de alto nvel que usa o menu Drawer.
A verso 3 o modelo preferido. Ela encontra um bom equilbrio ao mostrar tanto
os cones quanto o texto, ao mesmo tempo em que torna a navegao acessvel ao
permitir o deslizamento da direita para a esquerda ou um toque no cone Voltar
(o sinal de menor ou ). Isso tambm libera espao na barra de aes superior,
permitindo a incluso de um ttulo de tela limpo e de bom tamanho. Uma mo-
dicao recomendada para as diretrizes padro do Android uma linha na ao
longo de toda a borda esquerda da tela, sinalizando aos usurios que eles podem
abrir o menu Drawer deslizando o dedo na tela, da direita para a esquerda (assim
como ao clicar no cone Voltar).
Padres de Projeto para o Android
34
De acordo com as diretrizes de interface de usurio do Android, o Drawer pode
ser usado apenas para a navegao em nvel superior, o que signica que enquanto
seus clientes esto no meio de um uxo dentro da visualizao Car Search, eles
podem estar uma ou mais etapas alm do acesso a visualizaes adicionais. A
boa notcia que com a navegao global fora do caminho a barra de aes
pode incluir funes que estejam no contexto da pgina onde navegam, o que
recomendado no documento de padres de projeto do Android.
Abas
As abas (tabs) so um elemento essencial navegao secundria e podem ser
usadas em uma variada forma de aplicaes na plataforma Android. O padro
Tabs abordado no captulo 8, Ordenao e ltragem.
O aplicativo AutoTrader usa o estilo visual do projeto do iOS, exibindo as abas
com cantos arredondados, mas com a aparncia de um chanfro em baixo relevo
para a aba selecionada (Fig. 1.9).
Figura 1.9 A parte de cima mostra as abas do aplicativo AutoTrader antes da
remodelagem sugerida; a parte de baixo o tratamento proposto para o Android 4.0.
Adote uma remodelagem simples para esse controle, utilizando um sublinhado de
m a m, sem sombras, chanfros ou cantos arredondados. O elemento com mais
sublinhado sinaliza a aba selecionada. Nessa tela, h apenas espao suciente
para etiquetas de texto compactas (Basic | Advanced | Recent em portugus,
bsico, avanado e recente, respectivamente). Essa foi a forma utilizada na remo-
delagem sugerida.
Mas se a tela for menor do que o suciente para acomodar, confortavelmente, o
texto completo nas abas? A as etiquetas de texto se transformaro em abas ba-
seadas em cones correspondentes. Como voc ler no captulo 2, O que torna o
Android diferente, a escalabilidade da execuo da interface e dispositivos com
telas sensveis menores so o grande diferencial do sistema operacional Android.
Essa escalabilidade, por sua vez, dita muitas das escolhas e diretivas do projeto
visual bsico.
35
Captulo 1

Projetando para o Android: um estudo de caso

Pgina de seleo dedicada
A pgina de seleo dedicada (Dedicated Selection Page) o padro primrio para a
seleo a partir de uma longa lista. Ela ser abordada mais detalhadamente no
captulo 12, Servios bancrios para dispositivos mveis. O aplicativo AutoTra-
der usa o estilo de seleo do iOS, com o sinal de maior (ou o smbolo da seta
apontando para a direita: ), como pode ser visto no topo da gura 1.10.
Figura 1.10 O topo da gura mostra o link para a pgina de seleo dedicada antes da
remodelagem; sua parte de baixo o tratamento sugerido para o Android 4.0.
O iOS usa o para mostrar a interatividade baseada em linhas. Em contraste, no
sistema operacional Android, no existe a indicao dessa funcionalidade subja-
cente. Como discutido no captulo 2, o conceito de toque em qualquer lugar (Tap
Anywhere) importante no sistema Android. Se h qualquer razo para tocar
em qualquer coisa, como um seletor, presume-se que ele possui a interatividade
correspondente. Assim, o projeto visual implementado de acordo com o jeito
espartano do Android, utilizando um fundo levemente mais escuro na linha, sem
o sinal de maior.
Seleo e controle
A plataforma Android fornecida com um total complemento de controles amig-
veis ao toque, que voc pode usar em telas de mltiplos tamanhos e conguraes
de dispositivos. O Ice Cream Sandwich vem totalmente equipado com controles
deslizantes, uma entrada de texto completamente remodelada e uma nova roleta
de controle com dupla funo, todos discutidos detalhadamente no captulo 10,
Entrada de dados. Para esta seo, suciente dizer que o porte do AutoTrader
para o Android ainda utiliza o formato no estilo iOS em seus controles e cabea-
lhos de seo em formulrios. As sees a seguir descrevem como remodel-los,
no estilo Android.
Padres de Projeto para o Android
36
Antes
O primeiro item a observar a roleta de controle composta, no estilo iOS, que
o cliente usa no aplicativo AutoTrader para selecionar o ano e o preo (Fig. 1.11).

Figura 1.11 O aplicativo AutoTrader usa um formato no estilo iOS para a seleo do
ano e do preo.
O controle do iOS uma roleta no nativa, que precisa mudar para o estilo de con-
trole do Android. Verique algumas ideias a esse respeito na prxima seo, Depois.
Outro aspecto importante desse modelo de formulrio seu receptculo (con-
tainer) arredondado para os campos de entrada, com um cabealho de seo no
estilo do iOS. Como discutido no captulo 2, o Android utiliza o princpio de
estilo visual espao mvel, sem limites (Mobile Space, Unbound), que remove
quaisquer containers e caixas, especialmente os de cantos arredondados.
Depois
Como discutido no captulo 10, h vrias maneiras amigveis ao toque para im-
plementar a entrada de sries de valores no Android. A mais direta a converso
da roleta composta em roletas distintas para a seleo de valores mximos e m-
nimos (marcadas por uma linha com um pequeno tringulo direita). A gura
1.12 mostra como isso pode parecer.
37
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.12 A remodelagem usa controles nativos do Android, no formato de roleta, e
um cabealho de seo.
Ainda que controles no estilo roleta ofeream uma soluo decente, voc pode
usar uma variedade de outros padres de projeto de interao. Os captulos 10 e
11 discutem um controle composto, no estilo de uma lista suspensa (drop down),
controles deslizantes distintos para valores mnimos e mximos, um controle
deslizante duplo e um controle deslizante com o padro de projeto experimental
Histograma (Histogram). A aplicao desses padres no complicada, mas um
trabalho sosticado, discutido detalhadamente na parte II deste livro. Os padres
so projetados especialmente para limitar os casos de resultados nulos na busca,
como escolher uma faixa de valores de preos que sejam baixos demais, ou no
existir estoque para o ano desejado. Esse o tpico discutido, detalhadamente,
no captulo 9, Evitando resultados nulos ou indesejados.
Os formulrios no Android 4.0 e 4.1 tm uidez para se ajustarem a uma variedade
de alturas e larguras de tela. Assim, ao invs de usar containers para as sees dos
formulrios, as vrias partes deles so separadas, umas das outras, por cabea-
lhos simples. Cabealhos nativos so exibidos em letras maisculas com a fonte
Roboto (a Helvtica usada em guras), sublinhados com uma linha divisria
na em uma cor contrastante.
Botes
O aplicativo AutoTrader usa botes no estilo iOS, com cantos arredondados e
chanfros. Os botes esto em duas diferentes alturas, com tratamentos visuais
tambm distintos e com muito espao entre eles, o que deixa a tela bastante as-
simtrica. Alm disso, os botes esto posicionados como Search/Reset (buscar/
limpar), em outras palavras, na ordem OK/Cancel (OK/Cancelar, como pode ser
visto na gura 1.13). Conforme descrito no captulo 11, Formulrios, a orientao
preferencial dos botes a oposta a essa (Cancel/OK); assim, a remodelagem
inverte os botes a partir de sua posio no leiaute anterior.
Padres de Projeto para o Android
38
Figura 1.13 Os botes atuais do AutoTrader so mostrados no topo da gura; na
remodelagem eles esto no meio dela e uma proposta alternativa, com as reas de toque
do Android, mostrada a seguir.
Em contrapartida, os botes do Android so de acordo com o estilo do mundo
de negcios: planos, sem gradientes e com cantos ligeiramente arredondados. O
tratamento preferido do Android para os botes Cancel/OK transform-los em
reas quadradas slidas, que ocupam 100% da largura da tela, com apenas uma
linha na usada como separador. As reas de toque sero discutidas adiante, no
captulo 2. Optei por enfatizar o boto de ao principal, Search, permitindo o toque
mais fcil nele ao torn-lo mais largo, e tambm adicionei uma lupa como cone.
Resultados de busca
Com a tela principal e a arquitetura de informao remodeladas, preste ateno,
agora, na tela de resultados de busca. Esses resultados aparecem imediatamente
aps a pesquisa feita, pelo usurio, no formulrio da tela principal; assim, isso
faz sentido.
Antes
Mais uma vez, a tela com os resultados de busca para o aplicativo AutoTrader
foi, de maneira geral, projetada sem sua adaptao para as diretrizes do sistema
operacional Android em suas verses Ice Cream Sandwich e Jelly Bean (Fig. 1.14).
A tela usa, principalmente, padres iOS, com uma pequena mistura de Android,
e nela so visveis trs botes: dois com texto e outro com um cone. Todos os
botes possuem cantos arredondados e chanfros. Alm disso, cada resultado na
tela apresenta o tratamento padro da seta do iOS (). Da mesma forma j ob-
servada na tela principal, o menu, no topo do aplicativo, pode ser obtido com o
toque na tecla de menu, na barra de navegao na parte inferior do dispositivo.
39
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.14 A tela de resultados de busca apresentada desta forma, antes de sua
remodelagem.
Depois
O menu de navegao de nvel superior, no estilo gaveta (Drawer), foi, segura-
mente, removido da tela com os resultados de busca. O toque no cone no canto
superior esquerdo leva de volta tela inicial, onde o usurio pode chegar ao menu
principal simplesmente tocando, novamente, o mesmo boto. Isso libera espao
na tela para os botes contextuais de ao: Filter, Map e Share (respectivamente
ltrar, mapa e compartilhar, conforme visto na gura 1.15).
A partir da verso Ice Cream Sandwich do sistema operacional, a funo Share
(compartilhar) ganhou um uso especial, em funo das mltiplas funes de
compartilhamento agora oferecidas. Assim, voc pode implementar a ao Share
na forma de um menu suspenso, de acordo com os padres de projeto da interface
de usurio do Android. Os botes restantes, Map e Filter, so implementados com
cones no estilo Android (planos, em cor nica) e posicionados direita na barra
de aes. Essa uma forma pela qual a relao entre mapas e listas pode ser im-
plementada. Padres muito mais efetivos para a busca e ltragem so discutidos
no captulo 7, Busca, e no captulo 8, Ordenao e ltragem.
Padres de Projeto para o Android
40
Figura 1.15 Esta a primeira verso da remodelagem da tela de busca do aplicativo
AutoTrader, com uma barra de ttulo.
Alm do tratamento da barra de ttulo na barra de aes, uma outra verso
possvel: um controle suspenso que pode ser usado para a seleo de mltiplas
visualizaes, neste caso, para diferentes maneiras de organizar o inventrio. Na
verso 2 da remodelagem, o ttulo da tela (fabricante e modelo do carro) exibido
acima do seletor suspenso das mltiplas formas de visualizao. Essa verso a
recomendada, j que adiciona uma funcionalidade chave ao aproveitar totalmente
as capacidades do Android 4.0 (Fig. 1.16).
preciso destacar a ausncia do smbolo da seta nos resultados de busca.
Como mencionado anteriormente, os espaos da tela devem permitir o toque
sem o uso de nenhum tipo de indicador visual especco. Se uma ao, como o
aprofundamento em telas de detalhamento dos resultados de busca, impor-
tante para o cliente, ela deve estar disponvel na forma de um alvo de toque sem
nenhum indicador visual externo. Falando nisso, tempo de ngir que algum,
realmente, tocou nos resultados de busca. A prxima seo descreve a terceira e
ltima tela: o detalhamento dos resultados.
41
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.16 A Verso 2.0, recomendada para a tela de busca do aplicativo AutoTrader,
adicionando um seletor de tipo de ordenao para as visualizaes.
Detalhamento dos resultados
O que acontece quando o cliente aprofunda sua navegao, chegando tela de
detalhamento dos carros? Esta ltima tela oferece muitas oportunidades para
uma nova remodelagem para o Android, desde a arquitetura da informao at
abas e botes.
Antes
A tela de detalhamento, como todas as anteriores, inclui, principalmente, elementos
nativos do iOS (Fig. 1.17). Como discutido anteriormente, as abas so baseadas
em texto e possuem chanfros e cantos arredondados. De forma similar tela de
resultados de busca, h um outro boto de compartilhamento; entretanto, nessa
tela, ele aparece duas vezes: uma na barra de menu superior e uma vez dentro da
tela, na forma de um boto Save/Share (salvar/compartilhar), o que se torna confuso.
Padres de Projeto para o Android
42

Figura 1.17 Assim apresentada a tela original de detalhamento de resultados do
aplicativo AutoTrader, antes de sua remodelagem.
Outras aes incluem o contato por telefone ou email com o vendedor, ainda que
nenhum boto possa ser identicado como o mais importante nesse conjunto
completo no est claro o que o aplicativo quer que o cliente faa primeiro. O
restante da tela construdo com containers de cantos arredondados, que devem
ir para o lixo, claro.
O mais importante que a nica maneira de navegar para o prximo item da
lista por meio do mtodo vai e vem: pressionar o boto Voltar para retornar tela
de resultados de busca e, ento, selecionar uma outra tela de detalhamento. (O
vai e vem Pogosticking um antipadro de navegao, descrito no captulo 13.)
Depois
Na verso remodelada dessa tela, mantenha o uso da navegao acima, com
a remoo da funcionalidade global de navegao. Mas para onde devem ir os
botes de ao e qual a melhor maneira de identicar a ao principal, aquela
que, mais provavelmente, ser executada pelo cliente? fcil entender uma forma
de implementar essa soluo no sistema operacional Android 4.0 ao observar a
tela da aplicao nativa, Gmail, para o Android (Fig. 1.18).
43
Captulo 1

Projetando para o Android: um estudo de caso

Figura 1.18 O aplicativo Gmail usa o controle deslizante para as visualizaes em sua
tela de detalhamento de resultados.
Para reduzir o vai e vem, a aplicao nativa do Gmail usa um controle inteligente da
interface do sistema operacional Android, visualizaes deslizantes (Swipe Views),
para tornar a navegao mais eciente. Esse controle permite ao usurio deslizar
seu dedo na tela, da direita para a esquerda, para obter os detalhes do prximo
resultado. Essa funcionalidade exibida ao cliente na forma de uma linha escura
e na, na parte de baixo da tela, que mostra 2 de 133. Mesmo que funcione,
a usabilidade dessa funo na descoberta de resultados mostrou-se pobre nos
testes. Dessa forma, para a remodelagem do aplicativo AutoTrader, voc deve usar
o breve tutorial sobreposto descrito no captulo 5, A experincia de boas-vindas,
ou um padro Watermark, de transio animada, descrito no captulo 13, para des-
tacar o controle de deslizamento de visualizaes para o usurio e melhorar a
experincia de descoberta dessa importante funcionalidade. Independentemente
da introduo de boas-vindas que voc optar por apresentar, o tutorial no mais
necessrio depois que o usurio compreende a ao, podendo ser suprimido. Por
isso esses padres no sero mostrados aqui.
Padres de Projeto para o Android
44
A ao de deslizamento, em alguns aplicativos, usada para navegar entre as
abas. Se voc quiser preservar a ao deslize para a prxima para navegar para o
prximo detalhamento de item, use apenas abas para o toque no topo da pgina,
como mostrado na gura 1.19.
Figura 1.19 assim que voc pode remodelar a pgina de detalhes do AutoTrader.
As aes contextuais primrias e secundrias podem, agora, ser colocadas na
barra de aes. Como existem apenas trs aes na pgina de detalhamento de
carros, voc precisa de uma nica barra de aes no topo, acomodando as trs
aes acima das abas, perto do ttulo da tela (o nome da listagem). Se voc pre-
cisar de mais espao em dispositivos pequenos, ou se interaes futuras no pro-
jeto adicionarem mais funcionalidade, algumas das aes da pgina de detalhes
podem migrar para um menu sobreposto ou para a barra de aes dividida (esta
ser abordada no prximo captulo). Por ltimo, mas no menos importante,
remova todos os containers da tela, substituindo-os com os cabealhos Android
4.0, seguindo o princpio do espao mvel sem limites (Mobile Space Unbound)
discutido no captulo 2. Note que o modesto uso do espao permite que a tela
remodelada mostre linhas adicionais de texto algo muito importante em telas
de dispositivos mveis!
45
Captulo 1

Projetando para o Android: um estudo de caso

Juntando tudo
A gura 1.20 mostra trs telas do AutoTrader antes da remodelagem sugerida.
Repare na arquitetura da informao anterior e no tratamento de controles,
campos e botes no estilo iOS. As sees de telas so separadas umas das outras
por containers com cantos arredondados. Dentro de cada seo, os elementos
que implementam interatividade so especialmente acionados pelo smbolo ,
para separ-los visualmente dos elementos no interativos, dando uma aparncia
pesada ao estilo visual geral.
Figura 1.20 assim que as trs telas do AutoTrader so apresentadas, antes de sua
remodelagem.
A gura 1.21 mostra as trs telas remodeladas, j imbudas do DNA do Android 4.0.
Na remodelagem, foram usados um conjunto especializado de controles por
toque e um esquema uniforme de navegao, recomendados pelas diretrizes do
Android 4.0. Na perspectiva visual, o novo projeto usa botes planos, painis de
toque e barras de aes que, acima de tudo, no fazem uso de gradientes e cantos
arredondados. Finalmente, o novo projeto remove containers e indicadores de
toque desnecessrios.
Padres de Projeto para o Android
46
Figura 1.21 As trs telas do AutoTrader, remodeladas para o Android 4.0.
Durante o processo, voc examinou vrias verses diferentes de cada tela. Isso
natural: o projeto com o Android no complicado, mas bastante sosticado, com
restries extremas de espao e novas e excitantes oportunidades de interao.
Por isso, devem ser realizados testes completos de uso de novas ideias de projeto
antes de sua implementao, utilizando prottipos rpidos e baratos. Eu prero
fazer a prototipagem e os testes com notas adesivas. Neste livro, voc ver muitos
exemplos de uso dessa metodologia de modelagem. O captulo 4, Processo de
modelagem mvel, fornece uma descrio detalhada de todo o processo de mo-
delagem e prototipagem e apresenta tcnicas prticas para a abordagem de testes
de uso com conana.
O AutoTrader ofereceu uma grande oportunidade de mostrar os detalhes dos
componentes e da linguagem de projeto visual do Android, servindo como um
poderoso exemplo para o pontap inicial deste livro.
Ainda assim, essa apenas uma viso geral dos muitos padres de projetos ino-
vadores, interessantes e teis encontrados no Android. Antes do aprofundamento
nos padres de projeto que formam a maior parte do material deste livro, o pr-
ximo captulo aborda supercialmente alguns poucos aspectos do Android que
o diferenciam de outros sistemas operacionais para dispositivos mveis.