Room 3.0: modernização do Room

A primeira versão Alfa do Room 3.0 foi lançada. O Room 3.0 é uma versão importante da biblioteca que se concentra no Kotlin Multiplatform (KMP) e adiciona suporte para JavaScript e WebAssembly (WASM) além do suporte atual para Android, iOS e JVM. 

Neste blog, descrevemos as mudanças importantes, o raciocínio por trás do Room 3.0 e as várias coisas que você pode fazer para migrar do Room 2.0.

Alterações importantes

O Room 3.0 inclui as seguintes mudanças importantes na API: 

• Descontinuação das APIs SupportSQLite:o Room 3.0 é totalmente compatível com as APIs do driver androidx.sqlite. As APIs SQLiteDriver são compatíveis com KMP, e a remoção da dependência do Room na API do Android simplifica a superfície da API para Android, já que evita ter dois back-ends possíveis.
• Sem geração de código Java:o Room 3.0 gera exclusivamente código Kotlin. Isso está alinhado ao paradigma em evolução do Kotlin, mas também simplifica a base de código e o processo de desenvolvimento, permitindo iterações mais rápidas.
• Foco no KSP:também estamos descontinuando o suporte para o processamento de anotações Java (AP) e o KAPT. O Room 3.0 é apenas um processador KSP (processamento de símbolos do Kotlin), permitindo um melhor processamento de bases de código Kotlin sem ser limitado pela linguagem Java.
• Corrotinas primeiro : o Room 3.0 adota corrotinas Kotlin, tornando as APIs corrotinas primeiro. As corrotinas são o framework assíncrono compatível com KMP, e tornar o Room assíncrono por natureza é um requisito essencial para oferecer suporte a plataformas da Web.

Um novo pacote

Para evitar problemas de compatibilidade com implementações do Room 2.x e para bibliotecas com dependências transitivas do Room (por exemplo, WorkManager), o Room 3.0 reside em um novo pacote, o que significa que ele também tem um novo grupo Maven e IDs de artefato. Por exemplo, androidx.room:room-runtime se tornou androidx.room3:room3-runtime, e classes como androidx.room.RoomDatabase agora estão localizadas em androidx.room3.RoomDatabase.

Kotlin e corrotinas primeiro

Sem mais geração de código Java, o Room 3.0 também exige o KSP e o compilador Kotlin, mesmo que a base de código que interage com o Room esteja em Java. Recomendamos ter um projeto de vários módulos em que o uso do Room seja concentrado e o plug-in do Kotlin Gradle e o KSP possam ser aplicados sem afetar o restante da base de código.

O Room 3.0 também exige corrotinas e, mais especificamente, as funções DAO precisam ser suspensas, a menos que estejam retornando um tipo reativo, como um fluxo. O Room 3.0 não permite o bloqueio de funções DAO. Consulte a documentação de corrotinas no Android para começar a integrar corrotinas ao seu aplicativo.

Migração para APIs SQLiteDriver

Com a mudança do SupportSQLite, os apps precisarão migrar para as APIs SQLiteDriver. Essa migração é essencial para aproveitar todos os benefícios do Room 3.0, incluindo o uso da biblioteca SQLite agrupada pelo BundledSQLiteDriver. Você pode começar a migrar para as APIs do driver hoje mesmo com o Room 2.7.0 ou mais recente. Recomendamos que você evite qualquer outro uso do SupportSQLite. Se você migrar suas integrações do Room para APIs SQLiteDriver, a transição para o Room 3.0 será mais fácil, já que a mudança de pacote envolve principalmente a atualização de referências de símbolos (importações) e pode exigir mudanças mínimas nos locais de chamada.

Para uma breve visão geral das APIs SQLiteDriver, consulte a documentação das APIs SQLiteDriver.

Para mais detalhes sobre como migrar o Room para usar APIs SQLiteDriver, consulte a documentação oficial para migrar do SupportSQLite.

Wrapper SupportSQLite do Room

Entendemos que a remoção completa do SupportSQLite pode não ser viável imediatamente para todos os projetos. Para facilitar essa transição, o Room 2.8.0, a versão mais recente da série Room 2.0, introduziu um novo artefato chamado androidx.room:room-sqlite-wrapper. Esse artefato oferece uma API de compatibilidade que permite converter um RoomDatabase em um SupportSQLiteDatabase, mesmo que as APIs SupportSQLite no banco de dados tenham sido desativadas devido à instalação de um SQLiteDriver. Isso fornece uma ponte temporária para desenvolvedores que precisam de mais tempo para migrar totalmente a base de código. Esse artefato continua existindo no Room 3.0 como androidx.room3:room3-sqlite-wrapper para permitir a migração para o Room 3.0, mantendo o suporte ao uso crítico do SupportSQLite.

Por exemplo, as invocações de roomDatabase.openHelper.writableDatabase podem ser substituídas por roomDatabase.getSupportWrapper(), e um wrapper será fornecido mesmo que setDriver() seja chamado no builder do Room.

Para mais detalhes, consulte a documentação do room-sqlite-wrapper.

Suporte do Room e do SQLite para a Web

O suporte aos destinos do Kotlin Multiplatform JS e WasmJS traz algumas das mudanças mais significativas na API. Especificamente, muitas APIs no Room 3.0 são funções de suspensão, já que o suporte adequado para armazenamento da Web é assíncrono. As APIs SQLiteDriver também foram atualizadas para oferecer suporte à Web, e um novo driver assíncrono da Web está disponível em androidx.sqlite:sqlite-web. É um driver baseado em Web Worker que permite manter o banco de dados no sistema de arquivos particular de origem (OPFS, na sigla em inglês).

Para mais detalhes sobre como configurar o Room para a Web, consulte as notas de lançamento do Room 3.0.

Tipos de retorno DAO personalizados

O Room 3.0 introduz a capacidade de adicionar integrações personalizadas ao Room, semelhantes ao RxJava e ao Paging. Com uma nova API de anotação chamada @DaoReturnTypeConverter, você pode criar sua própria integração para que o código gerado do Room fique acessível no ambiente de execução. Isso permite que as funções @Dao tenham tipos de retorno personalizados sem precisar esperar que a equipe do Room adicione o suporte. As integrações atuais são migradas para usar essa funcionalidade e, portanto, agora exigirão que aqueles que dependem dela adicionem os conversores às definições @Database ou @Dao.

Por exemplo, o conversor de paginação estará localizado no artefato androidx.room3:room3-paging e será chamado de PagingSourceDaoReturnTypeConverter. Enquanto isso, para LiveData, o conversor está em androidx.room3:room3-livedata e é chamado de LiveDataDaoReturnTypeConverter.

Para mais detalhes, consulte a seção Conversores de tipo de retorno DAO nas notas de lançamento do Room 3.0.

Modo de manutenção do Room 2.x

Como o desenvolvimento do Room será focado no Room 3, a versão atual do Room 2.x entra no modo de manutenção. Isso significa que nenhum recurso importante será desenvolvido, mas as versões de patch (2.8.1, 2.8.2 etc.) ainda ocorrerão com correções de bugs e atualizações de dependência. A equipe está comprometida com esse trabalho até que o Room 3 se torne estável.

Considerações finais

Estamos muito animados com o potencial do Room 3.0 e as oportunidades que ele oferece para o ecossistema Kotlin. Fique atento para mais atualizações à medida que continuamos essa jornada.