Blog oficial para desenvolvedores que falam português
Participe da primeira sessão de App Review no Android Developers Live Brasil! (Office Hours)
26/07/2012
A partir do hangout da próxima quinta-feira 02/08, o Android Developer Office Hours Brasil passará a se chamar
Android Developers Live Brasil
e passaremos a ter conteúdo mais variado. No hangout de quinta-feira 02/08, faremos a nossa primeira sessão de
App Review
, onde daremos nossa opinião e faremos uma avaliação de aplicativos enviados por desenvolvedores!
Essa é uma ótima oportunidade para você ter o seu aplicativo avaliado pela nossa equipe e receber dicas de como melhorá-lo. Caso esteja interessado, por favor indique seu aplicativo
através desse formulário
até quarta-feira 01/08, 12:00.
Junte-se a nós no Android Developers Live Brasil #05 na
quinta-feira 02/08
, no horário habitual (das
19:00 às 20:00
). Além de fazer a avaliação dos apps enviados, também responderemos a perguntas ao vivo como sempre fazemos!
Para participar, adicione o
+Bruno Oliveira
no Google+ e fique atento aos posts no horário do hangout!
Você também pode acompanhar o hangout ao vivo através do
Google Developers Live
. Como sempre, gravaremos o hangout e posteriormente publicaremos no Youtube.
Postado por Bruno Oliveira, Android Developer Relations, Google Brasil
Dicas para Aplicativos Android
24/07/2012
Meu nome é Bruno Oliveira e trabalho com Android Developer Relations no Google Brasil. Boa parte do meu trabalho envolve orientar desenvolvedores que estão criando aplicativos para Android e fico muito feliz sempre que tenho a oportunidade de melhorar um app que já existe ou dar conselhos para melhorar o projeto de um app antes do seu lançamento. Pensei em escrever esse blog post falando um pouco sobre os erros comuns que vejo nos apps que reviso, para que essas informações sejam úteis para o maior número de desenvolvedores possível.
1. Atenção ao design.
Se você é como eu (engenheiro, gosta de escrever e debugar código, não sabe direito como combinar cores e tem uma grande dificuldade de desenhar qualquer coisa que não seja uma figura de palitinhos), você provavelmente tem noções muito rudimentares sobre o que pode ser considerado uma interface "bonita" e uma interface "feia". Não pense que isso é um assunto fácil: para fazer uma interface bonita, é necessário entender muito bem sobre tipografia, equilíbrio de cores, espaçamento entre componentes, hierarquia visual e até mesmo a psicologia que respalda a escolha de certas cores e formas para associação com cada significado. Em outras palavras, você precisa de um excelente design. Mas quem pode nos ajudar com isso? Dica: um designer. Se você está fazendo o app como um hobby, convide um(a) amigo(a) designer para participar; se você está fazendo um app profissionalmente, contrate ao menos 1 designer.
2. Android é Android.
Ao projetar seu app, lembre-se que os apps no Android devem ter um estilo e comportamento próprio do Android. Não tente imitar outra plataforma: os apps que tentam imitar o visual ou comportamento de outros sistemas operacionais são invariavelmente apps de baixíssima qualidade no Android. Recomendo uma leitura completa do
Guia de Estilo
, que explica em detalhes qual deve ser a aparência e comportamento de aplicativos no Android.
3. Esqueça os pixels.
As telas no Android não são medidas em pixels. Ok, até são, mas pixels não significam nada. Não planeje que "esse botão vai ter 200 pixels por 80 pixels", porque isso fará o botão ter um tamanho físico diferente em cada dispositivo. Não somente cada dispositivo tem um número diferente de pixels, mas eles têm densidades diferentes, o que significa que não há como prever qual será o tamanho físico de um retângulo de 200x80 pixels. A medida mais estável para se utilizar é o
dp
(density-independent pixel), que tem o mesmo tamanho físico em qualquer tela. Faz sentido dizer que um botão tem 200x80
dp,
pois isso tem um tamanho físico definido. Claro que a relação entre esse tamanho e o tamanho da tela ainda variará de dispositivo para dispositivo, e você deve ter cuidado para que isso sempre faça sentido -- uma boa prática é ter layouts diferentes para tamanhos diferentes de tela.
4. O usuário já sabe usar o seu app... se você não complicar.
O usuário usa muitos apps no seu dia-a-dia, então ele está constantemente sendo treinado nos padrões do Android. A cada vez que o usuário usa o GMail, o Youtube ou o Maps, o hábito dele com os padrões de interface e navegação do Android se solidifica mais. Portanto, se você usar os mesmos padrões, o usuário nem precisará pensar em como usar o seu app -- tudo será perfeitamente natural. Só não será natural se você resolver complicar a vida do usuário inventando um padrão de navegação novo que ele nunca viu antes, o que vai exigir que ele o aprenda, e isso frequentemente é uma barreira suficiente para fazer o usuário desistir de usar um app. Portanto, a dica é: não force o usuário a aprender um padrão novo, use os padrões que já existem.
5. Use a Action Bar.
Falando em padrões importantes, recorrentes e intuitivos, há um que não pode faltar no seu app: a
Action Bar
. A Action Bar é uma solução para fornecer identidade, navegação e acesso a ações frequentes de uma maneira que o usuário já está acostumado. Se o seu app é um daqueles que tem telas onde o usuário pode fazer coisas, a Action Bar é para você. Se o seu app não é desse tipo... você me deixou curioso.
6. O que colocar no título de cada tela na Action Bar?
Esse tópico é muito importante. Há desenvolvedores que colocam o nome do app como título na Action Bar em todas as telas. Ok, os usuários podem até ser esquecidos, mas não precisamos chegar a tanto. É suficiente que a tela inicial do seu app mostre o título; quando o usuário está em telas secundárias, o título na Action Bar deve ser o título dessa tela secundária. Um exemplo: se o seu app mostra informações esportivas, a Action Bar da tela inicial (e só da tela inicial) tem o seu logotipo e o nome do app. Agora, numa tela secundária onde você mostra os resultados do Campeonato XYZ 2012, o título que aparece na Action Bar deve ser "Campeonato XYZ 2012", juntamente com o ícone do seu app. Não esqueça de colocar o "up affordance", que é aquela seta apontando para a esquerda na Action Bar, que permite ao usuário navegar "para cima" e voltar à categoria mais geral.
7. Se o usuário quer focar em algo, não o distraia.
O usuário tem dois "modos": focado e distraído. Quando o usuário acaba de entrar no seu app, provavelmente está no modo "distraído" -- você pode (e deve) sugerir atividades para ele. Sugira conteúdo, tenha uma tela de conteúdo em destaque, ponha links para levar o usuário a descobrir novas funcionalidades do app. Agora, quando o usuário aperta um botão, ícone ou qualquer outra coisa, é porque o usuário está interessado naquilo que ele clicou. Se o seu app é um app de esportes e o usuário clicou em badminton, é porque ele está interessado em badminton. Nesse caso, faça com que a tela esteja inteiramente focada no que ele quer: badminton. Não coloque tabs ou spinners para permitir ao usuário "mudar de esporte". Ele não quer mudar de esporte. Ele quer badminton. Se ele cansar de badminton e quiser outra coisa, ele usará a tecla back do dispositivo ou o botão "up" da Action Bar (não deixe de ler cuidadosamente o capítulo sobre
navegação
). Isso nos leva ao próximo tópico...
8. Não ponha botões para tudo em todas as telas.
Às vezes ouço argumentos de que é bom colocar botões para tudo em todas as telas para reduzir "o número de cliques" para fazer algo. Este poderia ser um conselho útil em apps para desktop, onde o espaço é abundante. Porém, numa tela de dispositivo móvel (mesmo tablets), o espaço é muito precioso. Nesse caso o modelo "drill-down" é muito mais apropriado, onde o usuário vai selecionando o que lhe interessa e volta para cima quando quer uma visão mais geral. Apps que levam essa filosofia de "número de cliques" ao extremo fazem aquelas telas que têm mais botões que uma cabine de um avião, tornando a vida do usuário extremamente complicada.
9. Cuidado com gráficos de baixa resolução.
Os telefones e tablets de hoje têm resoluções impressionantes, alguns chegando a mais de 320 DPI. Isso significa que você deve sempre fazer seus recursos gráficos de maneira que eles tenham uma boa aparência em todas as telas, inclusive as de mais alta resolução. Sempre forneça assets em LDPI, MDPI, HDPI e XHDPI. O que acontece se você não faz isso? O sistema automaticamente fará a única coisa que ele pode fazer: usar um recurso de baixa resolução e redimensionar, resultando em gráficos distorcidos e com artefatos. Se você está tentando produzir um app profissional e bem acabado, a ilusão acaba ali.
10. Não bloqueie tudo só para carregar algo.
Há apps que bloqueiam a tela inteira quando vão fazer ou carregar algo. O usuário inocentemente clica num botão e de repente a tela inteira fica escura e aparece um spinner no meio da tela dizendo "Carregando." Claro que isso já é muito melhor do que apps que nem sequer dizem que estão carregando e ficam "congelados", mas mesmo assim esse comportamento pode ser muito irritante. Lembre-se que sempre que a tela fica escura e a interface fica bloqueada, o usuário se sente interrompido. Isto só deve acontecer em casos muito sérios, como por exemplo um prompt crítico, no qual o usuário está prestes a apagar todos os seus dados ou fazer alguma outra coisa irreversível e muito grave. Nos outros casos, o app deve carregar os dados em background, sem bloquear a interface.
11. Não faça o usuário tomar decisões desnecessárias.
Na medida do possível, o app deve fazer a coisa certa em qualquer situação, sem que o usuário precise fazer nada. Um exemplo: se o app depende de sincronização de dados com seu servidor, é tentador colocar um botão no app que alterna entre o "modo online" e o "modo offline", para que o usuário possa usar o app com ou sem conexão. A pergunta é: o usuário realmente precisa fazer essa escolha? Não seria melhor se o app detectasse sozinho se existe ou não uma conexão, e se comportasse apropriadamente para cada caso, sem pedir para o usuário controlar isso com um botão para mudar de "modo"? Pense no GMail: o app do GMail não precisa perguntar para o usuário se ele quer usar o "GMail Online" ou "GMail Offline". Ele simplesmente faz a coisa certa: se está online, ele manda emails; se está offline, ele guarda o email numa outbox para mandar depois. E não chateia o usuário perguntando se ele quer ou não mandar o email que está na outbox.
12. Não peça para o usuário avaliar o app no Google Play após 5 segundos.
Se o usuário acabou de instalar o app e o está usando há poucos instantes, provavelmente não tem uma opinião formada sobre o app ainda. Pouco adianta sugerir que ele avalie o app no Google Play. Aliás, é até perigoso: o usuário pode aceitar o seu convite e dar uma baixa avaliação porque se sentiu interrompido. Especialmente se isso acontece toda vez que o usuário roda o app.
Espero que essas dicas sejam úteis para os seus apps!
Postado por Bruno Oliveira, Android Developer Relations.
Labels
+page
1
20th Century Fox
1
A/B
1
Action
1
Action Console
1
Actions
3
Actions Console
1
Actions on Google
1
ActiveQA
1
Adaptive Battery
1
AddThis
1
ADK
1
ADL
1
Admin do Firebase
1
AdMob
6
Ads
2
AdWords
1
AdX
1
AI
4
algoritmo
1
AMP
6
AMP Linker
1
AMP Project
1
Analytics API
1
Android
58
Android 8.0 Oreo
1
Android 8.1
1
Android ADK
2
Android API
2
Android App Bundle
1
Android Dev Summit
1
Android Developers
23
Android Marshmallow
1
Android N
3
Android Nougat
2
Android P
3
Android P Beta 2
1
Android Preview
1
Android SDK
1
android studio
8
Android Studio 3.2
1
android wear
2
AndroidDev
6
AndroidX
1
Announcement
2
AoG
1
AoGDevs
1
api
15
API 25
1
API 28
1
APIs
4
Aplicativos
4
app
1
App Engine
1
Apple
1
apply
1
Apps
9
AR
1
ARCore
3
artificial intelligence
1
AsyncTask
1
AUC
1
AutoAugment
1
Avro
1
Awareness API
1
Biblioteca do Google
1
Big Data
1
BigQuery
1
BiometricPrompt
1
bitcode
1
Borg
1
Bot
1
bytecode Dalvik
1
C++
1
câmera
1
CameraDevice
1
Canal Beta
1
canary
1
câncer de próstata
1
Capital One
1
Cast
1
CFI
1
Chrome
8
Chrome 68
1
Chrome Dev Summit
1
Chrome DevTools
1
Chrome OS
2
Chromecast
1
Chromium
2
CI
1
CLI
1
Cloud
6
Cloud Computing
1
Cloud Console
1
Cloud Dataflow
1
Cloud Developers
2
Cloud DLP
1
Cloud Firestore
1
Cloud Messaging
1
Cloud ML Engine
1
Cloud Scheduler
1
Cloud Shell
1
Cloud Source Repositories
1
Cloud Spanner
2
CodeSchool
1
código aberto
2
Compute Engine
1
ConfigMap
1
Container Builder
1
CPU
2
Crash Reporting
2
Crashlytics
3
credential api
1
criptografia
1
CSS
3
CSS Grid Layout
1
CSV
1
CTA
1
Curitiba
1
Dart API
1
Data Validation
1
DBAs
1
DCGAN
1
Desenvolvedores Google
11
Desenvolvimento
3
DevBusBrasil
1
DevBytes
2
Developer Bus
1
Developer Preview
1
developer quiz
1
DevFest
3
DevFest16
1
DevFest18
1
DevFestW
1
DFP
2
Dialogflow
1
DLP
1
DLS
1
documentação
1
Dragon Ball Legends
1
E2E
1
eclipse
1
end-to-end-encryption
1
Estimator
1
Estimators API
1
estudantes
1
Eventos
15
Famílias multilíngue
1
FCM
2
Featured
1
Firebase
24
Firebase Analytics
6
Firebase App Indexing
2
Firebase Cloud Messaging
5
Firebase Crashlytics
2
Firebase Dynamic Links
3
Firebase In-App Messaging
1
Firebase Invites
2
Firebase Lab
1
Firebase Links Dinamicos
1
Firebase Notifications
3
Firebase Remote Config
1
Flutter
3
FRR
1
G+
1
game
1
game dev
3
Games
2
games services
1
GCloud
3
GCM
1
GCP
7
GDD
7
GDE
1
GDEs
1
GDG
12
GDG Curitiba
1
GDG Floripa
1
GDG OpenSampa
1
GDG Porto Alegre
1
GDG Recife
1
GDG SP
3
GDGs
1
GDL
1
Git
1
GitHub
1
GNMT
1
Google
3
Google Ad Manager
1
Google AI
1
Google Analytics
1
Google Assistant
1
Google Assistente
3
Google Brain
2
Google Cast SDK
1
google clou
1
Google Cloud
17
Google Cloud Certified
1
Google Cloud Healthcare API
1
Google Cloud Platform
3
google code-in
1
Google Developer Advocate
1
Google Developer Expert
1
Google Developers
11
Google Fotos
1
Google I/O
6
Google Play
16
Google Play Games services
1
Google Play Protect
1
Google Play Services
4
Google Slides
1
Google Speech
1
google summer of code
1
Google+
2
Google+ sign-in
1
Googlers
1
GPU
2
GSuites
1
GUI
1
Hackathon
1
Hangouts
1
Hangouts Chat
1
HDR
1
High Quality Apps
2
HTML5
6
HTTP
3
HTTPS
2
HttpURLConnection
2
I/O
1
IA
2
Illusive Images
1
ImageReader
1
In-App Messaging
1
Inglês
1
Instant Apps
1
inteligencia artificial
1
IntelliJ REPL
1
IntentService
1
Interoperabilidade
1
IO Extended
1
IO13
1
iOS
9
IU
2
Java
1
Java 8
1
javascript
2
JPEG
1
JSON
2
Kaggle
1
kernel
1
Keyboard Map API
1
Knowledge Connectors
1
Kotlin
6
Kotlin da Udacity
1
Kubernetes
5
LangID
1
Launchpad
1
launchpad accelerator
2
Learning Augmentation
1
LEGO
1
Listas
1
ListFragment
1
LLVM
1
LTO
1
Machine Learning
2
Meetup
2
mensagens
1
Mentoria
1
Messaging
2
microsserviços
1
ML
2
ML Kit
1
Mobile
3
Mobile Ads SDK
1
Monetização
3
Monetize
3
MySQL
1
Native
1
Navigation Architecture Component
1
NES
1
Neto Marin
2
Next Level Apps
2
Next Level Tips
2
NNLM
1
Node.js
2
Notificações
1
novembro azul
1
Number Genie
1
Nuvem Profissional
1
OAuth
2
OAuth2
1
Open Images Extended
1
open source
3
Options Menu
1
Options Menu virtual
1
Orkut
2
Payment Request
1
pesquisa
1
PHA
1
Phone Gateway
1
PII
1
pixel
1
Play Academy
1
Play Console
1
Play Services
1
Playtime 2018
1
plug-in AMP
1
Porto Alegre
1
Preact
1
PRIV
1
program
1
progressive web apps
2
Push Notification
2
Python
1
QA
1
RA
2
Raspberry Pi
1
RBDMS
1
React
1
recording apis
1
remarketing
1
Remote Config
2
research
4
ResultReceiver
1
reward
1
RNN
2
Robolectric 4.0
1
RV
1
Sceneform
1
SDK
4
SDK Manager
3
Security
2
Server
1
service worker
1
sign-in
1
Sliding Tabs
1
Smartronix
1
social
6
Spark
1
SRE
1
Stack
1
Stack Overflow
1
Startups
2
Storage
2
story
1
Support Library
1
SurfaceView
1
Svelte
1
switch
1
Tag Manager
1
Tag Manager 360
1
tensorflow
5
TensorFlow Hub
2
TensorFlow Lite
1
TensorFlow Transform
1
Test Lab
2
Testes
1
TF Hub
2
tf.keras
1
TFDV
1
TFX
1
TI essencial
1
toolkit
1
tradução
1
TTS
1
Udacity
1
Universal Apps
1
Universal Sentence Encoder
1
user experience
1
ux
1
VectorDrawable
1
Velostrata
1
Volley
1
vr
2
vulnerabilidades
1
vulnerabilidades do Google
1
vulnerability
1
web
2
web dev
2
WebKit
1
webservice
3
when
1
WordPress
1
WorkerDOM
1
YouTube
4
YouTube API
1
YUV
1
Zomato
1
Archive
2022
nov.
out.
jul.
jun.
mai.
abr.
mar.
fev.
jan.
2021
dez.
nov.
out.
set.
ago.
jul.
jun.
mai.
abr.
mar.
fev.
jan.
2020
dez.
nov.
out.
set.
ago.
jul.
jun.
mai.
abr.
mar.
fev.
jan.
2019
dez.
nov.
out.
set.
ago.
jul.
jun.
mai.
abr.
2018
dez.
nov.
out.
set.
ago.
jul.
jun.
mai.
abr.
mar.
fev.
2017
ago.
jul.
jun.
mai.
abr.
mar.
jan.
2016
dez.
nov.
out.
set.
ago.
jul.
mai.
mar.
2014
jul.
jun.
abr.
mar.
fev.
2013
dez.
nov.
out.
set.
ago.
jul.
jun.
mai.
mar.
fev.
jan.
2012
nov.
jul.
jun.
mai.
abr.
mar.
2011
nov.
set.
ago.
jul.
jun.
Feed
Follow @googledevbr
