Imagem de capa por Virginia Poltrack Esta é a terceira postagem da nossa série sobre navegação por gestos. Se você quiser acessar outra publicação, verifique a lista abaixo:
Na postagem anterior, finalizamos a conversa sobre como arrastar para as bordas. Nesta terceira publicação, falaremos sobre como processar todos os conflitos de gestos entre seu aplicativo e os novos gestos do sistema no Android 10 .
O que são os conflitos de gestos? Vejamos um exemplo. Aqui temos um aplicativo de reprodução de música que permite ao usuário arrastar a SeekBar para passar por diferentes pontos da faixa que está sendo tocada.
Infelizmente, a SeekBar está muito perto da área de gestos da tela inicial. Isso aciona o gesto de troca rápida do sistema, o que confunde o usuário.
O mesmo pode ocorrer em qualquer borda da tela com áreas de gestos. Há diversos exemplos comuns do que pode causar conflitos, como por exemplo: Gavetas de navegação (DrawerLayout ), carrosséis (ViewPager ), controles deslizantes (SeekBar ) e ações ao deslizar nas listas.
Isso nos leva à pergunta: como podemos corrigir esse problema? Para ajudar com essa questão, criamos um fluxograma que orientará uma das soluções.
Neste link Esperamos que as perguntas sejam autoexplicativas, mas caso você tenha dúvidas, responderemos a cada uma delas:
1. O aplicativo requer ocultação das barras de status e de navegação? A primeira pergunta serve para saber se o caso de uso principal do seu aplicativo exige ocultação das barras de status e/ou navegação. Ocultá-las significa tornar essas barras do sistema completamente invisíveis. Isso não significa que seu aplicativo ocupa o espaço de ponta a ponta ou algo semelhante.
Estes são alguns dos possíveis motivos para responder essa pergunta de forma afirmativa:
Alguns exemplos comuns de aplicativos que respondem afirmativamente a essa pergunta são jogos, players de vídeo, visualizadores de fotos e aplicativos de desenho.
2. O principal caso de uso da IU exige que o usuário deslize os dedos nas áreas de gestos ou próximo a elas? Ao responder essa pergunta, é possível saber se a IU contém elementos nas/próximo às zonas de gestos (voltar ou página inicial) que exigem que o usuário deslize os dedos sobre elas.
No caso de jogos, normalmente a resposta será “Sim”, já que:
Os controles na tela costumam ficar próximos às bordas esquerda/direta e perto da parte inferior da tela. Alguns jogos exigem que o usuário deslize os dedos sobre elementos que podem estar em qualquer lugar da tela, como no caso dos aplicativos de tabuleiro. Além dos jogos, estes são alguns exemplos comuns de IU que responderão de forma afirmativa a essa pergunta:
IUs de recorte de fotos em que a alça para arrastar fica próxima às bordas esquerda/direita da tela. Aplicativos em que o usuário pode desenhar sobre um espaço que cobre a tela do dispositivo. 3. As visualizações costumam ser usadas nas áreas de gesto ou próximas a elas? Esperamos que essa pergunta seja simples. Isso também inclui visualizações que cobrem a área de gestos e se estendem além da tela, como um DrawerLayout ou ViewPager grande.
4. A visualização exige que o usuário use os comandos de deslizar ou arrastar? Aqui, saímos um pouco do assunto sobre tato e começamos a abordar as visualizações individuais. No caso das visualizações em que você respondeu “Sim” para a pergunta 2, há alguma que exija que o usuário use os comandos de deslizar/arrastar sobre ela?
Há diversos exemplos em que a resposta para essa pergunta seria “Sim”: SeekBars , páginas na parte inferior ou até mesmo um PopupMenu (é possível arrastá-los para abrir).
5. A visualização completa ou a maior parte dela está disposta em áreas de gestos? Após respondermos à pergunta 4, agora queremos saber se a visualização completa ou a maior parte dela está disposta em uma área de gestos.
Caso sua visualização seja um contêiner rolável, como um RecyclerView , aborde essa questão de forma diferente: a visualização completa ou a maior parte dela está disposta em áreas de gestos em todas as posições de rolagem? Se o usuário puder rolar a visualização para fora da área de gestos, você não precisa fazer nada.
No gráfico acima, ao ver o exemplo em que carrosséis completos (ViewPager ) responderam negativamente a essa pergunta, é possível que você queira saber por que não há processamento nesse caso. Isso acontece porque as zonas de gestos esquerda/direita têm larguras comparativamente pequenas (o padrão é 20 dp cada) se comparadas à visualização. Normalmente, a largura da tela do smartphone na orientação retrato é de aproximadamente 360 dp, deixando por volta de 320 dp de largura para a tela visível em que o usuário pode deslizar os dedos livremente (ou seja, praticamente 90% ). Mesmo com o preenchimento e as margens internas, o usuário ainda poderá deslizar normalmente o carrossel.
6. Os limites da visualização se sobrepõem a alguma zona de gestos obrigatória? A última pergunta indaga se a visualização está disposta sobre alguma zona de gestos obrigatória. Na nossa postagem anterior do blog , dissemos que as zonas obrigatórias são as áreas da tela em que os gestos do sistema sempre recebem prioridade.
O Android 10 tem apenas uma zona de gestos obrigatória, localizada na parte inferior da tela. Ela permite que o usuário acesse a página inicial ou exiba os aplicativos recentes. Isso poderá mudar nas versões futuras da plataforma, mas por enquanto só precisamos pensar nas visualizações da parte inferior da tela.
Estes são alguns exemplos comuns:
Páginas na parte inferior não modais, uma vez que costumam se recolher como pequenas visualizações arrastáveis na parte inferior da tela.Um carrossel rolável horizontalmente na parte inferior da tela, como uma IU de pacote de adesivos. Agora que abordamos as perguntas, esperamos que você tenha chegado a uma das soluções. Portanto, veremos os detalhes de cada uma delas.
Nenhum conflito para gerenciar Começaremos com a “solução” mais fácil: simplesmente... nada a fazer! 🙌
Talvez ainda haja otimizações que você pode fazer (veja a seção abaixo). No entanto, é esperado que não ocorram grandes problemas no uso do seu aplicativo com o modo de navegação por gestos ativado.
Se o gráfico apontou esse resultado, mas você ainda acha que há um problema, entre em contato conosco . Podemos ter deixado algo passar.
Como remover as visualizações das áreas de gestos Como vimos na postagem anterior do blog , os encartes são enviados para informar ao seu aplicativo onde as zonas de gestos do sistema estão localizadas na tela. Um método que pode ser usado para resolver conflitos de gestos é remover todas as visualizações conflitantes das zonas de gestos. Isso é especialmente importante no caso das visualizações próximas à parte inferior da tela, uma vez que essa área á uma zona de gestos obrigatória, e os aplicativos não podem usar as APIs de exclusão nela.
Vejamos um exemplo. Esta é a IU do player de música que vimos anteriormente. Ela contém uma SeekBar posicionada na parte inferior da tela, o que permite ao usuário passar por diferentes pontos da faixa.
IU do player de música com uma SeekBar na parte inferior da tela No entanto, quando o usuário tenta passar para outro ponto da música, ocorre a seguinte situação:
Registro do gesto do sistema em conflito com a SeekBar Isso ocorre porque a zona de gestos inferior está sobreposta à SeekBar. Assim, o gesto da página inicial recebe a prioridade. Confira as zonas de gestos visualmente:
Solução simples A solução mais simples para esse caso é adicionar outras margens ou preenchimento para que a SeekBar seja deslocada para cima, fora da zona de gestos. Algo assim:
Se arrastarmos a SeekBar conforme esse exemplo, você perceberá que o gesto da página inicial não será mais ativado:
Demonstração da SeekBar, agora sem conflito com o gesto do sistema inferior Para implementar essa solução, precisamos usar os novos encartes de gestos do sistema , disponíveis na API 29 e a Biblioteca principal Jetpack v1.2.0 (atualmente em Alfa ). No exemplo, aumentamos o preenchimento inferior da SeekBar para corresponder ao valor do encarte de gesto inferior:
Pode ser interessante a você ler outra postagem do blog em que exploramos algumas maneiras de facilitar o uso dos WindowInsets :
WindowInsets: listeners para layouts
Mais informações Neste momento, é capaz que você pense: “tarefa concluída”. E realmente essa pode ser a solução final para alguns layouts. Mas no nosso exemplo, a IU regrediu com muito desperdício de espaço abaixo da SeekBar . Portanto, em vez de preencher a visualização para cima, podemos retrabalhar o layout para evitar o espaço desperdiçado:
Demonstração da SeekBar movida para a parte superior da barra de reprodução Aqui, movemos a SeekBar para a parte superior da barra de reprodução, completamente fora da zona de gestos. Isso significa que não é mais necessário preencher ou aumentar a altura da barra para acomodar a SeekBar .
No entanto, precisamos fazer esse preenchimento/aumento pela altura da barra do sistema para que o texto não fique encoberto. Esse assunto foi abordado na nossa segunda postagem do blog sobre “ Processamento de sobreposições visuais ”.
Usar as APIs de exclusão de gestos Na nossa postagem anterior do blog , mencionamos que “os aplicativos têm a capacidade de excluir os gestos do sistema para determinadas partes da tela ”. Os aplicativos fazem isso por meio das APIs de exclusão de gestos, uma novidade do Android 10.
O sistema fornece duas funções diferentes para excluir áreas: View.setSystemGestureExclusionRects() e Window.setSystemGestureExclusionRects() . A opção usada dependerá do seu aplicativo: se você usar a Visualização do Android, o sistema dará preferência à API de visualização. Caso contrário, use a API Window .
A principal diferença entre as duas APIs é que a API Window espera que todos os retângulos estejam no espaço de coordenadas da janela. Se você estiver usando visualizações, normalmente estará trabalhando no espaço de coordenada da visualização. A API de visualização cuida da conversão entre espaços de coordenadas, o que significa que você só precisa pensar em termos do conteúdo da visualização.
Vejamos um exemplo. Usaremos novamente o exemplo do player de música, com a SeekBar disposta em toda a largura da tela. Na seção anterior, corrigimos o fato da SeekBar acionar o gesto da página inicial. No entanto, ainda temos as zonas de gestos direita e esquerda para tratarmos.
Vejamos o que acontece quando o usuário tenta passar para outro ponto da música enquanto o ícone da SeekBar (o círculo para arrastar) está posicionado próximo a uma das bordas:
Demonstração da SeekBar em conflito com a área de gestos para “Voltar” Como o ícone está sob a área de gestos à direita, o sistema entende que o usuário está realizando o gesto para voltar e mostra a seta para trás. Isso confunde o usuário, que provavelmente não queria voltar. Para corrigir isso, podemos usar as APIs de exclusão de gestos citadas acima e excluir os limites do ícone.
Há dois lugares de onde essas APIs geralmente são chamadas: onLayout() quando sua visualização está disposta e onDraw() quando ela está desenhada. Sua visualização passa em uma List<Rect> que contém todos os retângulos a serem excluídos. Como mencionado anteriormente, esses retângulos precisam estar no sistema de coordenadas da própria visualização.
Normalmente, você criaria uma função semelhante a esta, que seria chamada do onLayout() e/ou do onDraw() :
Após essa adição, ao pular partes da música próximo às bordas funciona conforme o esperado:
Demonstração da SeekBar em funcionamento com a área de gestos para “Voltar” Veja o exemplo acima. A SeekBar faz isso automaticamente para você no Android 10, então não é necessário fazer isso por si só. Esse é apenas um exemplo para mostrar o padrão geral. Restrições Embora as APIs de exclusão de gestos possam parecer a solução perfeita para corrigir todos os conflitos desse tipo, elas não são. Ao usar essas APIs, você está declarando que o gesto do seu aplicativo é mais importante do que a ação do sistema de voltar. Essa é uma afirmação forte, e é por isso que essa API tem a finalidade de ser uma opção a ser usada em último caso.
Ao usar essas APIs, você está declarando que o gesto do seu aplicativo é mais importante do que a ação do sistema de voltar. Como o comportamento ativado pela API causa interrupção ao usuário, o sistema limita a forma como ela é usada: os aplicativos podem excluir apenas até 200 dp por borda.
Estas são algumas perguntas comuns dos desenvolvedores ao receberem essa informação:
Por que ter um limite? Esperamos que a explicação acima possa servir como dica para a resposta. Acreditamos que poder deslizar da borda para voltar de maneira consistente seja muito importante aos usuários. De forma consistente em todo o dispositivo, não em um único aplicativo. O limite pode parecer restritivo, mas basta um aplicativo excluir uma borda inteira da tela para confundir o usuário, levando à desinstalação do aplicativo ou a algo mais drástico.
Ou seja, a navegação do sistema precisa ser sempre consistente e utilizável.
Por que 200 dp? O pensamento por trás dos 200 dp é muito simples. Como mencionamos anteriormente, as APIs de exclusão de gestos são como uma última opção, portanto o limite foi calculado como um múltiplo de alvos importantes de toque. O tamanho mínimo recomendado para um alvo de toque é de 48 dp. 4 alvos de toque × 48 dp = 192 dp. Adicione um pouco de preenchimento e chegaremos ao nosso valor de 200 dp .
E se eu solicitar a exclusão de mais de 200 dp em uma borda? O sistema atenderá somente os 200 dp inferiores solicitados por você.
O sistema atende a solicitações com 200 dp de altura, contados a partir da borda inferior Minha visualização está fora da tela, ela entra na contagem do limite? Não, o sistema conta somente retângulos excluídos que estejam nos limites da tela. Da mesma forma, se a visualização estiver parcialmente na tela, apenas a parte visível do retângulo solicitado será contada.
Faça uma imersão na próxima postagem Você pode ter chegado até aqui e está se perguntando por que não falamos sobre o lado direito do fluxograma 🤔. Essas soluções são específicas para aplicativos que precisam ser exibidos em toda a tela. Elas serão abordadas na próxima postagem do blog, que já está disponível 👇
Navegação por gestos: Modos imersivos (IV)
11 comentários :
Você é um amante da música, deseja alterar o toque padrão em lugares de prestígio agora que as pessoas podem baixar suas músicas favoritas aqui: https://suonerietelefono.com
Vamos ouvir e baixar os melhores toques para celulares em: https://suonerietelefono.net/
Você é um amante da música e sempre atualizado com as músicas mais recentes. Você tem o direito de ler este comentário. Vou recomendar este site do Tonosdellamadacanciones com músicas constantemente atualizadas.
Actualice los últimos tonos de llamada para teléfonos en: https://suonerieandroid.info/
Obrigado por compartilhar, também estou procurando uma maneira de resolver esse problema e agora posso ouvir meu ringtone quando alguém liga. obrigado!
Thank you for your contribution. I am also seeking a basketball stars resolution to this issue.
hello
Insta fans, or followers, are the backbone of any successful account on the platform. They not only engage with your content through likes, comments, and shares but also help increase your visibility and reach by spreading your posts to a broader audience.
True criminal stories offers readers an intense glimpse into real-life crime cases, unraveling shocking events and the motives behind them. These stories dive into the lives of criminals, victims, detectives, and everyone affected, piecing together how crimes unfold and how they’re ultimately solved—or sometimes, left unsolved.
CareSens N Glucometer is a reliable, easy-to-use blood glucose monitoring device designed for people with diabetes to track their blood sugar levels at home. It offers accurate results within just 5 seconds, making it quick and efficient for daily testing. Etac Clean Shower Commode
Postar um comentário