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:
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 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.
Ou em formato de artigo:
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.
Para comemorar o Dia da Consciência Negra, conversamos com fundadores e desenvolvedores brasileiros de aplicativos, jogos e websites. Conheça as suas trajetórias no mundo da tecnologia e escute dicas e histórias.
Junte-se a nós para celebrar as histórias desses desenvolvedores, ou compartilhe a sua própria história usando #DevsDoBrasil. Você também pode experimentar alguns desses aplicativos, bem como outros criados por desenvolvedores negros, nesta coleção da Google Play Store
Vitor Eleotério, Rio de Janeiro (RJ), Engenheiro de Software do iFood, um aplicativo de entrega de comida no Brasil. Sempre gostou de tecnologia, mas os colegas costumavam zombar dele e desencorajá-lo. Vitor ouviu diversas vezes que seria um ótimo segurança por ser alto e forte. As pessoas diziam que TI era só para quem nasceu em berço de ouro. Com sua paixão e trabalho árduo, ele provou que todos estavam errados. Agora, ele quer motivar outras pessoas a também seguir seus sonhos.
Priscila Aparecida Ferreira Theodoro, São Paulo (SP), Engenheira de Software da Centauro, grande varejista de artigos esportivos no Brasil. Seu primeiro contato com tecnologia aconteceu enquanto trabalhava em uma instituição que ensina programação. Aos 38 anos, Priscila decidiu mudar completamente a carreira e aprendeu a programar. Ela agora ensina programação para mulheres, é mentora de jovens e está envolvida em um projeto de podcast para mulheres desenvolvedoras.
Marcos Pablo, Porto Alegre (RS), Cofundador e CTO da G4IT Solutions, uma plataforma que ajuda as empresas a gerenciar e automatizar o trabalho das equipes que trabalham na rua. Foi a mãe quem o encorajou a entrar no mundo da tecnologia quando ele estava no colégio. Aos 19 anos, Marcos já administrava uma pequena empresa de tecnologia.
Iago Silva Dos Santos, Salvador (BA), Cofundador & CEO do Trazfavela Delivery, uma plataforma para entregas de produtos. Ele queria ajudar sua comunidade, incluindo motoristas, varejistas e pessoas que queriam um acesso mais fácil aos produtos. A TrazFavela é uma das primeiras empresas a receber investimentos do Google Black Founders Fund no Brasil.
Tiago Santos, Araraquara (SP), Fundador e CEO do Husky, um aplicativo
para profissionais brasileiros receberem pagamentos internacionais. Como desenvolvedor de software que trabalha com clientes internacionais, Tiago experimentou em primeira mão como era difícil receber pagamentos no exterior. Com seu amigo Mauricio Carvalho, ele criou o aplicativo para que os profissionais possam se concentrar na carreira em vez de perderem tempo com tarefas burocráticas.
Ronaldo Valentino da Cruz, Londrina (PR), Cofundador & CEO da Oktagon, um estúdio de games que produz títulos e jogos independentes. Aprendeu a programar aos 14 anos e começou a trabalhar com desenvolvimento de jogos em 2002 na Universidade Federal Tecnológica do Paraná. A empresa já lançou títulos mid-core bem recebidos e trabalhou com publicadoras e clientes no mundo todo.
Nohoa Arcanjo Allgayer, São Paulo (SP), Cofundadora & CMO da Creators.LLC, uma rede que conecta talentos da indústria criativa com potenciais clientes. Para Nohoa, não foi uma decisão fácil abandonar seu confortável emprego corporativo para abrir esta startup. Agora ela está orgulhosa do risco que correu, pois isso abriu um mundo de oportunidades e aprendizados sem fim. Ela participou do Programa de Residência Google para Startups e a Creators.LLC foi uma das primeiras startups a receber capital do Google Black Founders Fund no Brasil.
Samuel Matias, Recife (PE), Engenheiro de Software do iFood. Ele se tornou um desenvolvedor em 2015 e é bastante ativo na comunidade Flutter. Samuel frequentemente compartilha seus aprendizados dando palestras e escrevendo artigos online.
Aline Bezzoco, Rio de Janeiro (RJ), Fundadora & Desenvolvedora do Tá tudo bem? - um aplicativo de prevenção do suicídio. Ela acredita que o melhor da tecnologia é a capacidade de criar soluções para ajudar as pessoas. Seu aplicativo ajuda aqueles que lutam com problemas de saúde mental a se sentirem mais calmos, menos ansiosos e a pedirem socorro.
Egio Arruda Junior, Goiânia (GO), Cofundador & CEO da EasyCrédito, uma plataforma que facilita empréstimos. O principal foco é ajudar quem ainda nem tem uma conta em banco. Egio é apaixonado por inovação e está sempre procurando criar algo novo. Participou de dois programas do Google for Startups (Residency e Accelerator).
Márcio Dos Santos, Seattle (EUA), Cofundador & CTO da Facio, uma plataforma de crédito
e educação financeira para colaboradores no Brasil. Entre amigos e familiares, não havia uma pessoa que tinha cursado o Ensino Superior. Márcio decidiu estudar Ciências da Computação por amar videogames. Um professor da Universidade o escolheu para fazer estágio nos Estados Unidos. Atualmente radicado em Seattle, nos Estados Unidos, Márcio gosta de ser procurado e ajudar quem está em início de carreira.
Danielle Monteiro, São Paulo (SP), Engenheira de Dados e Fundadora da Dani.Academy, uma plataforma educacional com cursos gratuitos e pagos sobre dados, arquitetura, NoSQL e infraestrutura. Ela foi a primeira da família a entrar e terminar uma faculdade. Já ganhou muitos prêmios dentro e fora do Brasil e é mentora do Google for Startups. Danielle é apaixonada por retribuir à sociedade compartilhando seus conhecimentos por meio do blog, palestras, cursos e artigos.
----
Essas são apenas algumas das histórias inspiradoras que mostram que o mundo da tecnologia não é para poucos, mas para todos. Juntos, podemos criar mudanças e ver mais pessoas negras encontrando oportunidades em tecnologia. Comemore essas histórias compartilhando esse vídeo: youtu.be/k5J-XamMhGI – youtu.be/k5J-XamMhGI
Se você disponibiliza imagens de contêineres públicos usando o Container Registry ou o Artifact Registry, está expondo o ID do projeto e outros detalhes aos usuários que fazem download dessas imagens. No entanto, ao escrever um pequeno middleware e executá-lo sem servidor, você pode personalizar a forma como seu registro funciona.
Neste artigo, quero mostrar como desenvolver e executar um proxy reverso sem servidor para personalizar o comportamento do registro, como para disponibilizar imagens publicamente em um domínio personalizado em vez de no gcr.io.
Disponibilizar imagens de contêiner a partir de um registro de contêiner não é nada de outro mundo. Todos os registros imagens de contêineres, como o Google Container Registry, o Google Artifact Registry ou o Docker Hub, implementam uma especificação de API aberta.
Portanto, quando você efetivamente executa um comando pull, como docker pull gcr.io/google-samples/hello:1.0, o mecanismo de contêiner subjacente (como o Docker Engine) faz algumas chamadas de API REST HTTP ao endpoint, como https://gcr.io/v2/google-samples/hello-app/manifests/1.0, para descobrir detalhes sobre essa imagem e fazer o download dos blobs de camadas. Você pode usar uma ferramenta como o crane para inspecionar mais a fundo como um registro de contêiner funciona ao tentar executar o pull ou push de uma imagem.
docker pull gcr.io/google-samples/hello:1.0
https://gcr.io/v2/google-samples/hello-app/manifests/1.0
Disponibilizar imagens em domínios personalizados é especialmente útil para imagens públicas, como projetos de código aberto. Isso também ajuda a ocultar dos usuários os detalhes do registro subjacente (como gcr.io/*).
Quando você utiliza um registro como o Container Registry ou o Artifact Registry para disponibilizar imagens publicamente, não só expõe os IDs do projeto ao mundo exterior, mas também acaba tendo nomes de imagens realmente longos:
docker pull us-central1-docker.pkg.dev/<project-id>/<registry-name>/<image-name>
No exemplo acima, é possível ver que o nome da imagem de contêiner determina onde está hospedado o registro e, portanto, a qual host são feitas as chamadas da API. Se você fosse criar um registro que disponibiliza imagens no domínio personalizado, como example.com, poderia executar o pull das imagens especificando example.com/IMAGE:TAG como a referência da imagem do contêiner. As solicitações da API, por sua vez, seriam feitas por proxy para o host real do registro.
example.com/IMAGE:TAG
Para criar essa experiência, basta usar o Google Container Registry ou o Artifact Registry existente para armazenar suas imagens e criar um “proxy reverso" por cima dele para encaminhar as solicitações recebidas, ainda disponibilizando o tráfego no nome de domínio personalizado de sua propriedade.
O Cloud Run é uma ótima opção para hospedar um aplicativo como esse no Google Cloud. O Cloud Run é uma plataforma de hospedagem de contêiner sem servidor, e seu preço é especialmente relevante neste caso, já que você só paga por cada solicitação atendida.
Nesse design, você seria cobrado apenas enquanto uma solicitação estivesse sendo atendida (ou seja, quando alguém estivesse recebendo uma imagem por pull), o que pode ser facilmente enquadrado na camada gratuita.
Quando você utiliza esse proxy com o Google Container Registry, não é feito o download das camadas de imagens reais (blobs) da API do registro (em vez disso, é gerado um link de download do Cloud Storage para o pull do tarball da camada). Uma vez que suas camadas, provavelmente com vários gigabytes, não passam por esse proxy, é fácil manter o controle dos custos no Cloud Run.
No entanto, quando isso é utilizado com o Artifact Registry, uma vez que os blobs de camadas da imagem são disponibilizados por meio desse proxy, o custo será mais alto devido às taxas de rede de saída para disponibilizar os blobs maiores e ao “tempo faturável" mais longo no Cloud Run, como resultado do uso do proxy para as respostas maiores durante uma solicitação.
Para realizar essa tarefa, criei um proxy reverso simples utilizando a linguagem de programação Go em cerca de 200 linhas de código. Esse proxy usa o httputil.ReverseProxy e adiciona um tratamento especial à negociação de credenciais para disponibilizar as imagens públicas (e as imagens privadas publicamente, se necessário).
O código de exemplo e as instruções de implantação podem ser encontrados em meu repositório, github.com/ahmetb/serverless-registry-proxy. Para implantar esse proxy no projeto a fim de disponibilizar imagens públicas em um domínio personalizado, consulte o repositório para ter instruções passo a passo. Resumidamente, você precisa:
<YOUR-DOMAIN>/<IMAGE>:<TAG>
Você pode estender a ideia de criar “proxies de middleware" à frente do registro do contêiner e hospedá-los de forma mais econômica em uma plataforma sem servidor, como o Cloud Run, com custos mínimos.
Por exemplo, você pode criar um proxy de registro que disponibilize apenas determinadas imagens ou tags. Da mesma forma, pode criar sua própria camada de autenticação por cima de um registro existente. Como a API do registro é padrão, meu código de exemplo funciona também para outros registros de contêiner, como o Docker Hub. Assim, é possível hospedar um proxy sem servidor no Cloud Run que disponibiliza imagens do Docker Hub ou de qualquer outro registro.
Sinta-se à vontade para examinar o código-fonte e mexer no projeto para estendê-lo de acordo com suas necessidades. Espero que este exemplo de projeto de código aberto também possa ajudar você a disponibilizar um registro de contêiner em um domínio personalizado.
Artigo relacionado
Imagens de contêiner podem ser criadas por meio de uma variedade de métodos, incluindo Buildpacks, Jib e Dockerfiles. Vamos compará-los.
Há pouco mais de três semanas, realizamos nosso primeiro AMP Fest, onde nos reunimos on-line como uma comunidade para compartilhar o que há de mais recente e melhor no mundo do AMP. Desde o lançamento do novo AMP Page Experience Guide até o excelente novo suporte a clientes ao AMP for Email, o AMP Fest apresentou vários desenvolvimentos incríveis em todo o ecossistema do AMP.
Continue lendo para relembrar o AMP Fest e saber tudo sobre as notícias que você pode ter perdido:
Uma das atualizações mais empolgantes do AMP Fest foi o trabalho de criação de ótimas experiências na página. O AMP foi elaborado para ajudar a promover o desenvolvimento de sites voltados para os usuários, e nós acreditamos que o AMP é uma solução econômica e simples para que os editores possam criar uma ótima experiência na página. Alinhados a isso, compartilhamos que 60% dos domínios AMP são aprovados* pelas métricas do Core Web Vitals, em comparação com 12% dos domínios não AMP, segundo os mesmos critérios.
* “aprovação” significa que 75% das páginas de um domínio foram aprovadas segundo as métricas do Core Web Vitals.
Para ajudar a atingir nossa meta de fazer com que todas as páginas do AMP sejam aprovadas nessas métricas, também lançamos o AMP Page Experience Guide, uma nova ferramenta que fornece aos desenvolvedores AMP feedback prático específico ao AMP sobre como melhorar o desempenho de páginas do AMP. Isso garante que, se uma página do AMP não atender aos sinais de experiência na página, nós podemos fornecer feedback prático ou suporte pessoal como um último recurso para ajudar a resolver problemas de desempenho.
Este ano, anunciamos que estávamos fazendo a transição do nome AMP Stories para Web Stories, devido à expansão do universo de criadores e consumidores que estão desfrutando do formato por meio de ferramentas #nocode. Desde o anúncio, vimos que o formato continua sendo adotado por editores e também pelo Web Creators.
Aproveitando esse momento, anunciamos novas atualizações do formato Web Stories, incluindo a funcionalidade personalizável de testes e sondagens, integração de vídeos em 360 e a capacidade de incorporar o Web Stories diretamente a um site com um Story Player de código aberto completo. Isso segue o recente anúncio da equipe do Web Stories na Google, de que o Web Stories está chegando ao Discover, que faz parte do Google app no Android e no iOS e é utilizado por mais de 800 milhões de pessoas todos os meses.
O AMP for Email já está comercialmente disponível há mais de um ano e meio, e continua sendo uma surpresa ver novos casos de uso para o e-mail dinâmico surgindo todos os dias. No AMP Fest, anunciamos que a Verizon Media (Yahoo Mail) lançou sua prévia para desenvolvedores para o AMP e que os e-mails AMP estarão no Salesforce Marketing Cloud no primeiro trimestre de 2021. Estamos muito felizes por ajudar a levar o e-mail dinâmico a milhões de novos usuários.
Os tipos de experiências que os remetentes do AMP for Email proporcionam a seus clientes nos inspiraram e encantaram totalmente e, no AMP Fest, destacamos vários remetentes que estão usando os e-mails AMP para ajudar seus clientes e consumidores a poupar tempo e dinheiro. Assista à palestra abaixo para ver os resultados impressionantes que os e-mails dinâmicos estão gerando para todos os tipos de remetentes de e-mail:
Com tantas ótimas notícias recebidas no evento, foi muito bom poder contar com desenvolvedores AMP e proprietários de sites de todo o mundo que compartilharam suas histórias de implementação do AMP e dicas sobre como tirar o máximo proveito do AMP.
Violeta Rosales, gerente de engenharia de software da Uno TV, nos mostrou como o outlet de notícias digital fez a transição de seu site para ser “AMP First”, além dos benefícios e desafios enfrentados pela Uno TV nessa transição.
Yosuke Furukawa, engenheiro de software sênior da Recruit, nos mostrou dicas para criar um site “AMP First” e falou sobre tópicos relacionados a bibliotecas, como Next.js, e também estratégias operacionais, como o AMP fora do cache.
Antonio González de León, CTO da Televisa Digital, compartilhou lições sobre a transição da Televisa para “AMP First”, além de outras lições que os editores e desenvolvedores iniciantes podem aprender com veteranos do setor de mídia.
Thomas Feldhaus, diretor executivo da JvM TECH, falou sobre como o AMP ajuda as agências a acelerar o processo de produção de seus sites para clientes e ainda a garantir uma qualidade de execução consistentemente alta.
E, por fim, Jason Caldwell, líder de engenharia de expansão da Automattic, compartilhou como a mudança para o “AMP First” ajudou o WordPress.com a elevar as taxas de conversão, reduzir os custos de aquisição e melhorar o desempenho de suas principais páginas de destino.
Houve muitas palestras incríveis que não pudemos destacar neste resumo. Então, não deixe de conferir a playlist do evento para assistir a todas elas novamente e relembrar esse momento incrível. Queremos agradecer a todos que nos ajudaram a fazer desse evento um grande sucesso. O AMP evoluiu muito desde sua introdução, cinco anos atrás, e estamos mais empolgados do que nunca com o brilhante futuro do AMP!
Postado por Alex Durán, marketing de projeto do AMP na Google
Desde que anunciamos o suporte ao Kotlin em 2017, recebemos muitas perguntas sobre o Kotlin no Android: vocês queriam saber se já é hora de aprender a utilizar a linguagem e de introduzi-la nos apps, qual é o melhor curso ou tutorial para aprender a usar o Kotlin, se a Google está usando essa linguagem internamente e quais são nossos planos para a linguagem de programação Java. Nesta postagem, vou responder a algumas dessas perguntas.
As perguntas que recebemos com mais frequência estão na mesma linha:
Resposta curta:
Sim! Comece a aprender e a usar o Kotlin!
Resposta longa:
Em 2017, anunciamos o suporte ao Kotlin no Google I/O. Foi então que começamos a dar os primeiros passos para garantir que nossas APIs, nossos documentos e nossas amostras fossem compatíveis com o Kotlin. Em 2019, o Android passou a usar o Kotlin como prioridade, então, começamos a depender ainda mais dos recursos do Kotlin. Como um exemplo, as corrotinas se tornaram nossa solução recomendada para a execução do trabalho assíncrono. Veja o que mais fizemos:
Começamos adicionando o suporte de primeira classe às corrotinas do Kotlin a várias de nossas APIs do Android Jetpack, como Room, LiveData, ViewModel e WorkManager, transformando a forma como executamos as operações assíncronas no Android. O SDK do Firebase para Android e muitas bibliotecas do Jetpack têm bibliotecas de extensão do Kotlin (KTX) para facilitar o uso delas com o Kotlin.
Agora, muitas de nossas bibliotecas, como Paging 3.0 e DataStore, são criadas inicialmente com o Kotlin. O Jetpack Compose, nosso novo kit de ferramentas de IU declarativo e não empacotado, foi escrito do zero em Kotlin.
A alta produtividade no desenvolvimento é resultado de um ótimo conjunto de ferramentas. Por isso, temos feito muitas melhorias no Kotlin na parte do conjunto de ferramentas de compilação, incluindo aprimoramentos do compilador JVM do Kotlin, otimizações R8 específicas ao Kotlin e até mesmo o desenvolvimento de novas ferramentas, como o processamento de símbolos do Kotlin. Adicionamos modelos dinâmicos do Android Kotlin integrados, que permitem usar abreviações para adicionar compilações comuns do Android a apps Kotlin. Ao mesmo tempo, novas verificações Lint específicas ao Kotlin ajudam a tornar o código do Kotlin mais idiomático. Isso é especialmente útil durante a transição da linguagem de programação Java para o Kotlin.
No Google, também estamos usando o Kotlin. Mais de 60 de nossos apps (como Google Home, Drive, Maps e outros) já adicionaram o Kotlin às suas bases de código. Nossa grande base de código interna conta com mais de dois milhões de linhas de código Kotlin.
Recebemos essa pergunta com frequência, mas a resposta é que isso depende do desenvolvedor. Se você estiver satisfeito com a base do código e o conjunto de tecnologias atuais, tiver o conhecimento adequado para usar a solução para gerenciar tarefas assíncronas e tiver uma forma eficiente de detectar erros, talvez a migração não seja a solução para você.
Se você gostar do que viu no Kotlin ao experimentá-lo, ou ao aprender a linguagem por meio de alguns dos cursos mencionados abaixo, e também quiser se beneficiar das mais recentes APIs do Jetpack, cogite a adição do Kotlin a seus apps. Uma das vantagens do Kotlin é sua ótima interoperabilidade com a linguagem de programação Java. Você pode dar pequenos passos, um de cada vez, em sua adoção — talvez, primeiro experimentando-o em testes e, depois, em novos recursos. E, mais tarde, pode tentar converter uma parte do código mais antigo durante os retoques.
Para dar seus primeiros passos na migração para o Kotlin idiomático, confira nosso codelab Converting to Kotlin.
Adicionamos o suporte ao Kotlin além do Java porque os dois são compilados para o mesmo bytecode e podem conviver lado a lado. Adoramos o Kotlin pela forma expressiva e mais segura de escrever o código. Continuamos mantendo e evoluindo nosso suporte ao Java. Por exemplo, no Android 11, adicionamos o suporte a várias APIs de versões mais recentes do OpenJDK, até a versão 13, e o Android Studio permite até mesmo usar algumas dessas APIs em todos os dispositivos Android, independentemente da versão do SO. Leia mais sobre o suporte a APIs mais recentes da linguagem aqui.
Adotar uma nova linguagem não é uma tarefa simples, mas estamos tentando facilitar o processo o máximo possível:
Desde que adicionamos oficialmente o suporte ao Kotlin, três anos atrás, temos aprimorado o suporte a essa incrível linguagem e seu ecossistema. Juntamente com a JetBrains, formamos uma base para o Kotlin a fim de garantir que a linguagem amadureça bem, por exemplo, com um processo cuidadoso para impedir as alterações interruptivas. Nossas contribuições se estendem para além disso: o Google tem uma equipe de engenheiros que contribuem para o compilador do Kotlin em tempo integral, as APIs do Jetpack que estamos criando não apenas dão suporte ao Kotlin, mas são criadas inicialmente com essa linguagem de programação, e estamos comprometidos em fazer do uso do Kotlin no Android uma experiência perfeita.
MAD Skills é uma nova série de conteúdo que ensina os desenvolvedores a usar as tecnologias Modern Android Development (MAD, ou desenvolvimento moderno no Android) para criar aplicativos com mais facilidade. A série tinha acabado de ser lançada quando fiz a postagem do último Now in Android. Algumas semanas depois, a primeira minissérie sobre o componente de navegação está completa. Bem… quase completa. Temos ainda um episódio sobre navegação: uma sessão de Perguntas e respostas ao vivo.
Um dos nossos objetivos com o MAD Skills era não só ensinar como utilizar os vários recursos do Modern Android Development, mas também conhecer os problemas e as dúvidas dos desenvolvedores para tentarmos ajudá-los. Por isso, ao final de cada minissérie, faremos uma sessão de Perguntas e respostas ao vivo no YouTube.
Antes, usaremos o Twitter para receber algumas perguntas. Também tentaremos colocar perguntas ao vivo no Twitter e no YouTube. Depois, teremos uma conversa com alguns dos especialistas que trabalham no produto para saber o que eles recomendam.
Para o componente de navegação, farei uma sessão de Perguntas e respostas ao vivo com Ian Lake nesta quinta-feira, às 10h (horário do Pacífico). Envie perguntas por este thread do Twitter (ou simplesmente poste tweets usando #AskAndroid) e participe conosco da sessão, se puder. Postaremos o vídeo no final, para que você ainda possa acompanhar o programa ao vivo… mesmo que ele não esteja mais ao vivo.
Caso tenha perdido os episódios sobre navegação, você poderá vê-los em formato de vídeo e artigo:
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. E fique ligado no próximo conteúdo do MAD; a próxima série começa na semana que vem!
Em primeiro lugar, o AndroidX disponibilizou mais bibliotecas para contribuições por meio do GitHub.
Sabemos que muitos desenvolvedores preferem o fluxo conhecido de contribuição do GitHub ao sistema AOSP+Gerrit tradicionalmente utilizado pelo Android e ficariam muito felizes se utilizássemos mais o GitHub.
O que é uma ótima ideia! Mas também algo difícil de realizar (considerando a infraestrutura que utilizamos). Mas nós ouvimos você e começamos a explorar a possibilidade, disponibilizando algumas das bibliotecas em desenvolvimento ativo no GitHub, começando alguns meses atrás com Paging, Room e WorkManager. Recentemente, também adicionamos as bibliotecas Activity, Fragment e Navigation. Confira e, se quiser contribuir, veja mais detalhes no documento CONTRIBUTING.
Temos a variedade de costume de versões Alfa, Beta, RC e estáveis, incluindo esta versão estável que é digna de nota:
MediaRouter 1.2.0: esta versão é interessante porque adiciona uma funcionalidade que se sincroniza com algumas das novas funcionalidades de mídia do Android 11.
O Android 11 adicionou algumas coisas muito legais de IU para media players, enviando os controles de mídia para um novo espaço dedicado no painel de notificação, o que facilita o controle da mídia em um só local, em vez de intercalá-lo com o restante das notificações. Não se trata de uma nova funcionalidade de desenvolvimento, mas sim de uma apresentação diferente para as notificações que você provavelmente já está criando. Você pode continuar usando as APIs MediaSession e MediaStyle disponíveis desde a versão Lollipop.
Mas algumas funcionalidades novas foram adicionadas ao Android 11 para a “transferência transparente de mídia”, que permite que os usuários troquem de dispositivo de reprodução usando o alternador de saída (mostrado abaixo). Essa nova versão do MediaRouter permite interagir com esse novo recurso da plataforma.
Se você quiser ver as mudanças relacionadas a mídia no Android 11, confira o vídeo What’s New in Media de Don Turner.
Eu também gostaria de destacar algumas versões Alfa interessantes. Geralmente, não falo muito sobre as versões Alfa porque, bom, elas são versões Alfa e, portanto, estão sujeitas a mudanças e iterações à medida que a equipe continua trabalhando nelas. Mas surgiram novas versões do Paging e do Navigation (hoje mesmo!) que são interessantes em termos do que indicam para o futuro do desenvolvimento.
Uma das perguntas que temos recebido recentemente, durante a jornada do Jetpack Compose pela fase Alfa, é: “Qual é o futuro da [insira aqui sua biblioteca do Jetpack favorita] no mundo do Jetpack Compose?”.
E essa é uma excelente pergunta! A resposta é que muitos dos componentes da arquitetura não têm a ver especificamente com visualizações ou com o kit de ferramentas de IU existente, portanto, eles serão igualmente necessários e úteis no novo mundo do Jetpack Compose. Mais do que isso, estamos criando integrações para facilitar o trabalho em conjunto dos diferentes componentes. O Compose já oferece integrações com ViewModels e LiveData, e o dia de hoje marca a primeira versão do suporte ao Paging e ao Navigation para o Jetpack Compose.
Recentemente, foram feitas algumas postagens sobre os recursos de linguagem do Kotlin que vale a pena conferir.
Florina Muntenescu postou um novo artigo e vídeo sobre o recurso de desestruturação do Kotlin. A desestruturação cria uma forma conveniente de atribuir diversas variáveis aos valores de diferentes campos de um objeto. Por exemplo, você pode ter a seguinte classe de dados:
data class Donut( dough: String, topping: String)
e rapidamente atribuir variáveis aos campos de uma instância Donut com:
val (dough, topping) = someDonut
A desestruturação funciona automaticamente para classes de dados, mas é possível fornecer funções em outras classes para dar a elas também o recurso de desestruturação.
Breaking down destructuring declarations
Meghan Mehta lançou um novo artigo falando sobre o recurso de linguagem de extensões do Kotlin. As extensões permitem adicionar novos métodos ou propriedades a classes existentes… mais ou menos. As extensões não são realmente inseridas em uma classe existente, mas essa é a aparência para os autores das chamadas a esses métodos. (Spoiler: elas são implementadas internamente como métodos estáticos que recebem uma instância da classe.)
Esse é, provavelmente, meu recurso favorito do Kotlin: como desenvolvedor de APIs, adoro a ideia de poder melhorá-las no futuro por meio da adição de APIs capazes de sobreviver fora da plataforma ou biblioteca central, mas que parecem totalmente à vontade na forma como são utilizadas no código. Então, por exemplo, eu poderia criar um método de extensão na classe String, String.isAGoodDonutName(). Depois, os autores das chamadas que utilizassem meu método de extensão poderiam chamá-lo diretamente em uma String, como “Sprinkle”.isAGoodDonutName(), em vez da abordagem de outras linguagens de fazer a chamada por meio de outro pacote/classe, como Utils.StringMethods.isAGoodDonutName(“Sprinkle”). Não é tão legal, mesmo que estejamos falando de donuts.
Extend your code readability with Kotlin extensions
E, por fim, Manuel Vivo publicou um novo vídeo sobre “os ABCs das corrotinas”, no qual explica tópicos como CoroutineScope, CoroutineContext, Dispatchers e Jobs. Na verdade, está mais para os CDJs do que para os ABCs das corrotinas.
Um dos aspectos mais complicados da publicação de apps é garantir que eles sigam as diretrizes da loja, cuja função é criar um bom ecossistema de apps para os usuários. Mas, às vezes, pode ser difícil saber exatamente como fazer isso de forma correta. Por isso, a Play Store publicou este artigo para ajudar você a compreender algumas das violações comuns que causam problemas e como evitá-las.
Algumas dessas áreas incluem uma IU de app com links para a Play Store, descrições mais concentradas nos termos de pesquisa do que em um resumo claro do app e apps que são simplesmente um wrapper de WebView em torno de conteúdo de sites.
Dicas para desenvolvedores e guias: Violações comuns de políticas e como evitá-las
A Droidcon teve uma abordagem interessante durante a temporada de conferências exclusivamente on-line, combinando muitos de seus eventos anuais em eventos maiores, em vários fusos horários. A versão dessa conferência para a região EMEA aconteceu em outubro, e todos os vídeos (de alguns de nós da equipe e também de muitos desenvolvedores da comunidade geral) já estão disponíveis on-line:
Vídeos
(Fique ligado nas versões para as Américas e para a região APAC [Ásia-Pacífico], que acontecerão nas próximas semanas.)
A série MotionTags de screencasts postou mais dois episódios desde nossa última postagem.
O Episódio 7 fala sobre <KeyAttribute>, a tag que contém propriedades da visualização, como seus valores transform e alpha.
O Episódio 8 fala sobre <KeyCycle>. Essa tag tem muitos atributos iguais à KeyAttribute, mas também oferece propriedades que definem a forma de onda sendo usada para uma animação, o que pode produzir um comportamento de movimento realmente interessante. Observe que há uma ferramenta CycleEditor autônoma para facilitar a criação e edição de KeyCycles.
Veja esses episódios, juntamente como o restante da série, na playlist do MotionTags:
O novo Udacity Android Kotlin Developer Nanodegree acaba de ser lançado. Esse curso se destina àqueles que desejam saber como criar apps Android no Kotlin seguindo práticas recomendadas. Para saber os pré-requisitos e outros detalhes, confira a visão geral do programa.
Observe que o nanodegree é um programa pago que inclui projetos com feedback, suporte de mentores técnicos e serviços de carreira da Udacity. No entanto, o conteúdo subjacente do curso que a Google desenvolveu com a Udacity é gratuito e disponível a todos. Você pode verificar esse conteúdo em Developing Android Apps with Kotlin e Advanced Android with Kotlin.
Romain Guy e eu batemos um papo com Dustin Lam e Chris Craik, da equipe do Kit de ferramentas do Android, sobre a nova versão 3.0 da biblioteca Paging (“Paging 3”). Essa versão (atualmente na fase Alfa) foi totalmente reescrita em Kotlin, utilizando corrotinas e o Flow, por vários motivos que serão explicados no podcast. Confira para saber mais.
Episódio 151: Paging3
Isso é tudo, por enquanto. Confira a série MAD Skills. Faça o download das últimas bibliotecas do AndroidX. Conheça os recursos de linguagem do Kotlin. Veja os mais recentes artigos e vídeos para desenvolvedores. Obtenha um nanodegree. 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.
Os usuários esperam ter uma boa experiência com o app. As falhas podem levar ao aumento de avaliações ruins, a desinstalações e até mesmo prejudicar a percepção sobre a marca. Em conversas com a comunidade, ficamos sabendo que um dos principais motivos da adoção do Kotlin é a maior segurança do código. Nesta postagem, compartilharei como o Kotlin melhorou a estabilidade do código de alguns de nossos parceiros. Além disso, vamos analisar os resultados de algumas estatísticas da Google Play Store para ver se existe uma correlação entre o uso do Kotlin e o número de falhas (spoiler: sim, existe).
A qualidade de um app não afeta apenas a experiência do usuário. Vários outros elementos são afetados por um alto número de falhas:
Os apps criados com o Kotlin têm 20% de menos de probabilidade de falhas.
Qual é o papel do Kotlin nisso tudo? Analisamos os 1.000 apps de maior destaque no Google Play e notamos que os apps que usam o Kotlin apresentam 20% a menos de falhas por usuário do que os que não o utilizam.
Um exemplo disso vem da equipe de engenharia do Swiggy, que tem 74% do código em Kotlin – eles observaram uma redução de 50% nas falhas desde a mudança do desenvolvimento de novos recursos para o Kotlin.
A principal causa de falhas no Google Play são os NullPointerExceptions. Em 2018, a equipe do Google Home começou a escrever todos os novos recursos em Kotlin e observou uma redução de 33% nas falhas de ponteiro nulo ao longo de um ano.
O Google Home teve uma redução de 33% em NullPointerExceptions
Para evitar NullPointerExceptions, é preciso assegurar que as referências a objetos com as quais você está trabalhando não sejam nulas antes de chamar métodos nelas ou tentar acessar seus assinantes. No Kotlin, a nulidade faz parte do sistema de tipos. Por exemplo, uma variável precisa ser declarada desde o início como anulável ou não anulável. Ao tornar a nulidade uma parte do sistema de tipos, você não precisa depender da memorização e do conhecimento da base do código nem de avisos de tempo de compilação (se você anotar os campos/parâmetros com @Nullable). Em vez disso, a nulidade é imposta, portanto, você receberá erros de tempo de compilação, não apenas avisos. Para ver como lidar com a nulidade, confira esta página.
Nós, desenvolvedores, introduzimos muitos problemas sem perceber, e vários deles podem ser bastante sutis e difíceis de investigar. Veja a seguir alguns desses problemas que são evitados com o uso do Kotlin.
Se dois objetos forem iguais, então seus hashcodes deverão ser iguais. Mesmo assim, é muito comum esquecer de implementar um desses métodos ou de atualizá-los quando novas propriedades são adicionadas à classe. Ao trabalhar com classes cuja função é apenas manter os dados, use as classes de dados do Kotlin. Com as classes de dados, hashCode() e equals() são gerados para você pelo compilador e, portanto, atualizados automaticamente quando há uma mudança nas propriedades da classe.
Dois objetos são estruturalmente iguais (têm conteúdos equivalentes) ou referencialmente iguais (seus ponteiros são os mesmos)? Na linguagem de programação Java, para os primitivos, você sempre usaria ==. Portanto, um erro comum é chamar == (igualdade referencial) também para os objetos, quando, na verdade, o correto é verificar se eles são estruturalmente iguais (verificação feita pela chamada a equals()). Primeiro, o Kotlin não tem tipos primitivos. Ele usa classes como Int ou String, o que significa que não é mais preciso fazer essa diferenciação entre objetos e tipos primitivos, já que todos são objetos. Em segundo lugar, o Kotlin definiu == para a igualdade estrutural e === para a igualdade referencial, portanto, não será preciso verificar a igualdade referencial quando isso não for necessário.
Ao trabalhar com enums, geralmente é preciso garantir que todos os casos possíveis sejam cobertos. Isso leva ao uso de uma chave ou de uma cadeia de if elses. Quando você modifica o enum para adicionar um novo valor, precisa verificar manualmente cada snippet de código no qual está usando o enum e assegurar que esteja lidando com o novo caso. Mas esse é um processo propenso a erros. No Kotlin, você pode usar o compilador para isso, se estiver usando when como uma expressão: você receberá um erro do compilador se não estiver cobrindo todas as ramificações possíveis.
A estabilidade de um app é importante para os usuários e para a sua marca. Comece a usar o Kotlin para reduzir as taxas de falha, manter os usuários satisfeitos e ficar sempre em uma boa colocação na retenção e aquisição, mantendo uma classificação alta dos apps.
Saiba mais sobre como você pode criar apps melhores com o Kotlin e leia nossos estudos de casos para ver como os desenvolvedores se beneficiaram com o Kotlin. Para dar seus primeiros passos no Kotlin, uma das linguagens mais amadas do mundo, confira nossa página Primeiros passos.