Esta é a série de artigos do MAD Skills sobre Hilt. Neste artigo, veremos por que a injeção de dependências (DI, na sigla em inglês) é importante para os apps e o Hilt, a solução recomendada do Jetpack para DI no Android.
Se preferir ver este conteúdo em vídeo, acesse este link:
Ao seguir os princípios de injeção de dependências nos apps Android, você estabelece as bases para uma boa arquitetura de apps. Isso contribui para a reutilização de código e a facilidade de refatoração e testes. Saiba mais sobre os benefícios da DI aqui.
Ao criar instâncias de classes nos projetos, você pode exercitar o gráfico de dependências manualmente atendendo às dependências diretas e transitivas exigidas pela classe.
Mas fazer isso manualmente sempre envolve algum código boilerplate e pode estar sujeito a erros. Veja, por exemplo, um dos ViewModels que temos no iosched, o app Google I/O de código aberto. Você tem ideia da quantidade de código necessária para criar um FeedViewModel com as dependências diretas e transitivas?
Essa uma tarefa difícil e repetitiva, e podemos facilmente errar nas dependências. Por meio de uma biblioteca de injeção de dependências, podemos ter os benefícios da DI sem precisar fornecer as dependências manualmente, já que a biblioteca gera todo o código necessário para você. É aí que entra o Hilt.
O Hilt é uma biblioteca de injeção de dependências desenvolvida pelo Google que ajuda a obter o máximo das práticas recomendadas de DI nos apps ao fazer o trabalho mais difícil e gerar todo o boilerplate que você precisaria escrever em outra situação.
Por meio de anotações, o Hilt gera esse código para você no tempo de compilação, tornando-o muito rápido no tempo de execução. Isso é feito com o poder do Dagger, a biblioteca de DI do JVM na qual o Hilt é baseado.
O Hilt é a solução de DI recomendada do Jetpack para apps Android e vem com ferramentas e suporte a outras bibliotecas do Jetpack.
Todos os apps que usam o Hilt devem conter uma classe Application que é anotada com @HiltAndroidApp, pois isso dispara a geração de código do Hilt no tempo de compilação. E, para que o Hilt possa injetar dependências em uma atividade, ela precisa ser anotada com @AndroidEntryPoint.
Para injetar uma dependência, anote com @Inject as variáveis que você deseja que o Hilt injete. Todas as variáveis injetadas pelo Hilt são disponibilizadas com a chamada a super.onCreate.
Neste exemplo, vamos injetar um MusicPlayer em PlayActivity. Mas como o Hilt sabe de que forma deve fornecer instâncias do tipo MusicPlayer? Bem, ele não sabe, por enquanto. Precisamos dizer ao Hilt como fazer isso… usando anotações, é claro!
Anotar o construtor de uma classe com @Inject diz ao Hilt como criar instâncias dessa classe.
Isso é tudo de que precisamos para injetar uma dependência em uma Activity. Essa parte foi fácil! Começamos com um exemplo simples, já que o MusicPlayer não depende de nenhum outro tipo. No entanto, se tivéssemos outras dependências passadas como parâmetros, o Hilt cuidaria disso e atenderia a essas dependências fornecendo uma instância do MusicPlayer.
Esse foi um exemplo muito simples e ingênuo, na verdade. Mas se você tivesse que fazer manualmente o que fizemos até agora, como faria?
Ao fazer a injeção de dependências manualmente, você pode ter classes de contêiner de dependências que são responsáveis por fornecer tipos e gerenciar o ciclo de vida das instâncias fornecidas. Para simplificar um pouco, é isso o que o Hilt faz nos bastidores!
Quando você anota a Activity com @AndroidEntryPoint, um contêiner de dependências é criado, gerenciado e associado automaticamente a PlayActivity. Vamos chamar nossa implementação manual de PlayActivityContainer. Ao anotar MusicPlayer com @Inject, basicamente dizemos ao contêiner como fornecer instâncias do tipo MusicPlayer.
E, na Activity, precisaríamos criar uma instância do contêiner e preencher as dependências da atividade com ela. Isso também é feito pelo Hilt quando a atividade é anotada com @AndroidEntryPoint.
Até agora, vimos que quando @Inject é usado para anotar o construtor de uma classe, isso diz ao Hilt como fornecer instâncias dessa classe. E quando anota uma variável em uma classe @AndroidEntryPoint anotada, o Hilt injeta uma instância desse tipo na classe.
@AndroidEntryPoint, que pode anotar a maioria das classes de framework do Android, e não apenas atividades, cria uma instância de um contêiner de dependências para essa classe e preenche todas as variáveis @Inject anotadas.
@HiltAndroidApp anota a classe Application e, além de disparar a geração de código do Hilt, também cria um contêiner de dependências associado à classe Application.
Agora que já sabemos o básico sobre o Hilt, vamos complicar o exemplo. O MusicPlayer agora toma uma dependência de seu construtor, MusicDatabase.
Portanto, precisamos dizer ao Hilt como fornecer instâncias de MusicDatabase. Quando o tipo é uma interface ou você não possui a classe porque ela vem de uma biblioteca, por exemplo, não é possível anotar o construtor com @Inject.
Vamos imaginar que estamos usando o Room como biblioteca de persistência no app. De volta à nossa implementação manual de PlayActivityContainer, ao fornecer MusicDatabase com o Room, essa seria uma classe abstrata na qual gostaríamos de executar algum código para fornecer a dependência. Depois, para fornecer uma instância de MusicPlayer, precisamos chamar o método que fornece ou satisfaz a dependência de MusicDatabase.
Não precisamos nos preocupar com dependências transitivas no Hilt, já que ele conecta todas as dependências transitivas automaticamente. No entanto, precisamos dizer a ele como fornecer instâncias do tipo MusicDatabase. Para isso, usamos os módulos do Hilt.
Um módulo do Hilt é uma classe anotada com @Module. Nessa classe, podemos ter funções que dizem ao Hilt como fornecer instâncias de determinados tipos. Essas informações conhecidas pelo Hilt também são chamadas de vinculações no jargão do Hilt.
A função anotada com @Provides diz ao Hilt como fornecer instâncias do tipo MusicDatabase. O corpo contém o bloco de código que o Hilt precisa executar, e isso é exatamente igual ao que tínhamos na implementação manual.
O tipo de retorno, MusicDatabase, informa ao Hilt o tipo que essa função fornece. E os parâmetros da função indicam ao Hilt as dependências do tipo correspondente. Nesse caso, ApplicationContext, já disponível no Hilt. Esse código informa ao Hilt como fornecer instâncias do tipo MusicDatabase ou, em outras palavras, temos uma vinculação para MusicDatabase.
Os módulos Hilt também são anotados com @InstallIn, que indica em quais contêineres de dependências ou componentes essas informações estão disponíveis. Mas o que é um componente? Vamos explicar em mais detalhes.
Um componente é uma classe gerada pelo Hilt que é responsável por fornecer instâncias de tipos, como o contêiner que estamos programando manualmente. No tempo de compilação, o Hilt percorre o gráfico de dependências do aplicativo e gera um código para fornecer as dependências transitivas a todos os tipos.
O Hilt gera um componente, ou contêiner de dependências, para a maioria das classes de framework do Android. As informações, ou vinculações, de cada componente se propagam pela hierarquia de componentes.
Se a vinculação MusicDatabase estiver disponível no SingletonComponent, que corresponde à classe Application, ela também estará disponível no restante dos componentes.
Esses componentes são gerados automaticamente pelo Hilt no tempo de compilação e são criados, gerenciados e associados à classe de framework do Android correspondente quando você anota essas classes com @AndroidEntryPoint.
A anotação @InstallIn para módulos é útil para controlar onde essas vinculações estão disponíveis e que outras vinculações podem ser utilizadas.
De volta ao nosso código PlayActivityContainer criado manualmente, não sei se você percebeu, mas sempre que a dependência MusicDatabase é necessária, estamos criando outra instância dela.
Isso não é o ideal, pois podemos querer reutilizar a mesma instância de MusicDatabase em todo o app. Em vez de uma função, poderíamos compartilhar a mesma instância tendo tudo isso em uma variável.
Basicamente, estamos definindo o escopo do tipo MusicDatabase para esse contêiner, já que sempre fornecemos a mesma instância como dependência. Como fazer isso com o Hilt? Bem, aqui não há mistério… com outra anotação!
Ao usar a anotação @Singleton no método @Provides, dizemos ao Hilt para sempre compartilhar a mesma instância desse tipo naquele componente.
@Singleton é uma anotação de escopo. E cada componente do Hilt tem uma anotação de escopo associada.
Se você quiser definir o escopo de um tipo para o ActivityComponent, use a anotação ActivityScoped. Essas anotações podem ser usadas em módulos, mas também podem anotar classes cujo construtor é anotado com @Inject.
Existem dois tipos de vinculações:
O Hilt oferece integrações com as bibliotecas do Jetpack mais populares: ViewModel, Navigation, Compose e WorkManager.
Além de ViewModel, cada integração requer uma biblioteca diferente para adição ao projeto. Confira a documentação para obter mais informações sobre isso. Você se lembra do código FeedViewModel do iosched que vimos no início desta postagem do blog? Quer ver como ele fica com o suporte do Hilt?
Além de anotar o construtor com @Inject, para dizer ao Hilt como fornecer instâncias desse ViewModel, precisamos anotar a classe com @HiltViewModel.
Pronto! Você não precisa criar manualmente um provedor ViewModel para isso. O Hilt se encarrega da tarefa.
O Hilt é baseado em outra biblioteca popular de injeção de dependências: o Dagger! O Dagger será muito mencionado nos próximos episódios! Se você já usa o Dagger, saiba que ele e o Hilt podem trabalhar juntos. Leia mais sobre as APIs de migração no guia.
Para saber mais sobre o Hilt, temos uma folha de referência com as anotações mais populares, o que elas fazem e como utilizá-las. Além dos documentos sobre o Hilt, também temos codelabs para aprender com uma experiência mais prática.
E assim terminamos este episódio. Mas a história não acaba aqui. Há mais episódios por vir na série MAD Skills, então siga a publicação do Android Developers no Medium para ver quando eles serão postados.
Postado por Dave Burke, vice-presidente de engenharia
Faltam apenas algumas semanas para o lançamento oficial do Android 12. Enquanto trabalhamos nos ajustes finais da nova versão do Android, hoje trazemos uma atualização Beta final para ajudar nos testes e no desenvolvimento. Para os desenvolvedores, chegou a hora de garantir que os apps estejam prontos.
Você pode ter a versão Beta 5 hoje mesmo em seu dispositivo Pixel, incluindo o Pixel 5a com 5G, fazendo a inscrição aqui para receber atualizações OTA. Se você já tiver feito a inscrição, receberá a atualização automaticamente. Você também pode experimentar o Android 12 Beta 5 em alguns dispositivos de vários de nossos parceiros, como a Sharp. Veja os detalhes no site para desenvolvedores Android 12.
Em breve, forneceremos mais informações sobre o lançamento oficial do Android 12.
A atualização de hoje inclui um build RC do Android 12 para Pixel e outros dispositivos, além do Android Emulator. Atingimos a estabilidade da plataforma na versão Beta 4. Portanto, todas as superfícies voltadas para os apps estão finalizadas, incluindo as APIs do SDK e NDK, os comportamentos do sistema voltados para os apps e as restrições em interfaces externas ao SDK. Com isso, e também com as mais recentes correções e otimizações, a versão Beta 5 oferece tudo o que você precisa para concluir os testes.
Com o lançamento oficial do Android 12 se aproximando, estamos solicitando a todos os desenvolvedores de jogos e apps que concluam os testes finais de compatibilidade e publiquem as atualizações de compatibilidade assim que possível, antes do lançamento final. No caso dos desenvolvedores de SDK, bibliotecas, ferramentas e mecanismos de jogos, é importante lançar as atualizações de compatibilidade o mais rápido possível. Vale lembrar que o desenvolvimento downstream de apps e jogos pode ser bloqueado até que você receba as atualizações.
Para testar a compatibilidade do app, basta instalá-lo em um dispositivo executando o Android 12 Beta 5 e passar pelos fluxos do app em busca de possíveis problemas funcionais ou de IU. Revise as mudanças de comportamento do Android 12 para todos os apps para se concentrar nas áreas do app podem ser afetadas. Estas são algumas das principais mudanças a serem testadas:
Lembre-se de testar a compatibilidade de bibliotecas e SDKs nos apps. Caso você encontre algum problema relacionado ao SDK, tente atualizar para a versão mais recente do SDK ou peça ajuda ao desenvolvedor.
Depois de publicar a versão compatível de um app atual, você pode dar início ao processo de atualização do targetSdkVersion do app. Revise as mudanças de comportamento para apps Android 12 e use o framework de compatibilidade para ajudar na detecção rápida de problemas.
O Android 12 tem muitos recursos novos para ajudar você a criar ótimas experiências para os usuários. Confira a postagem sobre o Android 12 Beta 2 para obter um resumo e links para as palestras sobre o Android 12 no Google I/O. Acesse o site para desenvolvedores Android 12 para obter todos os detalhes dos novos recursos e APIs.
Além disso, não deixe de experimentar o Android Studio Arctic Fox no desenvolvimento e nos testes do Android 12. Adicionamos verificações Lint para ajudar a identificar partes do código que podem ser afetadas pelas mudanças do Android 12, como declarações personalizadas de telas de apresentação, permissão de localização aproximada para a utilização de localização precisa, formatos de mídia e permissão de alta taxa de amostragem de sensores. Para experimentar essas mudanças, faça o download e configure a versão mais recente do Android Studio.
A versão Beta 5 de hoje tem tudo o que você precisa para experimentar os recursos do Android 12, testar apps e nos fornecer feedback. Basta registrar qualquer dispositivo Pixel com suporte para receber a atualização OTA. Para começar a desenvolver, configure o SDK do Android 12.
Você também pode ter a versão Beta 5 em dispositivos de vários de nossos parceiros, como a Sharp. Para testes ainda mais abrangentes, você pode experimentar a versão Beta 5 em imagens GSI do Android e, se não tiver um dispositivo, pode testar no Android Emulator. Essa atualização também está disponível para o Android TV, então você pode experimentar os recursos mais recentes para TV e testar apps na novíssima experiência do Google TV.
Fique ligado no lançamento oficial do Android 12 nas próximas semanas. Até lá, fique à vontade para continuar enviando feedback por nossas listas de referências sobre problemas de plataforma, problemas de compatibilidade de apps e problemas de SDKs de terceiros.
Agradecemos à comunidade de desenvolvedores pela ajuda na construção desta versão do Android 12! Recebemos de vocês milhares de relatórios de bugs e insights que nos ajudaram a ajustar as APIs, melhorar os recursos, corrigir bugs importantes e tornar a plataforma melhor, de modo geral, para usuários e desenvolvedores.
Esperamos ver seus aplicativos no Android 12!
O Trackr é um app de gerenciamento de tarefas de amostra. Embora seja utilizado principalmente para explorar padrões comuns de IU do ponto de vista do suporte à acessibilidade, o Trackr é também uma das amostras nas quais demonstramos as práticas recomendadas do Modern Android Development. Recentemente, adaptamos o app para as telas grandes. Então, vamos dar uma olhada em como a aplicação do Material Design e de padrões responsivos produziu uma experiência do usuário mais refinada e intuitiva em dispositivos com telas grandes.
Antes: na tela Tasks, era possível acessar as opções Archive e Settings no menu da barra inferior do app. Nas telas grandes, o controle do menu é um alvo de toque minúsculo em um local inconveniente, e a barra inferior do app fica excessivamente esticada.
Depois: quando a tela é mais larga, agora mostramos um trilho de navegação. Também posicionamos o botão de ação flutuante (que abre a tela New Task) no trilho de navegação e removemos totalmente a barra inferior do app.
Embora essa mudança tenha sido feita para o uso em dispositivos maiores, ela também beneficia os telefones no modo paisagem porque permite um espaço vertical maior para a visualização da lista de tarefas.
Antes: as telas Tasks e Archive ocupavam toda a largura da tela, e tocar em um item substituía a lista pelos detalhes do item selecionado. Nas telas grandes, os elementos da IU eram esticados ou agrupados de um lado, e não havia um equilíbrio na aparência da tela.
Depois: as telas Tasks e Archive mostram uma IU de lista/detalhes utilizando SlidingPaneLayout. Escrevemos sobre como fazer isso em um artigo anterior relacionado às mudanças que fizemos no app Google I/O. Confira esse artigo se tiver interesse pelos detalhes técnicos.
A tela Task Detail também tinha um botão de ação flutuante (para abrir a tela Edit Task). Mas, com o trilho de navegação visível, isso resultaria em dois botões de ação flutuantes, o que não é ideal. Em vez disso, ocultamos o segundo botão de ação flutuante e adicionamos um botão de edição à barra de ferramentas na parte superior direita.
Antes: durante a edição de uma tarefa, a IU Edit Task substituía os detalhes da tarefa e ocupava toda a tela. Assim como em Task Detail, havia um desequilíbrio na aparência dessa tela. A IU New Task tinha o mesmo problema (na verdade, New Task e Edit Task são o mesmo destino em nosso gráfico de navegação).
Depois: nas telas grandes, usamos um DialogFragment para que a IU Edit Task flutuasse sobre o restante do conteúdo.
Originalmente, tentamos exibir essa IU no painel de detalhes, substituindo Task Detail. Embora isso tenha sido bem simples, logo percebemos que não estávamos satisfeitos com essa abordagem por alguns motivos:
O importante aqui é saber que o design mais simples pode ter lacunas de funcionalidade quando você o experimenta em um dispositivo. Quando isso acontecer, pare um pouco, concentre-se na experiência do usuário e procure por um padrão de design que facilite isso.
Com o aumento da popularidade de tablets e dispositivos dobráveis, criar uma IU responsiva é mais importante do que nunca. Mostramos como a adição de um trilho de navegação e o uso de SlidingPaneLayout não só melhora a aparência do app Trackr, como também melhora drasticamente a usabilidade e cria experiências que não seriam possíveis em um celular. Também mostramos como, às vezes, é necessário repensar o design de acordo com a usabilidade e não só com o espaço da tela a fim de atender às necessidades dos usuários.
Esperamos que você goste do novo Trackr aprimorado! Confira o código em github.com/android/trackr.
Postado por Ting-Yuan Huang e Jiaxiang Chen, engenheiros de software
O Kotlin Symbol Processing (KSP), nossa nova ferramenta para a criação de plug-ins de compilador leves no Kotlin, agora está na versão estável. O KSP oferece uma funcionalidade similar à do Kotlin Annotation Processing Tool (KAPT). No entanto, ele é duas vezes mais rápido, oferece acesso direto a construções da linguagem Kotlin e dá suporte a destinos multiplataforma.
Nos últimos meses, o KSP passou por 32 versões, com mais de 162 bugs relatados pela comunidade e corrigidos por nossa equipe. Se você estava esperando para adotá-lo, este é momento certo para tentar.
Na equipe do Android, perguntamos regularmente aos desenvolvedores: quais são as suas maiores frustrações com os apps de escrita de código hoje? Um dos principais problemas apontados com frequência é a velocidade de compilação. Ao longo dos anos, fizemos melhorias constantes no conjunto de ferramentas de compilação do Android e, hoje, é com grande prazer que anunciamos a adição dessas melhorias com o KSP. O KSP é a próxima geração de processamento de anotações no Kotlin: ele aumentará drasticamente a velocidade de compilação para os desenvolvedores Kotlin e, ao contrário do KAPT, oferece suporte a Kotlin/Native e Kotlin/JS.
"A adição do suporte a KSP ao Room aumentou a velocidade de compilação e também permitiu que o Room entendesse melhor o código do Kotlin, como a nulidade de parâmetros genéricos, o que não era possível com o KAPT. Isso também abre novas possibilidades, como a geração de código do Kotlin, que permitirão ao Room ter uma experiência do usuário melhor com o Kotlin no futuro." - Yigit Boyar, engenheiro de software, Android
O Kotlin Annotation Processing Tool (KAPT) trabalha com a infraestrutura de processamento de anotações do Java para fazer com que a maioria dos processadores de anotações da linguagem Java funcione diretamente no Kotlin. Para isso, o KAPT compila código do Kotlin em stubs Java que retêm as informações tratadas pelos processadores de anotações do Java. No entanto, a criação desses stubs é cara, e requer que o compilador resolva todos os símbolos do programa várias vezes (uma para gerar os stubs e, depois, novamente para executar a compilação propriamente dita).
O KSP abandona o modelo de geração de stubs ao trabalhar como um plug-in de compilador do Kotlin, o que permite que os processadores de anotações leiam e analisem programas e recursos de origem diretamente no Kotlin, em vez de exigir o uso da infraestrutura de processamento de anotações do Java. Isso aumenta significativamente a velocidade de compilação (que foi até duas vezes mais rápida no app Kotlin de teste do Room) e significa que o KSP pode ser utilizado para ambientes não Android e não JVM, como Kotlin/Native e Kotlin/JS.
Para começar a usar o KSP, faça o download do projeto playground do KSP do GitHub, que mostra como usar o KSP como processador de anotações e como app/biblioteca de consumo:
test-processor
workload
Se você é desenvolvedor de apps, confira a lista de bibliotecas com suporte e o guia de início rápido para a migração de um módulo do KAPT para o KSP.
Se você estiver usando o Moshi ou o Room em um projeto, já pode experimentar o KSP fazendo uma correção rápida no arquivo de compilação do módulo. Por exemplo, para usar a versão KSP do Room em um módulo do Gradle, você pode simplesmente substituir o plug-in KAPT pelo KSP e trocar a dependência do KSP:
apply plugin: 'com.google.devtools.ksp' dependencies { ... implementation "androidx.room:room-runtime:$room_version" kapt "androidx.room:room-compiler:$room_version" ksp "androidx.room:room-compiler:$room_version" }
Veja mais informações nas notas da versão do Room.
Com a versão 1.0 do KSP, você começará a ver melhorias nos tempos de compilação dos projetos Kotlin ao fazer a migração das bibliotecas baseadas no KAPT. Também atualizamos várias bibliotecas específicas do Android que estão prontas para você experimentá-las hoje mesmo e oferecem melhorias significativas de desempenho.
Em maio, publicamos uma atualização em nossos planos de redução da string User-Agent com a promessa de publicar mais detalhes sobre o cronograma. Agora que temos uma avaliação de origem pronta para o teste do cabeçalho User-Agent reduzido (e das interfaces JS associadas), temos estimativas de prazos para compartilhar. O texto a seguir repete a postagem do blog original, mas contém as versões do Chrome estimadas pelas quais essas fases começarão para ajudar você a se preparar.
O painel de cronograma do Chromium será útil para entender as datas associadas a cada versão do Chrome e sua progressão da versão Canário para a Beta e para a versão Estável.
Observação: as isenções de responsabilidade usuais relacionadas aos prazos estimados de engenharia se aplicam, já que circunstâncias imprevistas podem gerar atrasos. Mas, caso ocorram atrasos, não pretendemos acelerar os prazos entre as fases.
Planejamos lançar essas mudanças de forma lenta e incremental em sete fases, dependendo do feedback da avaliação de origem.
Fase 1: a partir do Chrome 92 (20 de julho de 2021)
Call to Action (CTA): audite a utilização de seu site para entender em que pontos pode ser necessária a migração.
Aviso sobre o acesso a navigator.userAgent, navigator.appVersion e navigator.platform no DevTools, a partir do M92.
Fase 2: do Chrome 95 ao Chrome 100
CTA: inscreva-se na avaliação de origem para seu site e forneça feedback até o lançamento do Chrome 101.
Lançamento de uma avaliação de origem para que os sites ativem a string UA reduzida final para testes e feedback por pelo menos seis meses.
Avaliaremos o feedback de parceiros de avaliação de origem e da comunidade e, com base nesse feedback, prosseguiremos para as Fases 3 a 7 de nosso plano, dando ao ecossistema tempo suficiente para a adaptação entre as fases. Caso contrário, dependendo do feedback, reconsideraremos o melhor plano de ação.
Fase 3: Chrome 100
CTA: inscreva-se na avaliação de suspensão de uso ou na política do Enterprise para seu site, quando necessário.
Lançamento da avaliação de suspensão de uso e da política do Enterprise para os casos em que um site precise de mais tempo para a migração.
Fase 4: Chrome 101
CTA: assegure que seu site seja compatível com o número de versão do Chrome reduzido e, se não for, migre para o UA Client Hints.
Lançamento dos números de versão MINOR.BUILD.PATCH do Chrome reduzidos (“0.0.0”). Uma vez lançada, a string UA reduzida se aplicaria a todos os carregamentos de página em sistemas operacionais para desktops e dispositivos móveis para os sites que não ativarem a avaliação de suspensão de uso.
Fase 5: Chrome 107
CTA: assegure que seu site seja compatível com a string UA para desktops reduzida e às APIs JS relacionadas e, se não for, migre para o UA Client Hints.
Início do lançamento da string UA para desktops reduzida e das APIs JS relacionadas (navigator.userAgent, navigator.appVersion e navigator.platform). Uma vez lançada, a string UA reduzida se aplicaria a todos os carregamentos de página em sistemas operacionais para desktops para os sites que não ativarem a avaliação de suspensão de uso.
Fase 6: Chrome 110
CTA: assegure que seu site seja compatível com a string UA para dispositivos móveis reduzida e às APIs JS relacionadas e, se não for, migre para o UA Client Hints.
Início do lançamento da string UA para dispositivos móveis (e tablets) Android reduzida e das APIs JS relacionadas. Uma vez lançada, a string UA reduzida se aplicaria a todos os carregamentos de página no Android que não ativarem a avaliação de suspensão de uso.
Fase 7: Chrome 113
A avaliação de suspensão de uso termina e todos os carregamentos de página recebem a string UA reduzida e as APIs JS relacionadas.
Consulte a página de atualizações sobre a string User-Agent reduzida para obter mais detalhes e exemplos de strings User-Agent em cada uma dessas fases. Nessa página, também indicaremos quaisquer atrasos ou mudanças importantes.
Postado pela equipe do Firebase
Esta é uma introdução a uma série de postagens do blog composta por três partes sobre qualidade de apps que detalha como atingir um novo patamar de estabilidade e desempenho de apps para alcançar a experiência ideal em apps. No final desta postagem, você encontra links para os outros artigos.
Estabilidade e desempenho são os dois elementos centrais de um app bem-sucedido. Experiências rápidas e livres de falhas incentivam os usuários a permanecerem engajados e geram avaliações positivas. Por esse motivo, manter-se atento à estabilidade do app é essencial para concorrer no próspero mercado de apps de hoje.
Os usuários esperam ter a melhor experiência sempre que interagem com um app. E se os bugs ou problemas de latência atrapalharem, eles rapidamente sairão em busca de uma opção melhor. Pesquisas demonstram que 88% dos usuários de apps abandonarão os apps devido a bugs e falhas técnicas. E, dentro desse grupo, 51% dos usuários disseram que abandonariam um app completamente se tivessem que enfrentar um ou mais bugs todos os dias.
A qualidade não é importante apenas para reter usuários, mas também para atrair novos usuários. Se uma grande porcentagem de usuários estiver frustrada e a listagem da app store estiver repleta de feedbacks negativos apontando problemas de desempenho, talvez seja difícil adquirir novos usuários.
Na verdade, 54% dos usuários que deixaram uma avaliação de uma estrela na Play Store mencionaram a estabilidade e os bugs dos apps.1
Não é de se admirar que a estabilidade e o desempenho sejam as principais áreas de foco para os desenvolvedores. Nossa própria pesquisa sobre o Firebase mostra que uma necessidade primordial para os desenvolvedores é obter as ferramentas e os serviços que os ajudem a depurar problemas técnicos, rastrear problemas nas mudanças de código e detectar problemas técnicos de desempenho.
Uma grande parte do desenvolvimento de pré-lançamento de um novo app envolve eliminar bugs e fazer testes em busca de possíveis problemas. Mas preparar o app para o lançamento é apenas o primeiro passo. Uma vez lançado no mundo, manter a integridade do app torna-se um processo contínuo, à medida que você cria novos recursos e itera em versões anteriores.
É importante lembrar que a qualidade de apps não é um fator padronizado. Dependendo do tipo de app e de como você define o sucesso, convém priorizar os fatores que são essenciais para o seu negócio. Com as ferramentas de geração de relatórios personalizados e os insights em tempo real do Firebase, é possível aprimorar as métricas que são mais relevantes.
Por exemplo, em um app de produtividade, no qual os usuários desejam uma interface simples e limpa e a capacidade de uso em trânsito, as taxas de erro elevadas e a lentidão no tempo de resposta fariam com que os usuários o abandonassem. Por outro lado, os usuários podem tolerar um pouco de lentidão entre as telas de cardápio de um app de entrega de refeições. Mas, se o app falhar toda vez que os usuários chegarem à tela de finalização da compra, com certeza a receita de vendas no app será prejudicada.
Seja qual for o tipo de app que você tem, estas são algumas das métricas de qualidade mais importantes que um app de sucesso precisa seguir:
Métricas de monitoramento como essas podem significar a diferença entre gerar downloads e reter usuários satisfeitos e sofrer com desligamentos de usuários e avaliações negativas de usuários insatisfeitos.
Para se manter à frente em um ecossistema de apps tão dinâmico, é preciso saber precisamente onde ocorrem os problemas de desempenho e estabilidade de um app. Nas próximas duas postagens do blog desta série, destacaremos dois produtos do Firebase que podem ajudar você a detectar falhas em apps e coletar insights acionáveis sobre o desempenho de apps da perspectiva de um usuário.
Fontes
Este documento faz parte de uma série de artigos sobre qualidade de apps. Apresentamos a seguir uma visão geral de todos os outros artigos:
Para os usuários de apps, a primeira impressão é a que fica. Mesmo os apps mais bem desenvolvidos podem ser frustrantes se não proporcionarem de modo consistente uma experiência livre de falhas.
Imagine um usuário de app se preparando para relaxar depois de um dia de trabalho. Ele pega um petisco, se acomoda no sofá e abre seu app de jogo favorito... e o app falha. Ou ele trava todas as vezes que o usuário está a um passo de passar para o próximo nível. Essas experiências de instabilidade podem frustrar os usuários e fazer com que eles desinstalem um app ou deixem uma avaliação bem negativa na app store.
Na verdade, os problemas de qualidade são o motivo mais comum para a exclusão precoce de apps. Um em cada cinco usuários (19%) desinstala um app devido a erros técnicos ou falhas.1
Milhares de motivos justificam as falhas de apps. O dispositivo de um usuário pode ter pouca memória ou um chipset fraco ou pode estar executando uma versão de SO mais antiga. Sem contar que o código do app pode estar repleto de bugs. Pior ainda, à medida que você adiciona novos recursos e adquire mais usuários em diferentes dispositivos, maior é a probabilidade de encontrar uma variedade mais ampla de falhas nos bastidores.
Rastrear, organizar e corrigir falhas manualmente pode ser um desafio bastante complexo e demorado. E mesmo que você colete cada bit de dados da falha, ainda pode não ficar claro o que está causando a falha do app ou quais erros estão afetando a maioria dos usuários. Por isso, ter as ferramentas certas de geração de relatórios de erros faz toda a diferença.
Aprimorar continuamente os apps e lançar novos recursos é uma das melhores maneiras de aumentar a retenção de usuários, bem como de engajar usuários novos e existentes. No entanto, à medida que a base de usuários cresce, dividir o tempo entre o lançamento de novos recursos e o monitoramento da estabilidade de novas versões se torna uma questão complicada.
O relatório de erros em tempo real do Firebase Crashlytics permite fazer uma triagem rápida e resolver qualquer bug no app com a coleta e o agrupamento de falhas com base no local em que ocorreram no código do app. Grupos de falhas são listados em ordem de frequência e grau de impacto sobre os usuários, facilitando a identificação dos problemas a serem combatidos e fornecendo a você mais tempo para criar recursos que mantêm os usuários engajados.
Dados do relatório de erros exibidos no painel do Firebase Crashlytics
Para se aprofundar ainda mais nos dados de falhas, você pode ativar a exportação de streaming do BigQuery para identificar problemas mais frequentes e entender tendências ao longo do tempo como quais versões de SO ou dispositivos específicos estão causando a maioria das falhas. Isso ajuda a visualizar os dados de falhas e monitorar problemas que acionam alertas e fluxos de trabalho personalizados. Ativar o streaming do BigQuery também permite analisar os dados com o SQL do BigQuery, exportá-los para outro provedor de nuvem e usar o Google Data Studio a fim de criar visualizações e painéis personalizados de tendências de falhas.
Crashlytics integrado ao BigQuery
Para um app como o Spotify, com mais de 65 equipes mantendo milhões de linhas de código por plataforma e lançando novas atualizações toda semana, a movimentação rápida e a passos largos é essencial. Para reduzir a pressão sobre a equipe de desenvolvimento antes de cada lançamento, a Spotify mudou o processo de rastreamento manual diário de falhas para o processo automatizado de lançamento usando o Crashlytics, principalmente com o BigQuery. Em vez de ter um gerente de lançamento da equipe de plantão para monitorar cada falha, a Spotify agora usa o Crashlytics para rastrear falhas de versões Alfa e Beta, definir regras para abertura de tíquetes e atribuir os tíquetes às equipes corretas.
De modo semelhante, a empresa de entrega de refeições Deliveroo, com sede no Reino Unido, adotou o Crashlytics e o BigQuery para se manter à frente das falhas antes que elas atinjam um determinado limite e, ao mesmo tempo, rastrear e analisar os dados de desempenho de cada nova versão em tempo real. Com a capacidade de criar relatórios personalizados e separar erros, a equipe de desenvolvimento reduziu consideravelmente o tempo gasto na solução de problemas e na reprodução de problemas do app, e as sessões livres de falhas aumentaram de 99,35% para mais de 99,7%.
As falhas não apenas afastam os usuários existentes dos apps. Avaliações negativas causadas por uma sessão instável em um app também podem afetar a capacidade de adquirir novos usuários. Por isso é tão importante saber quando e onde as falhas acontecem.
Os alertas de velocidade do Crashlytics notificam quando uma falha específica começa a aumentar para que você possa reagir antes que o bug afete mais usuários. Eles também são configuráveis, o que permite definir limites que determinam quando os alertas devem ser acionados com base na porcentagem de sessões de usuário afetadas.
Por exemplo, os alertas de velocidade podem detectar bugs importantes durante o lançamento de uma nova versão do app ou alertar rapidamente se houver um problema afetando uma grande porcentagem de usuários. Os alertas de velocidade enviam um e-mail ou uma mensagem no Slack, Jira ou PagerDuty, de acordo com a integração a terceiros ativada no projeto.
Configurações do alerta de velocidade no Console do Firebase
É exatamente assim que o Swiggy, um dos maiores serviços de entrega de refeições da Índia, monitora simultaneamente todos os problemas do app, enquanto se concentra primeiro nos mais significativos. A equipe de desenvolvimento do Swiggy conectou os alertas de velocidade do Crashlytics ao PagerDuty e ao Jira para notificar o engenheiro de plantão sempre que falhas críticas atingirem um determinado limite. Isso permitiu ao Swiggy manter as entregas rápidas com a segurança de que será notificado sobre falhas de alta e baixa prioridade da maneira correta.
Identificar rapidamente as falhas mais frequentes é apenas uma das partes do desafio. Ao chegar à causa-raiz, você pode reduzir o risco e evitar a frustração dos usuários do app, garantindo que essas falhas não aconteçam novamente.
As chaves e os registros personalizados do Crashlytics gravam os eventos vivenciados por um usuário durante uma sessão, rastreando o estado e a sequência do respectivo app. Com isso, você tem um instantâneo acionável para verificar o que o usuário estava fazendo até o momento em que o app falhou. Também é possível definir chaves personalizadas, como "origem_instalação", "rede" e "linguagem" para identificar exatamente o que aconteceu antes de cada falha (por exemplo, se um usuário instalou o app na Play Store ou se estava conectado ao Wi-Fi) e reduzir o tempo de reprodução.
E, ao usar o Crashlytics com o Google Analytics, é possível capturar automaticamente eventos predefinidos do Google Analytics, conhecidos como navegação estrutural, o que aprimora os dados capturados com registros personalizados e fornece informações mais detalhadas sobre o que causou uma falha.
Navegação estrutural no Google Analytics
Para editores de jogos para dispositivos móveis, como a Tapps Games, proporcionar uma experiência imersiva e estável é essencial para manter os jogadores engajados. Antes, a Tapps pesquisava manualmente as avaliações dos usuários em busca de feedbacks negativos e tentava reproduzir as falhas que eram descritas. Com os alertas de velocidade do Crashlytics, a equipe passou a ser imediatamente notificada quando falhas graves estavam em ascensão. Após examinar detalhadamente os dados, ela percebeu que uma atualização do processo de criação de vídeos do jogo Vlogger Go Viral e um evento simultâneo de jogadores da comunidade estavam levando a falhas consistentes.
A equipe de desenvolvimento da Tapps Games fez uma correção que ajudou a elevar sua classificação no Google Play Store de 3,9 para 4,7 e aumentou as sessões de usuários livres de falhas de 94,6% para 99,8%.
Para aumentar seu público, manter os usuários engajados e gerar avaliações positivas e recomendações, a estabilidade do app precisa ser uma área de foco principal. Instale o SDK do Firebase Crashlytics no app e tenha as ferramentas e informações necessárias para se manter atualizado sobre os problemas críticos.
Na terceira e última série do nosso guia, destacamos um conjunto de ferramentas que podem ser usadas com o Firebase Crashlytics para entender como está o desempenho do app do ponto de vista de um usuário.
Postado por Tom Grinsted, Scott Lin e Tat Yang Koh, gerentes de produto no Google Play
Classificações e avaliações são importantes. Elas fornecem valiosos feedbacks quantitativos e qualitativos sobre a experiência dos usuários com um app ou jogo e com o serviço mais generalizado que você oferece. É por isso que as pessoas as utilizam para decidir se fazem ou não o download de apps do Google Play.
Ouvimos dos usuários e desenvolvedores da Play Store que as classificações e avaliações poderiam ser mais úteis. Isso vale principalmente quando as classificações de uma área afetam outra injustamente. Por exemplo, quando um bug que impactou negativamente apenas um país afeta a classificação do app em todos os outros locais ou quando melhorias positivas em uma experiência de tablet são negligenciadas devido ao número de usuários com smartphones. É por isso que iniciamos um programa de melhorias, a serem implementadas ao longo de vários meses, para tornar as classificações mais personalizadas e indicativas da experiência que cada usuário pode esperar, bem como para facilitar a navegação por elas e seu uso pelos desenvolvedores:
Sabemos que muitos desenvolvedores monitoram de perto as classificações vistas pelos usuários em potencial, por isso estamos assegurando que você receba avisos com antecedência sobre essas mudanças futuras. Também fizemos melhorias no Play Console para ajudar você a entender as classificações e avaliações, especialmente entre os vários formatos.
Expandir o suporte para diferentes tipos de dispositivo é uma das mudanças mais importantes e impactantes que você pode fazer nas interfaces do usuário. A adição de layouts otimizados para tablets ou um suporte melhor ao mouse e ao teclado para o Chrome OS podem resultar em uma mudança radical na qualidade da experiência dos usuários, o que influencia as classificações e avaliações que eles fazem.
Novos insights sobre classificações por tipo de dispositivo estão disponíveis na visão geral e nas páginas de detalhes das classificações do Play Console
Para facilitar a identificação de oportunidades entre os vários tipos de dispositivo e rastrear o impacto de experiências aprimoradas, adicionamos novas dimensões de tipo de dispositivo à página de classificações. Também adicionamos um filtro de tipo de dispositivo às avaliações para que você possa ver facilmente como os usuários de tablets estão classificando você ou o que os usuários do Chrome OS dizem nas avaliações.
Muitos de vocês nos disseram que desejam acessar dados mais granulares do que o permitido por nossos seletores. Por isso dividimos as opções de segmentação e facilitamos seu uso. Agora, é possível selecionar independentemente o período que você deseja plotar (dos últimos 28 dias até o ciclo de vida completo do app) e como você deseja que os dados das classificações sejam agregados (diariamente, semanalmente ou a cada 28 dias). Isso permite acessar dados mais granulares de períodos mais longos.
Selecione qualquer intervalo de tempo e período de agregação independentemente para localizar os dados de classificações que deseja
Também ativamos o recurso de downloads de CSV da média de dados e das distribuições de classificação. Com isso, além das novas opções de seleção de dados, você pode facilmente consultar e fazer o download de muito mais dados e fazer análises offline. Por exemplo, você pode fazer o download de todo o histórico de distribuições de classificações diárias e correlacioná-lo em uma planilha com contatos do atendimento ao cliente.
Acesse e faça o download de todos os dados, incluindo divisões de classificações, diretamente na página de visão geral
Todas essas mudanças já estão ativas no Play Console. Acesse as seções de análise de classificações e avaliações para experimentá-las.*
As classificações ajudam as pessoas a decidir de quais apps fazer o download e são levadas em consideração no destaque e no posicionamento dentro da Play Store. Mas, como a experiência nos apps pode variar de acordo com a região e o tipo de dispositivo do usuário, agregar classificações nem sempre é suficiente. Por esse motivo, a partir de novembro de 2021, faremos uma mudança nas classificações que os usuários individuais veem com base no local onde estão registrados e, mais adiante, em qual dispositivo estão usando.
A partir de novembro, os usuários de smartphones verão classificações específicas do país ou da região em que estiverem. Sendo assim, um usuário no Japão verá classificações de apps que foram enviadas por outros usuários japoneses.
No início do ano seguinte, faremos outras atualizações nas classificações para refletir o tipo de dispositivo em que os usuários estão navegando, ou seja, tablets e dispositivos dobráveis, Chrome OS, Wear ou Auto. Isso dará aos usuários uma impressão melhor da experiência que eles podem esperar com o dispositivo que estão usando. É recomendável dar uma olhada em suas classificações de formato atuais – especialmente no caso de tablets, cuja utilização vem aumentando muito – para determinar se você deve investir na otimização da experiência dos usuários.
Entendemos que, como desenvolvedor, você quer ter certeza de que entende e está à frente de qualquer grande mudança nas classificações que podem ser vistas pelos usuários. Por isso, pelo menos dez semanas antes de qualquer mudança na Play Store, analisaremos automaticamente a mudança que os apps podem esperar e entraremos em contato com qualquer desenvolvedor que verá uma mudança de mais 0,2 estrelas em qualquer tipo de dispositivo em um mercado-chave (com uma porcentagem superior a 5% de visitantes da listagem da loja). Com isso, você terá tempo de se planejar se quiser fazer mudanças importantes no app.
O lançamento dessas mudanças no Google Play terá início em novembro, com classificações específicas de região ou país. Fique de olho nas mensagens sobre classificações em sua Inbox do Play Console até o final deste ano, e não se esqueça de que você pode se adiantar, verificando suas classificações por país e tipo de dispositivo hoje mesmo.
*Observe que você precisa de uma conta do Play Console para acessar esses links.
Esta postagem do blog foi útil para você?
★ ★ ★ ★ ★
