A primeira versão Alfa da Room 3.0 foi lançada. A Room 3.0 é uma versão principal da biblioteca que se concentra na 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 da Room 3.0 e as várias ações que você pode realizar para migrar da Room 2.0.

Alterações importantes

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

• Descontinuação das APIs SupportSQLite:a 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 da Room na API do Android simplifica a superfície da API para o Android, evitando a necessidade de dois back-ends possíveis.
• Fim da geração de código Java:a 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. A 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 em primeiro lugar: a Room 3.0 adota corrotinas Kotlin, tornando as APIs delas prioritárias. As corrotinas são o framework assíncrono compatível com KMP, e tornar a Room assíncrona por natureza é um requisito essencial para oferecer suporte a plataformas da Web.

Um novo pacote

Para evitar problemas de compatibilidade com implementações da Room 2.x e para bibliotecas com dependências transitivas da Room (por exemplo, WorkManager), a Room 3.0 reside em um novo pacote, o que significa que ela também tem um novo grupo do 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 em primeiro lugar

Sem mais geração de código Java, a Room 3.0 também exige o KSP e o compilador Kotlin, mesmo que a base de código que interage com a Room esteja em Java. Recomendamos ter um projeto de vários módulos em que o uso da 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.

A 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. A Room 3.0 não permite funções DAO de bloqueio. Consulte a documentação sobre 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 da 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 a Room 2.7.0 ou mais recente. Recomendamos que você evite qualquer outro uso do SupportSQLite. Se você migrar as integrações da Room para as APIs SQLiteDriver, a transição para a 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 a Room para usar as APIs SQLiteDriver, consulte a documentação oficial para migrar do SupportSQLite.

Wrapper SupportSQLite da 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, a 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 na Room 3.0 como androidx.room3:room3-sqlite-wrapper para permitir a migração para a 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 da Room.

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

Suporte da Room e do SQLite para a Web

O suporte para os destinos da Kotlin Multiplatform JS e WasmJS traz algumas das mudanças mais significativas na API. Especificamente, muitas APIs na 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 persistir o banco de dados no sistema de arquivos particular de origem (OPFS, na sigla em inglês).

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

Tipos de retorno DAO personalizados

A Room 3.0 introduz a capacidade de adicionar integrações personalizadas à 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 da 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 da 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 da Room 3.0.

Modo de manutenção da Room 2.x

Como o desenvolvimento da Room será focado na Room 3, a versão atual da 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ências. A equipe está comprometida com esse trabalho até que a Room 3 se torne estável.

Considerações finais

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