Este é o Now in Android, seu guia atualizado de novidades e fatos importantes do mundo de desenvolvimento no Android.
A série MAD Skills continua rolando, com novo conteúdo técnico sobre Modern Android Development.
A série sobre App Bundles terminou com uma dica da desenvolvedora especialista da Google, Angélica Oliveira e com uma sessão de Perguntas e respostas ao vivo e gravada comigo (fazendo as perguntas) e com Ben Weiss, Wojtek Kaliciński e Iurii Makhno (fornecendo as respostas). Você também pode encontrar todos os episódios sobre App Bundles (em formato de vídeo e artigo) nos links do blog de encerramento:
MAD Skills - Become an Android App Bundle expert
Na semana passada, o MAD Skills apresentou uma nova série sobre componentes do Material Design, a biblioteca que simplifica a criação de aplicativos utilizando as diretrizes do Material Design.
O primeiro episódio foi o de Nick Butcher, sobre por que recomendamos que os desenvolvedores Android usem os componentes do Material Design. O vídeo inclui uma visão geral dos vários itens oferecidos pelo MDC, incluindo suporte a temas, transições integradas e componentes padrão no estilo do Material:
Esse conteúdo também foi abordado em um artigo anterior:
We Recommend Material Design Components
Em seguida, Nick Rout postou um episódio sobre os temas do Material, detalhando a amostra de projeto MaterialThemeBuilder para demonstrar o uso e a personalização de temas do Material:
Além do vídeo, você pode conferir também os artigos recentes sobre os temas do MDC para cor, tipografia e forma.
Esta semana, Chris Banes postou o terceiro episódio sobre a criação de um tema escuro com o MDC utilizando o recurso Force Dark do Android 10 e o tema DayNight do MDC.
Recentemente, Chris também publicou esse conteúdo em formato de artigo:
Dark Theme with MDC
Temos mais conteúdo sobre o MDC chegando esta semana, além de outra sessão de perguntas e respostas ao vivo, na próxima quinta-feira. Fique ligado na playlist do MDC para saber mais detalhes.
Para ver o conteúdo atual do MAD, não deixe de conferir a playlist do MAD Skills no YouTube, os artigos no Medium ou esta página de destino útil, que fornece acesso a todo o conteúdo.
No final de 2021, haverá requisitos de nível de API de destino (para apps novos e atualizados) e App Bundles. Hoi Lam fez uma postagem de blog com todos os detalhes. Resumidamente:
Agosto de 2021:
Novembro de 2021:
Novos requisitos de Android App Bundle e nível de API de destino em 2021
Os fragmentos fornecem um elemento arquitetônico importante para desenvolvedores de IUs, permitindo gerenciar blocos menores da IU de um app de forma autocontida. Seja com o uso da Navegação com fragmentos ou apenas de fragmentos, vale a pena saber como utilizá-los melhor nos apps. Sabemos como uma documentação completa e atualizada é importante para compreender como utilizar ferramentas e APIs. Embora as APIs obsoletas sejam uma indicação do que deve ser evitado, é a documentação que precisa apontar o caminho certo e explicar as práticas recomendadas.
Por isso, a equipe reescreveu quase toda a documentação sobre fragmentos, oferecendo orientações mais claras e atualizadas sobre vários aspectos dos fragmentos, incluindo ciclos de vida, estado, testes e muito mais. Confira aqui os documentos mais recentes (incluindo as subseções dos links a seguir):
Fragmentos | Android Developers
Ian Lake, que corrigiu e aprimorou os fragmentos no AndroidX, anotou essas mudanças de documentação neste feed do Twitter.
Também há um conjunto totalmente novo de documentos sobre o fluxo Kotlin, com informações sobre tudo, desde os conceitos básicos do uso do fluxo até os testes das novas APIs StateFlow e SharedFlow. Não deixe de conferir também o vídeo sobre o uso do fluxo (que será discutido a seguir).
Fluxos Kotlin | Android Developers
Na semana passada, postei um artigo sobre como automatizar alguns aspectos do desempenho da inicialização de aplicativos. Estive analisando o desempenho da inicialização em geral e queria encontrar uma forma automatizada e razoável de determinar a duração da inicialização para várias execuções consecutivas. Publiquei minha abordagem para todos os que tenham o mesmo interesse em testes de desempenho de inicialização.
Testing App Startup Performance
Em seu artigo, Migrating from Dagger to Hilt, Manuel Vivo apresenta a seguinte pergunta: “Vale a pena migrar do Dagger para o Hilt?” (alerta de spoiler: “Provavelmente… mas isso depende da situação”).
O artigo aborda alguns dos motivos importantes para se considerar a migração, incluindo testes de APIs, consistência e integração às extensões do AndroidX.
Migrating from Dagger to Hilt — Is it worth it?
Falando em Hilt, Filip Stanis postou este artigo para ajudar os desenvolvedores a dar os primeiros passos com o Hilt, mesmo que eles não tenham experiência anterior em injeção de dependências nem no Dagger. Então, se tudo isso é novidade para você, continue lendo.
Embora o título indique que o artigo é destinado aos desenvolvedores Kotlin, isso vale mais para os snippets de código do artigo. As abordagens e técnicas gerais do artigo também são aplicáveis aos desenvolvedores que utilizam a linguagem de programação Java.
A pragmatic guide to Hilt with Kotlin
Manuel Vivo postou um novo vídeo da série Vocabulário do Kotlin que discute o uso dos fluxos do Kotlin para a emissão de um stream de dados. Ele complementa seu vídeo anterior, The ABC of Coroutines, portanto, talvez você deva assistir a ele primeiro para… entrar no fluxo.
David Winer publicou um blog que fala sobre as propriedades sintéticas do Kotlin e também sobre a vinculação de visualizações (ambos mecanismos para eliminar aquelas incômodas chamadas a findViewById() no código). O artigo diz que o uso das propriedades sintéticas será suspenso em uma versão futura do plug-in do Kotlin (pelos motivos detalhados no artigo). O texto também discute a extensão @Parcelize, que continuará sendo recomendada e suportada.
O futuro do Android Kotlin Extensions
Houve muitas mudanças nas versões recentes do Android relacionadas à proteção de dados de usuários e ao aumento do controle dos usuários e da transparência sobre como os dados deles são acessados. Uma das principais áreas de foco foi a localização, já que talvez os usuários não queiram que os aplicativos acessem esses dados e prefiram controlar esse acesso com bastante cautela.
Nessa linha, a política do Google Play em breve exigirá que os apps que precisem de acesso à localização durante sua execução em segundo plano solicitem permissão (da Play Store) para isso. Esse artigo detalha o processo para essa solicitação.
Dicas para que seu app receba a aprovação de acesso à localização em segundo plano
Isso é tudo, por enquanto. Então, fique sabendo tudo sobre MAD, App Bundles e componentes do Material Design. Confira os requisitos do próximo ano relacionados a App Bundles e API de destino. Leia os documentos mais recentes sobre fragmentos e fluxo Kotlin. Confira o conteúdo mais recente para desenvolvedores na publicação Android Developers no Medium, no Blog de desenvolvedores Android e no canal Android Developers no YouTube. Em breve, voltaremos com a próxima atualização do universo dos desenvolvedores Android.
Em conjunto com a série MAD Skills, queríamos nos divertir um pouco e oferecer uma oportunidade para que você responda a uma pergunta importantíssima: Qual é o seu nível de MAD? Para descobrir, instale e execute o plug-in MAD Scorecard no Android Studio. Ele cria uma ficha para você, mostrando o nível de pontuação dos apps nos quatro pilares do Modern Android Development e que pode ser compartilhada no Twitter com a hashtag #MADscore.
Acesse o site MAD Score para saber os detalhes ou veja mais informações no blog de Christopher Katsaros:
Enquanto isso, a série MAD Skills continua rolando, com conteúdo técnico sobre Modern Android Development. Na semana passada, terminou a série sobre Componentes do Material Design. Desde o último Now in Android, a equipe postou mais três episódios:
Nº 4: Material MotionNo quarto episódio sobre MDC, Nick Rout fala sobre os quatro padrões de movimento no Material e como implementá-los nos aplicativos. Ele detalha a amostra de app Reply e um codelab baseado nesse app para mostrar como ele funciona na prática.
Nº 5 Community Tip de Zarah DominguezO quinto episódio sobre MDC é de Zarah Dominguez, especialista em desenvolvimento do Google. Ela fala sobre como sua equipe usa o app de catálogo do Material para ver como as coisas funcionam na prática e qual é a aparência do código-fonte como exemplo de implementação.
Nº 6: Perguntas e respostas ao vivoO episódio final sobre MDC foi, assim como nas séries anteriores sobre App Bundles e Navegação, uma sessão de Perguntas e respostas ao vivo com especialistas em MDC sobre os relacionamentos com desenvolvedores e as equipes de engenharia do Material. Recebemos muitas perguntas de vocês no Twitter e em tempo real no YouTube durante a sessão. Não tivemos tempo para responder a todas, mas tivemos um progresso… material.
Se você perdeu qualquer conteúdo da série MDC, Nick Rout escreveu um resumo da série neste artigo de encerramento, com links para todos os vídeos e artigos relevantes, além de amostras, documentos e codelabs associados e muito mais.
Esta semana, temos uma nova série MAD Skills sobre Kotlin e Jetpack. Especificamente, ela fala sobre como usar o Kotlin em conjunto com muitas das APIs do Jetpack. Florina Muntenescu fez a seguinte introdução:
Nº 1: Uso do KTXO primeiro episódio da série fala sobre o uso do KTX, as extensões do Kotlin que fornecem abordagens aprimoradas e mais simples para várias bibliotecas de plataforma e do Jetpack. Florina discute o KTX em geral, com exemplos de APIs de plataforma e do Jetpack, demonstrando como ela as utiliza junto com o LiveData e o ViewModel.
Ou em formato de artigo:
Nº 2: APIs simplificadas com corrotinasNesse segundo episódio, Manuel Vivo explica como usar as corrotinas do Kotlin para melhorar a experiência de uso de APIs existentes para desenvolvedores Kotlin. Por exemplo, é possível criar adaptadores que simplificam a complexidade de callbacks aninhadas com corrotinas. Ele traz um exemplo de criação de uma API mais simples para o provedor de localização combinada para demonstrar como fazer isso na prática.
Haverá mais episódios sobre Kotlin/Jetpack nas próximas semanas, que serão disponibilizados na playlist do YouTube e também em forma de arquivo, na publicação do Android Developers.
Para ver o conteúdo atual, não deixe de conferir a playlist do MAD Skills no YouTube, os artigos no Medium ou esta página de destino útil , a qual fornece acesso a todo o conteúdo.
Nas últimas versões, foram feitas várias mudanças nas permissões. Enquanto isso, continuamos nos concentrando no controle de usuários e na transparência de dados de usuários. Às vezes, isso envolve o trabalho de desenvolvedores, para acompanhar as últimas atualizações e mudanças de comportamento. Por isso, trabalhamos em nossa documentação, para ajudarmos nesse processo.
Como parte desse esforço, recentemente fizemos várias melhorias substanciais no guia de permissões no Android. Esse site agora fornece orientações mais otimizadas sobre o funcionamento das permissões, além de práticas recomendadas para o uso de permissões em apps. Em especial, você deve avaliar se realmente precisa declarar permissões, o que não é necessário na maioria dos casos comuns.
Dois guias da biblioteca Room foram reformulados para esclarecer como utilizar alguns dos aspectos das APIs:
Como acessar dados usando DAOs (objetos de acesso aos dados) da Room fornece uma visão geral do uso da interface DAO, incluindo o uso dos métodos de consulta integrados e também de métodos personalizados por meio da anotação @Query .
@Query
Writing asynchronous DAO queries cobre mais detalhes sobre como escrever consultas que ocorrem fora da linha de execução de IU, o que é bastante necessário para interações com bancos de dados. O guia discute várias alternativas que podem ser utilizadas, dependendo da linguagem e das preferências de API assíncrona.
Dentre todas as versões Alfa, Beta e RC recentes das várias bibliotecas do AndroidX, estão as seguintes versões estáveis:
Também chegaram algumas versões estáveis de correção de bugs, incluindo Exifinterface 1.3.2, Media 1.2.1 e Navigation 2.3.2.
Jamal Eason postou um artigo anunciando a próxima versão do Android Studio: o Arctic Fox já está no canal Canary e pronto para avaliação. A primeira coisa que você notará sobre essa versão é um novo esquema de nomenclatura e controle de versões, que é discutido detalhadamente no artigo. Além disso, algumas das coisas a serem conferidas nessa versão incluem uma IU para o emparelhamento com um dispositivo para depuração de Wi-Fi (por enquanto apenas para MacOS), uma ferramenta de validação de layout e o suporte continuado ao desenvolvimento no Jetpack Compose. (Note que a versão canário do Studio sempre deve ser utilizada para trabalhar com o Compose em seu estado inicial atual.)
Murat Yener também postou sobre as novidades do Android Studio em seu artigo sobre a nova versão Alfa do Plug-in do Android para Gradle, versão 7.0.0-alpha01. Observe que o AGP também passou por uma mudança de nomenclatura de versão. Agora, ele segue as versões do Gradle em vez de ser associado às versões do Android Studio. Isso explica por que parece que essa versão pulou ou omitiu algumas versões desde a atual 4.2. O artigo também fala sobre algumas das recentes mudanças de API no AGP 4.2.
Meghan Mehta postou mais um artigo em sua série sobre o RecyclerView. Embora o RecyclerView não seja novo (e provavelmente já esteja sendo utilizado em apps pela maioria dos desenvolvedores Android), achamos que a documentação e os exemplos de alguns dos fundamentos eram um pouco difíceis de encontrar (pelo menos em nossos documentos e artigos). Por isso, ela tem tentado explicar como usar alguns dos fundamentos, utilizando amostras de código para mostrar como fazer as coisas na prática.
Em seu artigo mais recente, Meghan fala especificamente sobre o uso do ListAdapter, que oferece uma forma simples de obter algumas funcionalidades ótimas para o RecyclerView, inclusive um desempenho melhor e animações automáticas de itens. O ListAdapter usa o DiffUtil para determinar as mudanças específicas que ocorreram, das quais o RecyclerView necessita para obter o máximo desempenho e as melhores animações.
Continuei com minha exploração do desempenho de inicialização com uma série em duas partes sobre a biblioteca do AndroidX App Startup, que recentemente chegou à versão 1.0 . A Parte um analisa como os provedores de conteúdo geralmente são utilizados para instanciar bibliotecas e como isso pode causar um impacto oculto sobre o tempo de inicialização dos aplicativos.
A Parte 2 investiga como usar a biblioteca App Startup para remover os provedores de conteúdo ocultos e agrupar as solicitações para iniciar as bibliotecas de forma lenta.
Há um artigo no blog do Android Developers que detalha melhorias adicionadas ao sistema e às APIs de localização para que seja possível obter informações de localização mais precisas em grandes cidades. O artigo discute o problema da derivação de localizações de GPS em grandes cidades, onde a suposição padrão da tecnologia de GPS utilizando a linha de visão é prejudicada pela forma como os sinais são refletidos pelos edifícios altos. (Tor e eu conversamos sobre isso com Marc Stogaitis, da equipe de localização, em um podcast do ADB em 2014: o fenômeno é conhecido como “vales urbanos”).
A equipe integrou modelos de edifícios 3D das principais cidades para atingir resultados de localização muito mais precisos. A versão 2 dessa tecnologia já está disponível em alguns dispositivos Pixel. Uma versão anterior foi disponibilizada para o ecossistema mais amplo, e essa versão mais recente também estará disponível mais globalmente no início do próximo ano.
É claro que tudo isso é um recurso para usuários, e o Now in Android é para desenvolvedores. Mas eu queria destacar isso aqui porque (a) acho o artigo e a tecnologia interessantes e (b) há um apelo para os desenvolvedores aqui, que é o de usar o provedor de localização combinada (FLP) para obter acesso a esses dados de localização aprimorados.
Além disso, há uma nova API no FLP que permite obter as informações de localização atuais com muito mais facilidade, simplesmente perguntando qual é a localização atual e obtendo um resultado, em vez de inscrever mudanças constantes de localização e, então, cancelar a inscrição depois de obter o primeiro resultado. Confira a documentação da API getCurrentLocation() do FLP, a nova amostra CurrentLocationKotlin e o artigo para obter mais informações.
Chris Banes migrou o app Tivi , deixando de usar o kit de ferramentas de IU atual e passando para o Jetpack Compose. Ele concluiu a maior parte dessa migração, com toda a IU agora sendo escrita no Compose, e reportou alguns resultados interessantes sobre tamanho do APK (muito menor!), contagem de métodos (menor) e duração da compilação (um pouco menor).
A API CameraView no CameraX estava trabalhando demais, lidando com a IU e a lógica de controle. Assim, essa lógica foi refatorada para o PreviewView e a nova classe CameraController . Este artigo descreve como usar o CameraController e como essa funcionalidade se compara com o que você pode ter utilizado no CameraView.
CameraController
CameraView
Desde o último Now in Android, publicamos outro episódio do Android Developers Backstage . Confira no link abaixo ou acesse em seu cliente de podcast favorito:
Romain Guy, Tor Norbye e eu conversamos com Jesse Wilson, da Square, sobre algumas das bibliotecas de código-aberto mais conhecidas nas quais ele está trabalhando, inclusive OkHttp, Okio e [Ok]Moshi. Falamos sobre essas e outras bibliotecas e também sobre desenvolvimento do Android, de bibliotecas, de frameworks e do Kotlin. E ainda falamos sobre aquele costume terrível que alguns engenheiros têm de transformar uma solicitação de recurso ou um pequeno problema em um projeto de criação de uma nova biblioteca de código aberto.
Isso é tudo, por enquanto. Então, obtenha seu MAD Scorecard. Acesse o MAD para saber mais sobre MDC e conteúdo do Kotlin/Jetpack. Conheça a documentação mais recente sobre Permissões e sobre a Room. Faça o download das versões estáveis mais recentes do AndroidX. Leia novos artigos sobre ListAdapter, desempenho de inicialização, localização de GPS aprimorada, migração para o Jetpack Compose e CameraController. Ouça o episódio mais recente do podcast do ADB. Em breve, voltaremos com a próxima atualização do universo dos desenvolvedores Android.
Este artigo faz parte de uma série sobre as mudanças de atributos de cookies SameSite:
SameSite
Schemeful Same-Site modifica a definição de um site (da Web) de apenas o domínio registrável para o esquema + o domínio registrável. Mais detalhes e exemplos podem ser encontrados em Understanding "same-site" and "same-origin".
Termo-chave: significa que a versão HTTP não segura de um site, como http://website.example, e a versão HTTPS segura desse mesmo site, https://website.example, agora são consideradas, uma em relação à outra, dentro de um contexto entre sites.
A boa notícia é que, se o upgrade do site para HTTPS já estiver concluído, você não precisa se preocupar com mais nada. Nada muda para você, nesse caso.
Se o upgrade do site ainda não estiver concluído, essa deve ser a prioridade. No entanto, se houver casos nos quais os visitantes do site alternem o HTTP e o HTTPS, alguns desses cenários comuns e o comportamento do cookie SameSite associado são descritos a seguir.
Aviso: no longo prazo, o plano é desativar gradual e totalmente o suporte a cookies de terceiros, substituindo-o por alternativas que preservem a privacidade. A definição de SameSite=None; Secure em um cookie para permitir que ele seja enviado entre esquemas só deve ser considerada como uma solução temporária na migração para o HTTPS total.
SameSite=None; Secure
Você pode ativar essas mudanças para teste no Chrome e no Firefox.
chrome://flags/#schemeful-same-site
network.cookie.sameSite.schemeful
true
about:config
Um dos motivos principais da mudança para SameSite=Lax como padrão para cookies foi a proteção contra ataques de falsificação de solicitação entre sites (CSRF, na sigla em inglês). No entanto, o tráfego HTTP não seguro ainda representa uma oportunidade para que invasores de redes adulterem cookies que são, então, utilizados na versão HTTPS segura do site. A criação desse limite adicional entre sites entre os esquemas oferece uma defesa melhor contra esses ataques.
SameSite=Lax
Termo-chave: nos exemplos abaixo, onde todos os URLs têm o mesmo domínio registrável, como site.example, mas esquemas diferentes, como http://site.example versus https://site.example, eles são referenciados como entre esquemas um em relação ao outro.
A navegação pelas versões entre esquemas de um site (por exemplo, um link de http://site.example para https://site.example) anteriormente permitiria o envio de cookies SameSite=Strict. Isso agora é tratado como uma navegação entre sites, o que significa que os cookies SameSite=Strict são bloqueados.
SameSite=Strict
SameSite=None;Secure
Aviso: todos os principais navegadores bloqueiam conteúdo misto ativo, como scripts ou iframes. Além disso, alguns navegadores, incluindo Chrome e Firefox, estão trabalhando no upgrade ou bloqueio de conteúdo misto passivo.
Quaisquer mudanças feitas aqui só devem ser consideradas correções temporárias enquanto você trabalha no upgrade para o HTTPS total.
Exemplos de sub-recursos incluem imagens, iframes e solicitações de rede feitas com XHR ou Fetch.
O carregamento de um sub-recurso entre esquemas em uma página anteriormente permitira o envio ou a definição de cookies SameSite=Strict ou SameSite=Lax. Agora, isso é tratado da mesma forma que qualquer outro sub-recurso entre sites ou de terceiros, o que significa que todos os cookies SameSite=Strict ou SameSite=Lax são bloqueados.
Além disso, mesmo que o navegador permita o carregamento de recursos de esquemas não seguros em uma página segura, todos os cookies são bloqueados nessas solicitações, porque os cookies entre sites ou de terceiros exigem Secure.
Secure
A postagem entre versões entre esquemas de um site anteriormente permitiria que cookies definidos com SameSite=Lax ou SameSite=Strict fossem enviados. Isso agora é tratado como um POST entre sites — apenas os cookies SameSite=None podem ser enviados. Esse cenário pode ser encontrado em sites que apresentam a versão não segura por padrão, mas que fazem upgrade dos usuários para a versão segura no envio do formulário de login ou da finalização da compra.
SameSite=None
Assim como no caso dos sub-recursos, se a solicitação for de um contexto seguro, como HTTPS, para um não seguro, como HTTP, todos os cookies são bloqueados nessas solicitações, uma vez que os cookies entre sites ou de terceiros exigem Secure.
Aviso: a melhor solução nesse caso é garantir que a página e o destino do formulário estejam em uma conexão segura, como HTTPS. Isso é especialmente importante se o usuário estiver inserindo informações confidenciais no formulário.
As mensagens e ferramentas para desenvolvedores estão disponíveis no Chrome e no Firefox.
No Chrome 86, a guia Issue em DevTools inclui os problemas relacionados ao Schemeful Same-Site. Os seguintes problemas podem ser destacados para um site.
Problemas de navegação:
Problemas de carregamento de sub-recursos:
Mais detalhes podem ser encontrados em Testing and Debugging Tips for Schemeful Same-Site.
No Firefox 79, com network.cookie.sameSite.schemeful definido como true via about:config, o console exibe a mensagem para problemas com o Schemeful Same-Site. Você pode ver o seguinte em seu site:
cookie_name
http://site.example/
É possível que alguns dos links e sub-recursos ainda apontem para URLs não seguros.
Uma forma de corrigir o problema é usar o HSTS HTTP Strict-Transport-Security e a diretiva includeSubDomain. Com o HSTS + includeSubDomain, mesmo que uma das páginas acidentalmente inclua um link não seguro, o navegador usa automaticamente a versão segura.
includeSubDomain
Embora seja altamente recomendável fazer upgrade do site totalmente para HTTPS a fim de proteger os usuários, se você não puder fazer isso, sugerimos falar com seu provedor de hospedagem para ver se ele oferece essa opção. Se a hospedagem for própria, a Let's Encrypt oferece várias ferramentas para instalar e configurar um certificado. Outra opção é tentar colocar o site por trás de um CDN ou outro proxy capaz de fornecer a conexão HTTPS.
Se isso também não for possível, tente afrouxar a proteção do SameSite sobre os cookies afetados.
Lax
Strict
None
Os cookies sem um atributo SameSite são tratados como se tivessem especificado SameSite=Lax, e o mesmo comportamento entre esquemas se aplica a eles. Observe que a exceção temporária para métodos não seguros também se aplica. Consulte sobre a mitigação de Lax + POST nas Perguntas frequentes do SameSite no Chromium para obter mais informações.
As conexões WebSocket ainda serão consideradas do mesmo site se tiverem a mesma segurança da página.
Do mesmo site:
wss://
https://
ws://
http://
Entre sites:
Foto de Julissa Capdevilla em Unsplash
O dia de hoje marca o lançamento da primeira versão Canário do Android Studio 4.3, juntamente com o plug-in do Android para Gradle (AGP) versão 7.0.0-alpha01. Com esse lançamento, estamos ajustando a numeração da versão para nosso plug-in Gradle, dissociando-o do esquema de controle de versões do Android Studio e pulando dois números inteiros. Nesta postagem do blog, explicaremos os motivos dessa mudança e faremos uma prévia de algumas mudanças importantes que estamos fazendo nas novas APIs e DSL do plug-in do Android para Gradle em incubação.
Com o AGP 7.0.0, estamos adotando os princípios do controle de versões semântico. Isso significa que apenas as mudanças de versões principais afetarão a compatibilidade com a API. Pretendemos lançar uma versão principal por ano, assim que a Gradle introduzir sua própria versão principal anual.
Além disso, no caso de uma alteração interruptiva, garantiremos que a API removida seja marcada com @Deprecated com aproximadamente um ano de antecedência e que sua substituição seja disponibilizada ao mesmo tempo. Isso dará aos desenvolvedores cerca de um ano para migrar e testar plug-ins com a nova API antes que a antiga seja removida.
O alinhamento à versão do Gradle é também o motivo pelo qual estamos pulando as versões 5 e 6 e passando diretamente para o AGP 7.0.0. Esse alinhamento indica que o AGP 7.x deve funcionar com as APIs do Gradle 7.x. Embora ele também possa ser executado no Gradle 8.x, isso não é garantido e dependerá da remoção, na versão 8.x, de APIs das quais o AGP depende.
Com essa mudança, o número da versão do AGP será dissociado do número da versão do Android Studio. No entanto, continuaremos lançando o Android Studio e o plug-in do Android para Gradle juntos, por enquanto.
A compatibilidade entre o Android Studio e o plug-in do Android para Gradle continua inalterada. Como regra geral, os projetos que usam versões estáveis do AGP podem ser abertos com versões mais recentes do Android Studio.
Ainda é possível usar a linguagem de programação Java versão 8 com o AGP 7.0.0-alpha01, mas estamos mudando a versão mínima exigida da linguagem de programação Java para o Java 11, a partir do AGP 7.0.0-alpha02. Estamos anunciando isso logo no início da programação da versão Canário e muitos meses antes da versão estável para que os desenvolvedores tenham tempo para se prepararem.
Essa versão do AGP também introduz algumas mudanças em APIs. Como lembrete, várias APIs que foram introduzidas no AGP 4.1 foram marcadas como em incubação e estavam sujeitas a mudanças. Na verdade, no AGP 4.2, algumas dessas APIs foram modificadas. As APIs atualmente em incubação não seguem o ciclo de suspensão de uso que explicamos acima.
Segue um resumo de algumas mudanças importantes nas APIs.
Vamos dar uma olhada em algumas dessas mudanças. Segue uma amostra de bloco onVariants direcionada ao build de lançamento. O bloco onVariants é alterado para beforeVariants e usa um seletor de variante neste exemplo.
```
android {
…
//onVariants.withName("release") {
// ...
//}
}
androidComponents {
val release = selector().withBuildType(“release”)
beforeVariants(release) { variant ->
...
Da mesma forma, o bloco onVariantProperties é alterado para onVariants.
//onVariantProperties {
androidComponents.onVariants { variant ->
Observe que essa personalização geralmente é feita em um plug-in e não deve ser posicionada em build.gradle. Estamos deixando de usar funções com receptores, que eram adequadas à sintaxe do DSL, mas não são necessárias no código do plug-in.
Planejamos tornar essas APIs estáveis com o AGP 7.0.0, e todos os autores de plug-ins devem migrar para o novo androidComponents. Se você quiser evitar ter que lidar com essas mudanças, use apenas APIs estáveis nos plug-ins e não dependa de APIs marcadas como em incubação.
Caso deseje saber mais sobre outras mudanças dessa versão, não deixe de dar uma olhada nas notas da versão.
Java é marca registrada da Oracle e/ou de suas afiliadas.
O plug-in Android Kotlin Extensions Gradle (não confundir com o Android KTX) foi lançado em 2017 e trouxe duas novas conveniências para o desenvolvimento no Android com o Kotlin:
Depois disso, lançamos a vinculação de visualizações para Android, uma biblioteca com suporte oficial altamente integrada ao conjunto de ferramentas de criação do Android e que fornece funcionalidade similar à das propriedades sintéticas do Kotlin. Apesar de continuarmos recomendando o Parcelize, várias desvantagens surgiram com o uso das propriedades sintéticas do Kotlin:
A JetBrains é a desenvolvedora original do plug-in Android Kotlin Extensions e, junto com eles, discutimos os prós e contras de continuarmos mantendo as propriedades sintéticas: sempre que possível, nos esforçamos para garantir o suporte de longo prazo a APIs, mas queremos orientar os desenvolvedores para práticas recomendadas que permitam bases de código saudáveis e, consequentemente, usuários satisfeitos.
Ao longo do próximo ano, nossas equipes, em conjunto, suspenderão o uso das propriedades sintéticas de forma a continuar dando suporte à nossa opção recomendada, a vinculação de visualizações. Veja o que isso significa:
O período de suspensão começa com o Kotlin 1.4.20, lançado hoje. O android-kotlin-extensions continuará a existir por pelo menos um ano, mas será removido em uma versão futura do Kotlin, durante ou depois de setembro de 2021. No longo prazo, continuaremos mantendo o plug-in kotlin-parcelize, e você poderá continuar registrando problemas relacionados ao Parcelize no Rastreador de problemas do Android Studio.
O público-alvo de um app pode ser dividido em três grupos básicos: os não engajados (atraídos pela estratégia de aquisição), os que se tornam mais engajados (encorajados pela estratégia de retenção) e os que se tornam menos engajados (redirecionados pela estratégia de desligamento de usuários). Uma vez que todos eles envolvem diferentes estratégias, faz sentido pensar em aquisição, retenção e desligamento de usuários como áreas totalmente diferentes, embora o combate ao desligamento de usuários seja, muitas vezes, negligenciado por ser visto como mitigado pelo aumento da aquisição ou solucionado pelo aumento da retenção de usuários engajados.
Em um artigo anterior [LINK], discutimos como os desenvolvedores podem configurar uma estratégia de retenção eficaz visando aumentar a probabilidade de reter usuários engajados (confira também o relatório completo, que apresenta um detalhamento maior). Mas, não importa o quanto a estratégia e o app sejam bons, alguns dos usuários acabarão sendo desligados.
O desligamento de um usuário está associado a uma perda para as empresas que vai além da perda óbvia de potencial de receita. Se o desligamento for precoce, o custo de aquisição do usuário será totalmente perdido e, embora seja possível reengajar um usuário desligado, isso pode ser mais caro e demorado do que adquirir um novo.
Como resultado, em vez de tentar reengajar um usuário - o que envolve superar diretamente todos os problemas que levaram ao desligamento - é muito melhor ver se algo pode ser feito antecipadamente para impedir que ele se desligue.
Como agir antes que seja tarde demais?
Evitar o desligamento de usuários significa agir antes que isso aconteça, criando um sistema de aviso que permita identificar os sinais de desligamento e agir antes da ocorrência. Os usuários não se desengajam do dia para a noite. Antes do desligamento, a maneira como eles interagem com o app começa a mudar de formas identificáveis e mensuráveis. Para identificar esses alertas vermelhos, veja nos próprios dados quais comportamentos são demonstrados por usuários que se desligam:
O Quickbooks usa modelagem detalhada para desconstruir os comportamentos dos usuários recentemente desligados. Eles criam "perfis de risco dos usuários" que destacam quais comportamentos estão correlacionados à alta probabilidade de desligamento.
Esses perfis consistem em 200 a 300 comportamentos diferentes no app, incluindo falta de interação com recursos, número de dias de inatividade e não atingimento da métrica estrela-guia. Para saber como definir essa métrica, confira este artigo.
A realização desses "post-mortems" permite ao Quickbooks intervir imediatamente com retoques personalizados de comportamentos desejáveis, reduzindo o risco de desligamento dos usuários.
Depois de criar indicadores de desligamento de usuários, você pode identificar usuários em risco e ajudá-los a se reconectar ao app. O usuário precisa voltar a enxergar o valor do app. Isso pode ser reforçado por meio de lembretes úteis dos recursos aos quais eles já tinham acesso ou gerando empolgação com lançamentos futuros.
Uma das formas de se fazer isso é lembrar aos usuários o que eles já conquistaram com a ajuda do app. O Yazio garante continuamente que o progresso dos usuários seja rastreado de forma visível e celebrado com regularidade, como uma medida para evitar o desligamento. Eles utilizam barras de progresso e telas comemorativas para motivar os usuários a continuar atingindo suas metas.
Não deixe de personalizar o conteúdo o máximo possível para que o usuário se sinta valorizado. O Mobills envia mensagens adaptadas aos usuários com engajamento reduzido, oferecendo presentes e mensagens encorajadoras.
O Lifesum também envia mensagens adaptadas. No entanto, eles destacam o que o usuário pode estar perdendo. Eles se concentram nos lembretes de recursos-chave e no destaque de recursos menos conhecidos que podem convencer o usuário a manter o engajamento.
Se o app utilizar um modelo de assinatura, a janela de renovação é sempre um risco em potencial. O mais importante aqui é agir com base nos sinais certos, no momento certo. Para isso, identifique comportamentos que indicam o desligamento de usuários nas semanas ou nos meses antes do final da assinatura e em que momento eles ocorrem. Você talvez encontre sinais antes do que esperava.
Além disso, não deixe de oferecer outras opções além do cancelamento e comunique-as claramente aos usuários. Eles talvez simplesmente não saibam que existem opções mais acessíveis, de baixo contato ou baseadas em anúncios. Não dê aos usuários motivos para cancelamento!
Ao comunicar ofertas, considere o reenquadramento do valor. A renovação pode ser um assunto delicado. Pode ser necessário testar diferentes mensagens para saber o que funciona melhor com os usuários. Uma mensagem direta sobre os custos, benefícios e opções pode fazer com que o usuário se sinta com mais poder. A comparação do custo com equivalentes do mundo real pode dar alguma perspectiva - o Yazio mostra que o custo mensal de sua assinatura é menor que o de uma xícara de café por dia e do que alguns produtos alimentícios.
E, como sempre, as mensagens personalizadas fazem com que o usuário se sinta valorizado. Durante o fluxo de cancelamento, o Quickbooks mostra o que o usuário já conquistou por meio do app (por exemplo, o controle de 1.000 milhas) e destaca os recursos que estavam sendo pagos, mas que ainda não foram utilizados.
Ao longo das etapas acima, você talvez descubra padrões diferentes de comportamento que levam ao desligamento de usuários e representam grupos de usuários distintos e suas barreiras. Para alguns desses grupos, o desligamento pode ser inevitável. Eles podem representar usuários que não compreendem a proposta de valor do app ou que simplesmente já não o acham útil. Concentre-se nos grupos de usuários que gerarão valor para você em vez de naqueles que você identificar como tendo níveis baixos de atividade, apesar de vários esforços de reengajamento. Lembre-se de que é impossível erradicar completamente o desligamento de usuários.
Esperamos que este artigo ajude você a configurar uma estratégia de minimização do desligamento de usuários. As táticas acima são ferramentas úteis para manter engajados os usuários que estão "em cima do muro" - uma parte essencial do crescimento sustentável de um app - e também para uma estratégia de aquisição e retenção. Para obter mais informações sobre esses tópicos, consulte os recursos abaixo:
A série MAD Skills continua rolando, com conteúdo técnico sobre Modern Android Development. Wojtek Kaliciński e Ben Weiss postaram alguns episódios na segunda série sobre App Bundles. Até agora, vimos conteúdo sobre assinatura de apps do Google Play, como criar seu primeiro App Bundle e entrega de recursos do Google Play. Confira os vídeos e artigos abaixo para saber mais.
Em uma série sobre Android App Bundles, é natural falar sobre assinatura de apps, porque o Google Play gera APKs para download nos dispositivos dos usuários, e esses APKs precisam ser assinados para que possam ser instalados. Este vídeo fala sobre as etapas para ativar a assinatura de um app no Play Console, incluindo opções para ter uma chave gerada pela Google ou fazer upload de uma chave própria.
Certifique-se de conferir o artigo relacionado de Wojtek, que fala das perguntas comuns sobre a assinatura de apps no Google Play:
Answers to common questions about App Signing by Google Play
O vídeo de Ben fala sobre as etapas da criação de um App Bundle, que pode ser feita no Android Studio ou pela linha de comando e sobre seu upload para o Play Console. Ele também mostra como usar as ferramentas do Play Console para explorar informações sobre o bundle carregado.
Este episódio mostra como usar o Android Studio para modularizar seu aplicativo e como selecionar módulos para download no momento da instalação (com condições opcionais que determinam se será feita a instalação ou não) ou sob demanda. Ben também fornece alguns detalhes sobre como usar as APIs para solicitar a instalação de módulos sob demanda.
Configuring your app for Play Feature Delivery
Neste episódio final, Wojtek explica como usar as ferramentas disponíveis para testar um bundle e os APKs resultantes, incluindo o bundletool para testes locais e também o Play Console para testes de uploads.
Há vários artigos e documentos vinculados na descrição do vídeo, portanto, não deixe de conferi-los para ter ainda mais informações sobre o tópico.
Fique ligado no conteúdo final sobre App Bundles, na próxima semana, quando teremos uma sessão de Perguntas e respostas ao vivo, na quinta-feira (um link de vídeo ao vivo do YouTube será exibido na playlist e faremos um tweet solicitando perguntas antes do evento).
Para ver o conteúdo atual, não deixe de conferir a playlist do MAD Skills no YouTube, os artigos no Medium ou esta página de destino útil, a qual fornece acesso a todo o conteúdo. A próxima série começa na semana que vem: fique ligado!
Dentre todas as versões Alfa, Beta e RC incrementais das bibliotecas do AndroidX, algumas versões estáveis importantes foram lançadas recentemente, e eu gostaria de falar sobre elas.
Não é sempre que falamos sobre o Kotlin. Mas, quando falamos, falamos muito. Vários artigos e vídeos sobre o Kotlin foram postados recentemente:
Florina Muntenescu adicionou mais um episódio da atual série Vocabulário do Kotlin, desta vez sobre as classes de dados do Kotlin. As classes de dados permitem criar facilmente uma estrutura para a manutenção de dados com menos código boilerplate, contando com o Kotlin para gerar automaticamente as funções equals() e hashCode() apropriadas. Você também tem a desestruturação das propriedades da classe sem a necessidade de configurações adicionais, juntamente com copy(). Como de costume nos episódios de Vocabulário do Kotlin, Florina explora o bytecode descompilado das classes de dados para explicar como tudo isso funciona nos bastidores.
Data classes — the classy way to hold data
Falando em Vocabulário do Kotlin, Murat Yener postou uma sequência de seu artigo anterior sobre o recurso delegate do Kotlin. Desta vez, ele discute dos delegates fornecidos pela biblioteca padrão do Kotlin: lazy, observable, vetoable e notNull.
Built-in Delegates
A resposta curta é… sim!
Mas, para dar uma explicação mais completa, Florina postou este artigo para responder a algumas das principais perguntas que recebemos dos desenvolvedores relacionadas ao investimento em treinamento e desenvolvimento no Kotlin. Ele inclui links para recursos de aprendizado importantes.
Devo aprender a usar o Kotlin para Android e outras Perguntas frequentes
Neste artigo, Florina discute alguns dos motivos pelos quais os apps Kotlin são menos propensos a erros do que aqueles que não são escritos em Kotlin. Ela fala sobre alguns apps e casos de uso específicos que corroboram essa afirmação, mas também discute alguns dos motivos pelos quais essa linguagem permite um código mais robusto, incluindo nulidade, hashCode() != equals() e muito mais. Confira a postagem para ver todos os detalhes.
Menos falhas e mais estabilidade com o Kotlin
Desde o último Now in Android, publicamos outro episódio do Android Developers Backstage. Confira no link abaixo ou acesse seu cliente de podcast favorito:
Romain Guy, Tor Norbye e eu conversamos com Colin White, da Instacart, sobre sua biblioteca de carregamento de imagens de código: Coil. Batemos um papo sobre carregamento de imagens, desempenho, código aberto e o uso do Kotlin e das corrotinas que compõem essa biblioteca criada inicialmente com o Kotlin.
Episódio 151: Image Loading with Coil
Isso é tudo, por enquanto. Não deixe de aprender sobre os App Bundles. Faça o download das últimas versões do AndroidX. Leia os mais recentes artigos sobre o Kotlin. Ouça o episódio mais recente do podcast do ADB. Em breve, voltaremos com a próxima atualização do universo dos desenvolvedores Android.
