Udostępniliśmy pierwszą wersję alfa Room 3.0. Room 3.0 to ważna wersja biblioteki, która koncentruje się na Kotlin Multiplatform (KMP) i dodaje obsługę JavaScriptu i WebAssembly (WASM) do dotychczasowej obsługi Androida, iOS i JVM na komputerach.
W tym poście na blogu omawiamy zmiany powodujące niezgodność, uzasadnienie wprowadzenia Room 3.0 i różne sposoby migracji z Room 2.0.
Zmiany powodujące niezgodność
Room 3.0 zawiera te zmiany interfejsu API powodujące niezgodność:
- Wycofanie interfejsów API SupportSQLite: Room 3.0 jest w pełni obsługiwany przez interfejsy API sterowników androidx.sqlite. Interfejsy SQLiteDriver API są zgodne z KMP, a usunięcie zależności Room od interfejsu API Androida upraszcza interfejs API na Androidzie, ponieważ pozwala uniknąć 2 możliwych backendów.
- Koniec z generowaniem kodu w języku Java: Room 3.0 generuje wyłącznie kod w języku Kotlin. Jest to zgodne z ewoluującym paradygmatem Kotlin-first, ale też upraszcza bazę kodu i proces programowania, co umożliwia szybsze iteracje.
- Skupienie się na KSP: wycofujemy też obsługę procesora adnotacji (AP) Javy i KAPT. Room 3.0 to wyłącznie procesor KSP (Kotlin Symbol Processing), który umożliwia lepsze przetwarzanie baz kodu Kotlin bez ograniczeń związanych z językiem Java.
- Współprogramy na pierwszym miejscu: Room 3.0 obsługuje współprogramy Kotlin, dzięki czemu interfejsy API są dostosowane do współprogramów. Koprocedury to zgodna z KMP platforma asynchroniczna, a zapewnienie asynchroniczności Room jest kluczowym wymaganiem do obsługi platform internetowych.
Nowy pakiet
Aby zapobiec problemom ze zgodnością z istniejącymi implementacjami Room 2.x i bibliotekami z zależnościami przechodnimi 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 to teraz 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ż Room 3.0 nie generuje już kodu w języku Java, wymaga również KSP i kompilatora Kotlin, nawet jeśli baza kodu, która współdziała z Room, jest w języku Java. Zalecamy utworzenie projektu wielomodułowego, w którym użycie Room jest skoncentrowane, a wtyczkę Kotlin Gradle i KSP można stosować bez wpływu na resztę bazy kodu.
Room 3.0 wymaga też współprogramów, a dokładniej funkcji DAO, które muszą być zawieszone, chyba że zwracają typ reaktywny, taki jak Flow. Room 3.0 nie zezwala na blokowanie funkcji DAO. Zapoznaj się z dokumentacją współprogramów na Androidzie, aby dowiedzieć się, jak zacząć integrować współprogramy z aplikacją.
Migracja do interfejsów API SQLiteDriver
W związku z rezygnacją z SupportSQLite aplikacje będą musiały przejść na interfejsy API SQLiteDriver. Ta migracja jest niezbędna do wykorzystania wszystkich zalet Room 3.0, w tym umożliwienia korzystania z dołączonej biblioteki SQLite za pomocą BundledSQLiteDriver. Możesz zacząć migrację do interfejsów API sterowników już dziś, korzystając z Room w wersji 2.7.0 lub nowszej. Zdecydowanie zalecamy unikanie dalszego korzystania z SupportSQLite. Jeśli przeniesiesz integracje Room do interfejsów API SQLiteDriver, przejście na Room 3.0 będzie łatwiejsze, ponieważ zmiana pakietu obejmuje głównie aktualizowanie odwołań do symboli (importów) i może wymagać minimalnych zmian w miejscach wywołania.
Krótkie omówienie interfejsów API SQLiteDriver znajdziesz w dokumentacji interfejsów API SQLiteDriver.
Więcej informacji o migracji Room na interfejsy API SQLiteDriver znajdziesz w oficjalnej dokumentacji dotyczącej migracji z SupportSQLite.
Kod SupportSQLite w Room
Zdajemy sobie sprawę, że całkowite usunięcie interfejsu SupportSQLite może nie być od razu możliwe we wszystkich projektach. Aby ułatwić to 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 udostępnia interfejs API zgodności, który umożliwia konwertowanie RoomDatabase na SupportSQLiteDatabase, nawet jeśli interfejsy API SupportSQLite w bazie danych zostały wyłączone z powodu zainstalowania SQLiteDriver. Zapewnia 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, a jednocześnie obsługiwać krytyczne zastosowania SupportSQLite.
Na przykład wywołania roomDatabase.openHelper.writableDatabase można zastąpić przez roomDatabase.getSupportWrapper(), a kod otaczający zostanie udostępniony, nawet jeśli w konstruktorze Room zostanie wywołana metoda setDriver().
Więcej informacji znajdziesz w dokumentacji room-sqlite-wrapper.
Obsługa Room i SQLite w przeglądarce
Obsługa platform Kotlin Multiplatform JS i WasmJS oraz niektóre z najważniejszych zmian w interfejsie API. Wiele interfejsów API w Room 3.0 to funkcje zawieszenia, ponieważ prawidłowa obsługa pamięci masowej w internecie jest asynchroniczna. Interfejsy API SQLiteDriver zostały też zaktualizowane, aby obsługiwać internet, a w pakiecie androidx.sqlite:sqlite-web jest dostępny nowy asynchroniczny sterownik internetowy. Jest to sterownik oparty na Web Worker, który umożliwia utrwalanie bazy danych w prywatnym systemie plików Origin (OPFS).
Więcej informacji o konfigurowaniu Room for the Web znajdziesz w informacjach o wersji Room 3.0.
Niestandardowe typy zwracane przez DAO
Room 3.0 wprowadza możliwość dodawania niestandardowych integracji do Room, podobnie jak RxJava i Paging. Dzięki nowemu interfejsowi API adnotacji o nazwie @DaoReturnTypeConverter możesz utworzyć własną integrację, aby wygenerowany kod Room był dostępny w czasie działania. Dzięki temu funkcje @Dao mogą mieć niestandardowe zwracane typy bez konieczności czekania, aż zespół Room doda obsługę. Istniejące integracje zostały przeniesione, aby korzystać z tej funkcji, więc osoby, które z niej korzystają, będą teraz musiały dodać konwertery do definicji @Database lub @Dao.
Na przykład konwerter stronicowania będzie znajdować się w artefakcie androidx.room3:room3-paging i będzie nosić nazwę PagingSourceDaoReturnTypeConverter. W przypadku LiveData konwerter znajduje się w androidx.room3:room3-livedata i nazywa się LiveDataDaoReturnTypeConverter.
Więcej informacji znajdziesz w sekcji Konwertery zwracanych typów DAO w informacjach o wersji Room 3.0.
Tryb konserwacji Room 2.x
Ponieważ rozwój Room będzie się koncentrować na Room 3, obecna wersja Room 2.x przechodzi w tryb konserwacji. Oznacza to, że nie będą rozwijane żadne ważne funkcje, ale nadal będą pojawiać się wersje poprawek (2.8.1, 2.8.2 itd.) z poprawkami błędów i aktualizacjami zależności. Zespół będzie pracować nad tym, dopóki pokój 3 nie będzie stabilny.
Uwagi końcowe
Jesteśmy bardzo podekscytowani potencjałem Room 3.0 i możliwościami, jakie otwiera on dla ekosystemu Kotlin. Będziemy na bieżąco informować o postępach.
-
Wiadomości o usłudzeW erze inteligentnych technologii użytkownicy nie tylko klikają aplikacje, ale też wyrażają ogólne cele i oczekują, że agenty AI, takie jak Gemini, będą wykonywać wieloetapowe zadania, czasem w kilku aplikacjach na urządzeniach.
Jingyu Shi • Czas czytania: 4 min -
Wiadomości o usłudzeDzisiaj, podczas Android Dev Summit, ogłaszamy szeroką dostępność wielu narzędzi i interfejsów API, które mają na celu usunięcie codziennych problemów i zapewnienie większej elastyczności podczas tworzenia świetnych aplikacji na Androida.
Matthew McCullough • Czas czytania: 4 min -
Wiadomości o usłudzeAndroid Studio Rabbit 2 jest teraz stabilny i gotowy do użycia w środowisku produkcyjnym. Ta wersja zawiera kluczowe funkcje, które ułatwią Ci programowanie, takie jak Bring Your Own Agent, nowe funkcje emulatora XR, aktualizacja LeakCanary, nowe narzędzie do zarządzania umiejętnościami agenta, inspekcja kodu przez AI i inne.
Matthew Warner • Czas czytania: 3 min
Otrzymuj co tydzień najnowsze informacje o tworzeniu aplikacji na Androida na swoją skrzynkę odbiorczą.
