Wiadomości o usługach

Room 3.0 – modernizacja biblioteki Room

Czas czytania: 4 minuty
Wyświetl profil Daniela Santiago Rivery
Daniel Santiago Rivera Software Engineer

Pierwsza wersja alfa Room 3.0 została udostępniona. Room 3.0 to ważna wersja biblioteki, która wprowadza wiele zmian. Koncentruje się ona na Kotlin Multiplatform (KMP) i dodaje obsługę JavaScriptu i WebAssembly (WASM) oprócz dotychczasowej obsługi Androida, iOS i JVM na komputerach.

W tym artykule na blogu opisujemy zmiany powodujące niezgodność, uzasadnienie wprowadzenia Room 3.0 oraz różne sposoby migracji z Room 2.0.

Zmiany powodujące niezgodność

Wersja 3.0 biblioteki Room zawiera te zmiany powodujące niezgodność interfejsu API: 

  • Wycofanie interfejsów SupportSQLite API: Room 3.0 jest w pełni obsługiwany przez interfejsy API sterownika androidx.sqlite. Interfejsy API SQLiteDriver są zgodne z KMP, a usunięcie zależności Room od interfejsu API Androida upraszcza powierzchnię interfejsu API na Androidzie, ponieważ pozwala uniknąć dwóch możliwych backendów.
  • Koniec generowania kodu Java: Room 3.0 generuje wyłącznie kod Kotlin. Jest to zgodne z rozwijającym się paradygmatem Kotlin-first, ale upraszcza też bazę kodu i proces programowania, co umożliwia szybsze iteracje.
  • Skupienie się na KSP: wycofujemy też obsługę przetwarzania adnotacji w Javie (AP) i KAPT. Room 3.0 to procesor KSP (Kotlin Symbol Processing), który umożliwia lepsze przetwarzanie baz kodu w języku Kotlin bez ograniczeń związanych z językiem Java.
  • Współprogramy na pierwszym miejscu:  Room 3.0 wykorzystuje współprogramy Kotlin, dzięki czemu jego interfejsy API są oparte na współprogramach. Korutyny to asynchroniczna platforma zgodna z KMP, a asynchroniczny charakter Room jest kluczowym wymaganiem w przypadku obsługi platform internetowych.

nowy pakiet,

Aby zapobiec problemom ze zgodnością z istniejącymi implementacjami Room w wersji 2.x i bibliotekami z przechodnimi zależnościami od Room (np. WorkManager), Room 3.0 znajduje się w nowym pakiecie, co oznacza, że ma też nową grupę Maven i identyfikatory artefaktów. Na przykład androidx.room:room-runtime zmieniło się w androidx.room3:room3-runtime, a zajęcia takie jak androidx.room.RoomDatabase będą teraz dostępne pod adresem androidx.room3.RoomDatabase.

Kotlin i korutyny w pierwszej kolejności

W wersji 3.0 nie ma już generowania kodu w języku Java, więc Room wymaga KSP i kompilatora Kotlin nawet wtedy, gdy baza kodu współpracująca z Room jest napisana w języku Java. Zalecamy korzystanie z projektu wielomodułowego, w którym użycie biblioteki Room jest skoncentrowane, a wtyczkę Kotlin Gradle Plugin i KSP można zastosować bez wpływu na pozostałą część bazy kodu.

Biblioteka Room 3.0 wymaga też używania korutyn, a funkcje DAO muszą być zawieszane, chyba że zwracają typ reaktywny, np. Flow. Room 3.0 nie zezwala na blokowanie funkcji DAO. Informacje o tym, jak zacząć integrować współprogramy z aplikacją, znajdziesz w dokumentacji współprogramów na Androidzie.

Migracja do interfejsów SQLiteDriver API

W związku z wycofaniem SupportSQLite aplikacje będą musiały przejść na interfejsy SQLiteDriver API. Ta migracja jest niezbędna, aby w pełni wykorzystać zalety biblioteki Room 3.0, w tym umożliwić korzystanie z dołączonej biblioteki SQLite za pomocą BundledSQLiteDriver. Możesz zacząć migrację do interfejsów API sterownika już dziś, korzystając z biblioteki Room w wersji 2.7.0 lub nowszej. Zdecydowanie zalecamy, aby nie używać już biblioteki SupportSQLite. Jeśli przeniesiesz integracje Room do interfejsów API SQLiteDriver, przejście na Room 3.0 będzie łatwiejsze, ponieważ zmiana pakietu polega głównie na aktualizacji odwołań do symboli (importów) i może wymagać minimalnych zmian w miejscach wywołań.

Krótkie omówienie interfejsów API SQLiteDriver znajdziesz w dokumentacji interfejsów API SQLiteDriver.

Więcej informacji o migracji Room do korzystania z interfejsów API SQLiteDriver znajdziesz w oficjalnej dokumentacji migracji z SupportSQLite.

Otoczka Room SupportSQLite

Zdajemy sobie sprawę, że całkowite usunięcie biblioteki SupportSQLite może nie być od razu możliwe w przypadku wszystkich projektów. Aby ułatwić to przejście, w najnowszej wersji Room 2.0, czyli Room 2.8.0, wprowadziliśmy nowy artefakt o nazwie androidx.room:room-sqlite-wrapper. Ten artefakt udostępnia interfejs API zgodności, który umożliwia przekształcenie RoomDatabaseSupportSQLiteDatabase, nawet jeśli interfejsy SupportSQLite API w bazie danych zostały wyłączone z powodu zainstalowania SQLiteDriver. Jest to tymczasowe rozwiązanie dla programistów, którzy potrzebują więcej czasu na pełną migrację bazy kodu. Ten artefakt nadal występuje w Room 3.0 jako androidx.room3:room3-sqlite-wrapper, aby umożliwić migrację do Room 3.0 przy jednoczesnym zachowaniu obsługi krytycznego użycia SupportSQLite.

Na przykład wywołania roomDatabase.openHelper.writableDatabase można zastąpić wywołaniami roomDatabase.getSupportWrapper(), a otoczka będzie dostępna nawet wtedy, gdy setDriver() zostanie wywołana w konstruktorze pokoju.

Więcej informacji znajdziesz w dokumentacji room-sqlite-wrapper.

Obsługa Room i SQLite w internecie

Obsługa Kotlin Multiplatform obejmuje platformy JS i WasmJS i wprowadza niektóre z najważniejszych zmian w interfejsie API. Wiele interfejsów API w Room 3.0 to funkcje zawieszania, ponieważ prawidłowa obsługa pamięci internetowej jest asynchroniczna. Zaktualizowaliśmy też interfejsy API SQLiteDriver, aby obsługiwały internet, a nowy asynchroniczny sterownik internetowy jest dostępny w androidx.sqlite:sqlite-web. Jest to sterownik oparty na skrypcie Web Worker, który umożliwia zapisywanie bazy danych w prywatnym systemie plików źródła (Origin Private File System, OPFS).

Więcej informacji o konfigurowaniu Room w przeglądarce znajdziesz w informacjach o wersji Room 3.0.

Niestandardowe typy zwracane przez DAO

W wersji 3.0 biblioteki Room wprowadzono możliwość dodawania do niej niestandardowych integracji podobnych do RxJava i Paging. Dzięki nowemu interfejsowi API adnotacji o nazwie @DaoReturnTypeConverter możesz utworzyć własną integrację, tak aby wygenerowany przez Room kod był dostępny w czasie działania programu. Umożliwia to funkcjom @Dao posiadanie niestandardowych typów zwracanych bez konieczności czekania na dodanie obsługi przez zespół Room. Obecne integracje są migrowane, aby korzystać z tej funkcji, dlatego użytkownicy, którzy z niej korzystają, muszą dodać konwertery do definicji @Database lub @Dao.

Na przykład konwerter stronicowania znajduje się w artefakcie androidx.room3:room3-paging i nazywa się PagingSourceDaoReturnTypeConverter. Tymczasem w przypadku LiveData konwerter znajduje się w androidx.room3:room3-livedata i nazywa się LiveDataDaoReturnTypeConverter.

Więcej informacji znajdziesz w sekcji DAO Return Type Converters w informacjach o wersji Room 3.0.

Tryb konserwacji Room 2.x

Ponieważ rozwój Room będzie koncentrować się na Room 3, obecna wersja Room 2.x przechodzi w tryb konserwacji. Oznacza to, że nie będą już opracowywane żadne główne funkcje, ale nadal będą się pojawiać wersje z poprawkami (2.8.1, 2.8.2 itd.) zawierające poprawki błędów i aktualizacje zależności. Zespół będzie kontynuować te prace, dopóki Room 3 nie będzie działać stabilnie.

Uwagi końcowe

Jesteśmy bardzo podekscytowani potencjałem biblioteki Room 3.0 i możliwościami, jakie otwiera ona przed ekosystemem Kotlina. Będziemy na bieżąco informować o postępach.

Czytaj dalej