"invisible"
"activatable"
autofocus
font-optical-sizing
list-style-type
disc
decimal
::before
list-style-position
Worklet.addModule()
AbortError
SyntaxError
self.serviceWorker
self.serviceWorker.state
error
load
<script>
A Hugging Face é a startup líder em PLN com mais de mil empresas, incluindo Bing, Apple e Monzo, usando a biblioteca da organização em processos de produção. Todos os exemplos usados neste tutorial estão disponíveis no Colab. Encontre os links nas seções correspondentes.
A Hugging Face é uma startup focada no PLN e tem uma grande comunidade que trabalha em código aberto, usando especialmente a biblioteca Transformers. A 🤗/Transformers é uma biblioteca baseada em python que expõe uma API para o uso de diversas arquiteturas de transformação conhecidas, como BERT, RoBERTa, GPT-2 ou DistilBERT. Esses recursos geram resultados de ponta em diferentes tarefas do PLN, como classificação de texto, extração de informações, resposta a perguntas e geração de texto. Essas arquiteturas são pré-treinadas com vários conjuntos de pesos. Para dar os primeiros passos com a Transformers, você só precisa instalar o pacote pip:
pip install transformers
A biblioteca teve um crescimento veloz no PyTorch e foi portada recentemente para o TensorFlow 2.0, oferecendo uma API que funciona com a API fit do Keras, o TensorFlow Extended e TPUs 👏. Esta postagem do blog é dedicada ao uso da biblioteca Transformers com o TensorFlow. Com a API do Keras e o TPUStrategy do TensorFlow, é possível ajustar um modelo de transformação de última geração.
A Transformers é baseada no conceito de modelos de transformação pré-treinados. Esses modelos de transformação têm diferentes formas, tamanhos e arquiteturas e incluem maneiras próprias de aceitar dados de entrada: via tokenização.
A biblioteca é baseada em três classes principais: configuração, tokenização e modelo.
A vantagem da biblioteca Transformers está no uso de uma API simples e independente de modelo. O carregamento de um modelo pré-treinado, junto com o tokenizador, pode ser feito usando algumas linhas de código. Veja um exemplo de carregamento de modelos BERT e GPT-2 do TensorFlow, bem como os tokenizadores relacionados:
Os pesos são transferidos por download do intervalo S3 da Hugging Face e armazenados em cache localmente na sua máquina. Os modelos estão prontos para inferências ou podem ser ajustados, se necessário. Vejamos como isso funciona na prática.
Graças a alguns métodos disponíveis na biblioteca Transformer, ficou mais fácil ajustar um modelo. As partes a seguir são criadas da seguinte forma:
Criamos um notebook do Colab para ajudar você com o processo de codificação. Aproveitaremos o pacote tensorflow_datasets para o carregamento de dados. O Tensorflow-dataset oferece um tf.data.Dataset, que pode ser alimentado no nosso método glue_convert_examples_to_features.
Esse método utilizará o tokenizador para tokenizar a entrada e adicionar tokens especiais no início e no final das sequências, caso eles sejam exigidos pelo modelo (como [SEP], [CLS], </s> ou <s>, por exemplo). Isso retornará um tf.data.Dataset contendo as entradas com recursos.
Em seguida, podemos usar uma ordem aleatória desse conjunto de dados e agrupá-lo em lotes de 32 unidades usando os métodos padrão tf.data.Dataset.
Treinar um modelo usando o método fit do Keras nunca foi tão simples. Agora que temos a configuração do canal de entrada, podemos definir os hiperparâmetros e chamar o método fit do Keras com nosso conjunto de dados.
Usar uma estratégia oferece a você um controle maior sobre o que acontece durante o treinamento. Ao alternar entre estratégias, o usuário pode selecionar a forma distribuída usada para treinar o modelo: de várias GPUs a TPUs.
Até o momento, o TPUStrategy é a única maneira certeira de treinar um modelo em uma TPU usando o TensorFlow 2. Criar um loop personalizado usando uma estratégia é ainda mais útil, já que as estratégias podem ser facilmente alternadas, e o treinamento em várias GPUs não exige quase mudanças no código.
A configuração desse loop é um pouco trabalhosa. Por isso, aconselhamos você a abrir o notebook do Colab a seguir para ter uma melhor compreensão do assunto em questão. Você não encontrará detalhes sobre a tokenização como na primeira edição, mas verá como criar um canal de entrada que será usado pelo TPUStrategy.
O recurso usa o intervalo do Google Cloud Platform para hospedar dados, devido à complexidade do gerenciamento de TPUs em sistemas de arquivos locais. O notebook do Codelab está disponível aqui.
A principal vantagem da biblioteca Transformers é seu modelo de API simples e independente. Ao atuar como um front-end para modelos que geram resultados avançados em PLN, ela facilita muito a alternância entre modelos de acordo com a tarefa em questão.
Como exemplo, veja o script completo para ajustar BERT em uma tarefa de classificação idiomática (MRPC):
No entanto, em um ambiente de produção, a memória é escassa. Você poderia usar um modelo menor e mudar para DistilBERT, por exemplo. Para isso, basta alterar as duas primeiras linhas para as novas opções:
Como uma plataforma que hospeda mais de 10 arquiteturas de transformação, a 🤗/Transformers facilita o uso, o ajuste e a comparação dos modelos que transfiguraram o aprendizado detalhado para o campo do PLN. O recurso funciona como back-end para muitos aplicativos descendentes que utilizam modelos de transformação e é usado nos processos de produção em diversas empresas diferentes. Se você tiver perguntas ou questões, use nosso repositório do GitHub.
Kevin Chyn, biblioteca do Android
Curtis Belmonte, biblioteca do Android
Com o lançamento do Android 10 (API de nível 29), os desenvolvedores agora podem usar a API biométrica, parte da biblioteca AndroidX Biometric, para todas as necessidades de autenticação do usuário no dispositivo. A equipe da biblioteca e segurança do Android adicionou diversos recursos significativos à biblioteca AndroidX Biometric.Com isso, todo o comportamento biométrico do Android 10 é disponibilizado a todos os dispositivos que executam o Android 6.0 (API de nível 23) ou versões posteriores. A API é compatível com vários formatos de autenticação biométrica. Com ela, os desenvolvedores podem verificar com muito mais facilidade se determinado dispositivo tem sensores biométricos. Caso não haja nenhum sensor biométrico, a API permitirá que os desenvolvedores especifiquem se querem usar as credenciais do dispositivo nos aplicativos.
Os recursos não beneficiam apenas os desenvolvedores. Fabricantes de dispositivos e OEMs também têm bastante a comemorar. A biblioteca agora oferece uma API otimizada e padronizada para OEMs integrarem suporte a todos os tipos de sensores biométricos nos dispositivos. Além disso, a biblioteca tem suporte integrado para autenticação facial no Android 10. Assim, os fornecedores não precisam criar uma implementação personalizada.
A classe FingerprintManager foi introduzida no Android 6.0 (API de nível 23). Atualmente, e até o Android 9 (API de nível de 28), a API era compatível somente com sensores de impressão digital e sem IU. Os desenvolvedores precisavam criar uma IU de impressão digital própria.
FingerprintManager
Com base no feedback dos desenvolvedores, o Android 9 introduziu uma política da IU de impressão digital padronizada. O BiometricPrompt também foi introduzido para abranger mais sensores além da impressão digital. Além de fornecer uma IU segura e familiar para autenticação do usuário, isso permitiu que uma pequena superfície de API mantida pelos desenvolvedores acessasse a variedade de hardware biométrico disponível em dispositivos OEM. Agora, os OEMs podem personalizar a IU com os recursos e a iconografia necessários para expor novas biometrias, como contornos de sensores em exibição. Com isso, os desenvolvedores de aplicativos não precisam se preocupar em executar implementações personalizadas específicas de dispositivos para autenticação biométrica.
BiometricPrompt
Ou seja, no Android 10, a equipe introduziu alguns recursos essenciais para transformar a API biométrica em um balcão único para a autenticação do usuário no aplicativo. Com o BiometricManager, os desenvolvedores podem verificar se um dispositivo é compatível com a autenticação biométrica. Além disso, o método setDeviceCredentialAllowed() foi adicionado para oferecer aos desenvolvedores a opção de usar o PIN, o padrão ou a senha de um dispositivo em vez da credencial biométrica, caso faça sentido para o aplicativo.
BiometricManager
setDeviceCredentialAllowed()
A equipe incluiu todos os recursos biométricos do Android 10 à dependência Gradle do androidx.biometric. Assim, uma interface única e consistente é disponibilizada até o Android 6.0 (API de nível 23).
androidx.biometric
A dependência Gradle do androidx.biometric é uma biblioteca de suporte para as classes Biometric da biblioteca Android. Na API 29 e versões posteriores, a biblioteca usa as classes em android.hardware.biometrics e FingerprintManager até a API 23 e a credencial de confirmação até a API 21. Devido à variedade de APIs, é altamente recomendado usar a biblioteca de suporte androidx, independentemente do nível de API executado no seu aplicativo.
Biometric
android.hardware.biometrics
androidx
Para usar a API biométrica no seu aplicativo, siga as etapas abaixo:
$biometric_version é a versão mais recente da biblioteca
$biometric_version
def biometric_version= '1.0.0-rc02' implementation "androidx.biometric:biometric:$biometric_version"
O BiometricPrompt precisa ser recriado todas as vezes que houver a criação de Activity/Fragment. Isso precisa ser feito no onCreate() ou onCreateView() para que BiometricPrompt.AuthenticationCallback possa começar a receber os callbacks adequadamente.
Activity
Fragment
onCreate()
onCreateView()
BiometricPrompt.AuthenticationCallback
Para verificar se o dispositivo é compatível com a autenticação biométrica, adicione a lógica a seguir:
val biometricManager = BiometricManager.from(context) if (biometricManager.canAuthenticate() == BiometricManager.BIOMETRIC_SUCCESS){ // TODO: show in-app settings, make authentication calls. }
O construtor BiometricPrompt requer um Executor e um objeto AuthenticationCallback. Com o Executor, é possível especificar um thread que será usado para a execução dos callbacks.
Executor
AuthenticationCallback
O AuthenticationCallback tem três métodos:
onAuthenticationSucceeded()
onAuthenticationError()
onAuthenticationFailed()
O snippet a seguir mostra uma maneira de implementar o Executor e como instanciar o BiometricPrompt:
private fun instanceOfBiometricPrompt(): BiometricPrompt { val executor = ContextCompat.getmainExecutor(context) val callback = object: BiometricPrompt.AuthenticationCallback() { override fun onAuthenticationError(errorCode: Int, errString: CharSequence) { super.onAuthenticationError(errorCode, errString) showMessage("$errorCode :: $errString") } override fun onAuthenticationFailed() { super.onAuthenticationFailed() showMessage("Authentication failed for an unknown reason") } override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) { super.onAuthenticationSucceeded(result) showMessage("Authentication was successful") } } val biometricPrompt = BiometricPrompt(context, executor, callback) return biometricPrompt }
A instanciação do BiometricPrompt precisa ser concluída no início do ciclo de vida do fragmento ou da atividade (por exemplo,em onCreate ou onCreateView). Isso garante que a instância atual sempre receberá adequadamente os callbacks de autenticação.
onCreate
onCreateView
Após ter um objeto BiometricPrompt, chame biometricPrompt.authenticate(promptInfo) para solicitar a autenticação ao usuário. Se o aplicativo exigir que o usuário autentique usando uma biometria forte ou precisar executar operações criptográficas no repositório de chaves, use authenticate(PromptInfo, CryptoObject).
biometricPrompt.authenticate(promptInfo)
authenticate(PromptInfo, CryptoObject)
Essa chamada mostrará a IU adequada ao usuário, com base no tipo da credencial biométrica usada para autenticação, como impressão digital, rosto ou íris. Como desenvolvedor, você não precisa saber qual o tipo de credencial é usado para autenticação, a API cuida disso tudo para você.
Essa chamada requer um objeto BiometricPrompt.PromptInfo. Um PromptInfo é onde você define o texto exibido na solicitação: como o título, subtítulo e a descrição. Sem um PromptInfo, não fica claro ao usuário final qual aplicativo está solicitando a credencial biométrica. Com o PromptInfo também é possível especificar se será permitido que dispositivos incompatíveis com a autenticação biométrica concedam acesso por meio das credenciais do dispositivo, como senha, PIN ou padrão usados para desbloquear o dispositivo.
BiometricPrompt.PromptInfo
PromptInfo
Veja este exemplo de loop de declaração PromptInfo:
private fun getPromptInfo(): BiometricPrompt.PromptInfo { val promptInfo = BiometricPrompt.PromptInfo.Builder() .setTitle("My App's Authentication") .setSubtitle("Please login to get access") .setDescription("My App is using Android biometric authentication") .setDeviceCredentialAllowed(true) .build() return promptInfo }
Para ações que requerem uma etapa de confirmação, como transações e pagamentos, recomendamos usar a opção padrão: setConfirmationRequired(true). Ela adicionará um botão de confirmação à IU, conforme exibido na Imagem 2.
setConfirmationRequired(true)
setConfirmationRequired(false)
Agora que já realizou todas as etapas obrigatórias, solicite a autenticação do usuário.
val canAuthenticate = biometricManager.canAuthenticate() if (canAuthenticate == BiometricManager.BIOMETRIC_SUCCESS) { biometricPrompt.authenticate(promptInfo) } else { Log.d(TAG, "could not authenticate because: $canAuthenticate") }
Está tudo pronto! Agora você pode executar a autenticação, usando credenciais biométricas, em qualquer dispositivo que opere no Android 6.0 (API de nível 23) ou versões posteriores.
Como o ecossistema continua a evoluir rapidamente, a equipe da biblioteca do Android pensa constantemente em formas de oferecer suporte a longo prazo para OEMs e desenvolvedores. Devido à IU com base no sistema consistente da biblioteca biométrica, os desenvolvedores não precisam se preocupar com requisitos específicos do dispositivo, e os usuários têm uma experiência mais confiável.
Será ótimo receber feedback de desenvolvedores e OEMs sobre como fortalecer, simplificar a utilização e melhorar o suporte de diversos casos de uso.
Para ver exemplos detalhados que exibem casos de uso adicionais e demonstram como você pode integrar essa biblioteca ao seu aplicativo, confira nosso repositório. Ele contém aplicativos de amostra funcionais que usam a biblioteca. Também é possível ler o guia do desenvolvedor associado e a referência da API para saber mais.
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.
Esperamos que as perguntas sejam autoexplicativas, mas caso você tenha dúvidas, responderemos a cada uma delas:
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.
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:
Além dos jogos, estes são alguns exemplos comuns de IU que responderão de forma afirmativa a essa pergunta:
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.
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).
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.
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:
Agora que abordamos as perguntas, esperamos que você tenha chegado a uma das soluções. Portanto, veremos os detalhes de cada uma delas.
Começaremos com a “solução” mais fácil: simplesmente... nadaa 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 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.
No entanto, quando o usuário tenta passar para outro ponto da música, ocorre a seguinte situação:
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:
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:
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
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:
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”.
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:
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:
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.
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ê.
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.
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)
A tecnologia do Google Cloud ajuda tanto nossos clientes quanto nossas equipes internas. Recentemente, a equipe de arquitetos de soluções decidiu mover um processo interno para usar o BigQuery com o objetivo de otimizar e concentrar melhor os esforços em toda a equipe.
Eles publicaram os guias de referência para que os clientes possam usá-los durante a criação de aplicativos no Google Cloud. Nosso processo de publicação tem várias etapas, incluindo aprovação de esboço, rascunho, revisão dos colegas, edição técnica, revisão jurídica, aprovação de RP e, por fim, a publicação no nosso site. Esse processo envolve a colaboração entres as equipes de edição técnica, jurídico e RP.
Com tantas etapas e pessoas envolvidas, é importante que colaboremos efetivamente. Nossa equipe usa uma ferramenta de colaboração executada no Google Cloud Platform (GCP) como um repositório central e fluxo de trabalho para nossos guias de referência.
À medida que nossa equipe de arquitetos de soluções crescia e nossas necessidades de relatórios se tornavam mais sofisticadas, percebemos que não podíamos fornecer efetivamente os insights de que precisávamos diretamente na nossa ferramenta de colaboração existente. Por exemplo, precisávamos criar e compartilhar painéis de status dos nossos guias de referência, criar um roteiro para os próximos trabalhos e analisar quanto tempo nossas soluções demoram para serem publicadas, desde a aprovação do esboço até a publicação. Também era necessário compartilhar essas informações fora da equipe, mas sem compartilhar informações desnecessárias, concedendo amplo acesso a toda a nossa instância de colaboração.
Como nossa ferramenta de colaboração oferece uma REST API robusta e flexível, decidimos escrever um script de exportação que armazenasse os resultados no BigQuery. O BigQuery foi escolhido porque sabíamos que seria possível escrever consultas avançadas nos dados e, em seguida, usar o Data Studio para criar os painéis. O uso do BigQuery para análise forneceu uma solução escalonável bem integrada a outras ferramentas de GCP e compatível com inserções em lote e em tempo real por meio da API de streaming.
Usamos um script Python simples para ler os problemas da API e inserir as entradas no BigQuery por meio do método da API de streaming. Escolhemos a API de streaming, em vez do Cloud Pub/Sub ou do Cloud Dataflow, porque queríamos preencher novamente o conteúdo do BigQuery com os dados mais recentes várias vezes ao dia. A biblioteca do cliente API Python do Google foi uma escolha óbvia, porque ela oferece uma maneira idiomática de interagir com as APIs do Google, incluindo a API de streaming do BigQuery.
Como esses dados seriam usados somente para fins de relatório, optamos por manter apenas a versão mais recente dos dados extraída. Tivemos duas razões para essa decisão:
Seguimos as práticas recomendadas comuns de extrair, transformar e carregar (ETL), com uma tabela de preparação e uma tabela de produção separada para que pudéssemos carregar dados na tabela de preparação sem afetar os usuários dos dados. O design criado com base nas práticas recomendadas de ETL exigia a exclusão de todos os registros da tabela de preparação. Além disso, era necessário carregá-la e substituir a tabela de produção pelo conteúdo.
Ao usar a API de streaming, o buffer de streaming do BigQuery permanece ativo por cerca de 30 a 60 minutos ou mais após o uso. Isso significa que não é possível excluir nem alterar os dados durante esse período. Como usamos a API de streaming, programamos o carregamento a cada três horas para equilibrar a inserção rápida de dados no BigQuery e poder excluir os dados subsequentemente da tabela de preparação durante o processo de carregamento.
Após os dados estarem no BigQuery, seria possível escrever consultas SQL diretamente neles ou usar qualquer uma das diversas ferramentas integradas disponíveis para analisá-los. Para visualização, escolhemos o Data Studio, porque ele é bem integrado ao BigQuery, oferece recursos personalizáveis do painel e a capacidade de colaborar, além de ser gratuito, é claro.
Como os conjuntos de dados do BigQuery podem ser compartilhados com os usuários, a usabilidade dos dados foi aberta para quem recebeu acesso e autorização apropriada. Com isso, também poderíamos combinar esses dados no BigQuery com outros conjuntos de dados. Por exemplo, rastreamos as métricas de engajamento on-line dos nossos guias de referência e as carregamos no BigQuery. Com os dois conjuntos de dados no BigQuery, foi fácil levar em consideração os números de engajamento on-line para criar os painéis.
Um dos principais motivos para querermos criar relatórios no nosso processo de publicação é acompanhar esse processo ao longo do tempo. O Data Studio facilitou a criação de painéis com gráficos, semelhantes aos dois que podem ser vistos abaixo. A criação do painel no Data Studio nos permitiu analisar facilmente nossas métricas de publicação ao longo do tempo e depois compartilhar os painéis específicos com outras equipes além da nossa.
O monitoramento é uma parte importante de qualquer canal ETL. O Stackdriver Monitoring oferece monitoramento, alertas e painéis para ambientes do GCP. Optamos por usar o módulo Google Cloud Logging no script de carregamento do Python porque isso geraria registros de erros no Stackdriver Logging e eles poderiam ser usados para alertar sobre erros no Stackdriver Monitoring. Configuramos um espaço de trabalho do Stackdriver Monitoring especificamente para o projeto com o processo de carregamento. Em seguida, criamos um painel de gerenciamento para rastrear qualquer erro de aplicativo. Configuramos alertas para enviar uma notificação por SMS sempre que erros aparecessem nos arquivos de registro do processo de carregamento. Veja os painéis no espaço de trabalho do Stackdriver:
Estes são os detalhes dos alertas que configuramos:
O BigQuery oferece a flexibilidade para você atender às suas necessidades comerciais ou analíticas, sejam elas de tamanho de petabyte ou não. A API de streaming do BigQuery significa que você pode transmitir dados diretamente no BigQuery e fornecer aos usuários finais acesso rápido aos dados. O Data Studio oferece uma integração fácil de usar com o BigQuery, que simplifica o desenvolvimento de painéis avançados. A abordagem de custo por consulta significa que você pagará pelo que armazenar e analisar, embora o BigQuery também ofereça preços fixos, caso você tenha um número alto de consultas grandes. O uso do BigQuery permitiu à nossa equipe ter novos insights consideráveis sobre o processo de publicação. Isso nos ajudou a refinar esse processo e concentrar maiores esforços nos tópicos técnicos mais conhecidos.
Se ainda não tiver visto, confira o que o BigQuery pode fazer com os conjuntos de dados públicos do BigQuery e consulte o que mais você pode fazer com o GCP nos nossos guias de referência.
