A primeira versão alfa do Room 3.0 foi lançada. O Room 3.0 é uma versão principal 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 para computador. 

Neste blog, descrevemos as mudanças incompatíveis, 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.

Mudanças importantes

O Room 3.0 inclui as seguintes mudanças interruptivas da API: 

• Descontinuação das APIs SupportSQLite:o Room 3.0 é totalmente compatível com as APIs de 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 plataforma de API para Android, já que evita ter dois backends possíveis.
• Não há mais geração de código Java:o Room 3.0 gera exclusivamente código Kotlin. Isso se alinha ao paradigma em evolução do Kotlin como prioridade, 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 vamos descontinuar o suporte ao processamento de anotações (AP) do Java e ao KAPT. O Room 3.0 é apenas um processador KSP (Kotlin Symbol Processing), permitindo um melhor processamento de bases de código Kotlin sem ser limitado pela linguagem Java.
• Corrotinas primeiro : o Room 3.0 adota as corrotinas Kotlin, tornando as APIs dele compatíveis com corrotinas. 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 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, 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 esteja concentrado e o plug-in do Gradle para Kotlin 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, que as funções DAO sejam de suspensão, a menos que retornem um tipo reativo, como um fluxo. O Room 3.0 não permite funções de bloqueio de DAO. 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 do Room 3.0, incluindo o uso da biblioteca SQLite agrupada pelo BundledSQLiteDriver. Você pode começar a migrar para as APIs de driver hoje mesmo com o Room 2.7.0 ou versões mais recentes. Recomendamos evitar o uso do SupportSQLite. Se você migrar suas integrações do Room para as 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, confira a documentação das APIs SQLiteDriver.

Para mais detalhes sobre como migrar o Room para usar as APIs SQLiteDriver, confira 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, a Room 2.8.0, a versão mais recente da série 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 oferece 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 e ainda oferecer 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 wrapper room-sqlite.

Suporte da Web para Room e SQLite

O suporte para as plataformas múltiplas do Kotlin tem como destino JS e WasmJS e 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 privado de origem (OPFS, na sigla em inglês).

Para mais detalhes sobre como configurar o Room para a Web, confira as notas da versão do Room 3.0.

Tipos de retorno de DAO personalizados

O Room 3.0 apresenta a capacidade de adicionar integrações personalizadas ao Room, semelhantes ao RxJava e ao Paging. Com uma nova API de anotação chamada @DaoReturnTypeConverter, é possível criar sua própria integração para que o código gerado pelo Room fique acessível durante a 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 exigem que quem depende dela adicione os conversores às definições de @Database ou @Dao.

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

Para mais detalhes, confira a seção "Conversores de tipo de retorno de DAO" nas notas da versão do Room 3.0.

Modo de manutenção do Room 2.x

Como o desenvolvimento do Room vai se concentrar no Room 3, a versão atual do Room 2.x vai entrar no modo de manutenção. Isso significa que nenhum recurso importante será desenvolvido, mas ainda haverá lançamentos de patch (2.8.1, 2.8.2 etc.) com correções de bugs e atualizações de dependências. 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 de olho nas próximas atualizações enquanto continuamos essa jornada.