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 opisujemy zmiany powodujące niezgodność, uzasadnienie wprowadzenia Room 3.0 oraz 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 API SQLiteDriver 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, umożliwiając szybsze iteracje.
- Skupienie się na KSP: wycofujemy też obsługę procesora adnotacji (AP) w języku Java 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 asynchroniczna platforma zgodna z KMP, 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 nowe 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
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 pełnego wykorzystania zalet Room 3.0, w tym do 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 do interfejsów API SQLiteDriver znajdziesz w oficjalnej dokumentacji dotyczącej migracji z SupportSQLite.
Kod Room SupportSQLite
Zdajemy sobie sprawę, że całkowite usunięcie 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 przy jednoczesnym zachowaniu obsługi krytycznego wykorzystania SupportSQLite.
Na przykład wywołania roomDatabase.openHelper.writableDatabase można zastąpić przez roomDatabase.getSupportWrapper(), a kod otaczający zostanie dostarczony, nawet jeśli setDriver() zostanie wywołany w konstruktorze Room.
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. W szczególności wiele interfejsów API w Room 3.0 to funkcje zawieszania, 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 do Room niestandardowych integracji podobnych do RxJava i Paging. Dzięki nowemu interfejsowi API adnotacji o nazwie @DaoReturnTypeConverter możesz utworzyć własną integrację, aby kod wygenerowany przez 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, dlatego teraz osoby, które z niej korzystają, muszą 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 koncentrować się 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 Room 3 nie stanie się 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łudzeAplikacje kierowane na nadchodzącą wersję Androida nie będą już mogły bezpośrednio zapisywać kontaktów za pomocą uprawnienia WRITE_CONTACTS.
Roxanna Aliabadi Walker • Czas czytania: 6 min -
Wiadomości o usłudzeW miarę jak rozwój agentów przyspiesza, inżynieria Androida osiąga nowy, ekscytujący etap: przechodzi od wspomagania uzupełniania kodu do agentów wykonujących zadania od początku do końca pod Twoim kierunkiem. Masz pełną swobodę i elastyczność w wyborze modeli i agentów, których używasz.
Jason Buchel • Czas czytania: 3 min -
Wiadomości o usłudzeDziś przedstawiliśmy, jak zamierzamy realizować naszą wizję „więcej niż sklep” w kolejnym rozdziale. Od karty Ty, która jest teraz osobistą bazą dla ponad 250 milionów aktywnych użytkowników miesięcznie, po ujednoliconą platformę do gier łączącą ponad 700 milionów profili graczy – Google Play jest zawsze tam, gdzie użytkownicy.
Paul Feng • Czas czytania: 3 min
Otrzymuj co tydzień najnowsze informacje o tworzeniu aplikacji na Androida na swoją skrzynkę odbiorczą.
