📝 O recente lançamento do WorkManager 2.5.0 facilita a utilização em ambientes multiprocesso e oferece várias melhorias de estabilidade.
Portanto, se você tem um app que gerencia vários processos e precisa de uma forma robusta para gerenciar o trabalho em segundo plano (sem mais erros de inicialização ️️⚠), essa é a versão para você.
Você terá que fazer algumas alterações no código, por isso, continue lendo para saber mais.
Ao final deste artigo, também listarei algumas outras alterações de comportamento e as mais recentes adições desta versão da biblioteca WorkManager.
Apresentamos o work-multiprocess
O novo artefato multiprocess introduz ganhos de desempenho com a unificação da programação de jobs em um único processo. Para começar, adicione-o ao app.
Agora, você pode escolher o processo designado que o WorkManager usa para enfileirar WorkRequests e executar seu programador em processo.
Uma configuração que use Configuration.Provider pode ser semelhante a esta.
class MyApplication() : Application(), Configuration.Provider { override fun getWorkManagerConfiguration() = Configuration.Builder() .setProcessName("com.example:remote") .build() }
Observação: o parâmetro em setProcessName exige a transmissão do nome totalmente qualificado do processo, que consiste no nome do pacote do app, seguido por dois-pontos e pelo nome do processo do host, por exemplo, com.example:remote.
Ao usar work-multiprocess, também convém usar RemoteWorkManager em vez de WorkManager para gerenciar suas solicitações de trabalho. RemoteWorkManager sempre contatará o processo designado para enfileirar o trabalho para você. Isso garante que você não inicialize acidentalmente um novo WorkManager no processo de chamada. O programador em processo também é executado no mesmo processo designado.
Benefícios
Com o WorkManager configurado dessa forma e o uso do RemoteWorkManager para programar seus jobs, agora você pode apreciar seu trabalho sendo gerenciado com mais rapidez e confiabilidade no app multiprocesso. Isso porque a contenção do SQLite pode ser amplamente reduzida (uma vez que não dependemos mais dos bloqueios baseados em arquivo) e a reconciliação de jobs entre processos não será mais necessária porque o app terá uma única instância do WorkManager em execução em um processo que você pode designar.
Alterações de comportamento 🔀
Reconciliação de jobs
Antes, quando o ActivityManager não conseguia instanciar o JobService para iniciar um job, esse job era descartado silenciosamente devido a um bug subjacente da plataforma. Agora, o WorkManager garante que haja um job programador de apoio para cada WorkRequest quando uma instância de Aplicativo é criada com a reconciliação de objetos WorkRequest com os jobs.
Limite o crescimento do banco de dados interno
Vimos que uma das causas de falhas de apps era o esgotamento do armazenamento no dispositivo. Isso acontecia principalmente nos dispositivos que tinham baixa capacidade de armazenamento. No entanto, quando os apps programavam muito trabalho, o WorkManager era parcialmente responsável por esse esgotamento de capacidade.
Por padrão, os jobs ficavam registrados em um banco de dados interno do WorkManager por sete dias. Isso foi reduzido para um dia, o que diminui drasticamente o tamanho do banco de dados.
Embora tenhamos encurtado a duração do buffer, você pode controlar por quanto tempo seu job deve ser memorizado usando a API keepResultsForAtLeast() .
Nova API de teste ✨
Se você estiver usando o ListenableFuture com o WorkManager, o teste ficou mais fácil — a extensão do Kotlin TestListenableWorkerBuilder agora assume qualquer classe que estenda ListenableWorker, dando mais flexibilidade durante o teste.
Correções de bugs 🐛
Além dos novos recursos, essa versão também contém várias correções de bugs que melhoram a estabilidade, a confiabilidade e o desempenho do WorkManager. Você pode saber sobre todas as alterações e os bugs corrigidos nas notas da versão.
O que você pode fazer para melhorar o WorkManager
Contribua com o WorkManager pelo GitHub 👩💻
O WorkManager, assim como várias outras bibliotecas do Jetpack, pode aceitar contribuições via GitHub.
A maioria dos bugs corrigidos na versão 2.5.0 foi conhecida por meio das informações do Issue Tracker público.
A melhor forma de criar um problema para que possamos corrigi-lo é criar um problema que possamos reproduzir. Para nos ajudar a reproduzir um problema, recomendamos usar a amostra do WorkManager ou fornecer a sua própria amostra codificada com instruções na descrição do problema.
Essa é a hora certa para colocar mãos à obra e fazer aquela atualização da versão da biblioteca de seu app.
Em dezembro, abrimos a Google Play Store para a publicação de novos apps Android Auto para testes fechados. Hoje, você pode atingir mais motoristas com a publicação de apps de navegação, estacionamento e carregamento em faixas de testes abertos na Google Play Store. Com os testes abertos, não há limite para o número de usuários que podem fazer o download de um app e não é necessário gerenciar listas de endereços de e-mail. Esse é um marco importante, que nos aproxima da disponibilização desses apps para todos os usuários em produção. Comece com a biblioteca de apps do Android para carros e selecione uma faixa de teste aberto no Play Console.
TomTom AmiGO, um de nossos parceiros de acesso antecipado
Para que você possa saber o que vem por aí, estamos trabalhando na adição da biblioteca ao Android Jetpack. Isso permitirá mais consistência com outras APIs do Jetpack e visibilidade dos novos recursos. Quando a biblioteca do Jetpack estiver pronta, a migração de um app da biblioteca existente será um processo direto: simplesmente alterar o namespace e modificar algumas chamadas de API. Após a estabilização da biblioteca no Jetpack, prepararemos a Google Play Store para publicar esses novos apps em faixas de produção.
Você pode começar hoje mesmo. Não é preciso esperar pela biblioteca do Jetpack.
