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łudzeOd pełnej immersji w domu po szybkie sprawdzanie informacji w podróży – tworzenie aplikacji na Androida XR pozwala dotrzeć do użytkowników w każdym momencie i w całym spektrum aplikacji przestrzennych. Podczas Android Dev Summit osiągnęliśmy ważny kamień milowy, wprowadzając na rynek XREAL AURA.
Amy Zeppenfeld, Vinny DaSilva • Czas czytania: 3 min -
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
Otrzymuj co tydzień najnowsze informacje o tworzeniu aplikacji na Androida na swoją skrzynkę odbiorczą.
