Ukazała się pierwsza wersja alfa biblioteki Room 3.0. Room 3.0 to główna wersja biblioteki, która wprowadza zmiany powodujące niezgodność. Koncentruje się 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 poście opisujemy zmiany powodujące niezgodność, uzasadnienie wprowadzenia biblioteki Room 3.0 oraz różne sposoby migracji z Room 2.0.
Zmiany powodujące niezgodność
Room 3.0 zawiera te zmiany powodujące niezgodność z interfejsem API:
- Wycofanie interfejsów API SupportSQLite: Room 3.0 jest w pełni obsługiwana 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 interfejs API na Androidzie, ponieważ eliminuje konieczność obsługi 2 możliwych backendów.
- Brak generowania kodu Java: Room 3.0 generuje wyłącznie kod Kotlin. Jest to zgodne z rozwijającym się paradygmatem Kotlin-first, ale też upraszcza bazę kodu i proces tworzenia, co umożliwia szybsze iteracje.
- Skupienie się na KSP: wycofujemy też obsługę przetwarzania adnotacji Java (AP) i KAPT. Room 3.0 jest wyłącznie procesorem KSP (Kotlin Symbol Processing), co umożliwia lepsze przetwarzanie baz kodu Kotlin bez ograniczeń języka Java.
- Współprogramy jako priorytet: Room 3.0 wykorzystuje współprogramy Kotlin, dzięki czemu jej interfejsy API są oparte na współprogramach. Współprogramy to asynchroniczny framework zgodny z KMP, a asynchroniczny charakter Room jest kluczowym wymaganiem do obsługi platform internetowych.
Nowy pakiet
Aby zapobiec problemom ze zgodnością z dotychczasowymi implementacjami Room 2.x i bibliotekami z zależnościami przechodnimi do 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ł się na androidx.room3:room3-runtime, a klasy takie jak androidx.room.RoomDatabase będą teraz znajdować się w androidx.room3.RoomDatabase.
Kotlin i współprogramy jako priorytet
Ponieważ nie generujemy już kodu Java, Room 3.0 wymaga też KSP i kompilatora Kotlin, nawet jeśli baza kodu, która wchodzi w interakcję z Room, jest napisana w Javie. Zalecamy używanie projektu wielomodułowego, w którym użycie Room jest skoncentrowane, a wtyczkę Kotlin Gradle i KSP można zastosować bez wpływu na resztę bazy kodu.
Room 3.0 wymaga też współprogramów, a konkretnie funkcji DAO, które 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 API SQLiteDriver
W związku z wycofywaniem się z SupportSQLite aplikacje będą musiały przejść na interfejsy API SQLiteDriver. Ta migracja jest niezbędna, aby w pełni wykorzystać zalety Room 3.0, w tym możliwość używania dołączonej biblioteki SQLite za pomocą BundledSQLiteDriver. Migrację do interfejsów API sterownika możesz rozpocząć już dziś, korzystając z Room 2.7.0 lub nowszej wersji. Zdecydowanie zalecamy unikanie dalszego używania SupportSQLite. Jeśli zmigrujesz 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ótki przegląd interfejsów API SQLiteDriver znajdziesz w dokumentacji interfejsów API SQLiteDriver.
Więcej informacji o tym, jak zmigrować Room do korzystania z interfejsów API SQLiteDriver, znajdziesz w oficjalnej dokumentacji migracji z SupportSQLite.
Otoka SupportSQLite w Room
Rozumiemy, że całkowite usunięcie SupportSQLite może nie być od razu możliwe w przypadku wszystkich projektów. Aby ułatwić przejście, w Room 2.8.0, najnowszej wersji z serii Room 2.0, wprowadziliśmy nowy artefakt o nazwie androidx.room:room-sqlite-wrapper. Ten artefakt oferuje interfejs API zgodności, który umożliwia przekształcenie RoomDatabase w SupportSQLiteDatabase, nawet jeśli interfejsy API SupportSQLite w bazie danych zostały wyłączone z powodu zainstalowania SQLiteDriver. Jest to tymczasowe rozwiązanie dla deweloperów, którzy potrzebują więcej czasu na pełną migrację bazy kodu. Ten artefakt nadal istnieje w Room 3.0 jako androidx.room3:room3-sqlite-wrapper, aby umożliwić migrację do Room 3.0 przy jednoczesnym zachowaniu obsługi krytycznych zastosowań SupportSQLite.
Na przykład wywołania roomDatabase.openHelper.writableDatabase można zastąpić przez roomDatabase.getSupportWrapper(), a otoka będzie dostępna nawet wtedy, gdy w konstruktorze Room zostanie wywołana funkcja setDriver().
Więcej informacji znajdziesz w dokumentacji room-sqlite-wrapper.
Obsługa Room i SQLite w internecie
Obsługa Kotlin Multiplatform dla JS i WasmJS wprowadza niektóre z najważniejszych zmian w interfejsie API. W szczególności wiele interfejsów API w Room 3.0 to funkcje zawieszane, ponieważ prawidłowa obsługa pamięci masowej w internecie jest asynchroniczna. Interfejsy API SQLiteDriver zostały też zaktualizowane, aby obsługiwać internet, a nowy asynchroniczny sterownik internetowy jest dostępny w androidx.sqlite:sqlite-web. Jest to sterownik oparty na Web Worker, który umożliwia utrwalanie bazy danych w prywatnym systemie plików pochodzenia (OPFS).
Więcej informacji o tym, jak skonfigurować Room na potrzeby internetu, znajdziesz w informacjach o wersji Room 3.0.
Niestandardowe typy zwracane przez DAO
Room 3.0 umożliwia dodawanie niestandardowych integracji do Room 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, aż zespół Room doda obsługę. Dotychczasowe integracje są migrowane do korzystania z tej funkcji, dlatego osoby, które z niej korzystają, będą musiały dodać konwertery do definicji @Database lub @Dao.
Na przykład konwerter Paging będzie znajdować się w artefakcie androidx.room3:room3-paging i będzie się nazywać PagingSourceDaoReturnTypeConverter. W przypadku LiveData konwerter znajduje się w androidx.room3:room3-livedata i nazywa się LiveDataDaoReturnTypeConverter.
Więcej informacji znajdziesz w sekcji Konwertery typów zwracanych przez DAO w informacjach o wersji Room 3.0.
Tryb konserwacji Room 2.x
Ponieważ prace nad Room będą się koncentrować na Room 3, obecna wersja Room 2.x przechodzi w tryb konserwacji. Oznacza to, że nie będziemy rozwijać żadnych ważnych funkcji, ale nadal będziemy publikować poprawki (2.8.1, 2.8.2 itp.) z poprawkami błędów i aktualizacjami zależności. Zespół będzie kontynuować te prace do czasu, aż Room 3 stanie się stabilna.
Uwagi końcowe
Jesteśmy bardzo podekscytowani potencjałem Room 3.0 i możliwościami, jakie otwiera ona dla ekosystemu Kotlin. Bądź na bieżąco z kolejnymi aktualizacjami!
-
Nowości o produktachW marcu wprowadziliśmy Android Bench – naszą tabelę wyników LLM dla rzeczywistych zadań związanych z tworzeniem aplikacji na Androida. Od tego czasu ulepszyliśmy test porównawczy na podstawie Waszych opinii, m.in. dodając ocenę modeli o otwartej wadze oraz wymiary kosztów i wydajności do tabeli wyników.
Zoe Lopez-Latorre • 3 minuty czytania -
Nowości o produktachW Google Play dokładamy wszelkich starań, aby zapewnić użytkownikom jak najlepsze wrażenia, a deweloperom – narzędzia i elastyczność, które pozwolą im odnieść sukces.
Paul Feng • 3 minuty czytania -
Nowości o produktachW zeszłym roku wprowadziliśmy weryfikację deweloperów aplikacji na Androida, aby zwiększyć bezpieczeństwo ekosystemu i uniemożliwić złośliwym podmiotom ukrywanie się za anonimowością w celu publikowania szkodliwych aplikacji.
Matthew Forsythe • 2 minuty czytania
Otrzymuj co tydzień najnowsze informacje o tworzeniu aplikacji na Androida na swoją skrzynkę odbiorczą.
