- Ročno obdelavo SQLite nadomešča z abstrakcijsko plastjo, ki preverja poizvedbe med prevajanjem.
- Strukturiran je s tremi bistvenimi komponentami: entitetami za tabele, DAO-ji za operacije in razredom Database za povezavo.
- Omogoča upravljanje kompleksnih odnosov in migracij shem, da se prepreči izguba podatkov pri posodabljanju aplikacije.
- Brezhibno se integrira v arhitekturo MVVM z uporabo repozitorijev, ViewModel in asinhronih tokov, kot je Flow.
Ko oblikujete aplikacijo, ki obravnava precejšnjo količino organiziranih podatkov, se zavedate, da je nenehno zanašanje na internetno povezavo tvegano. Najboljši način, da preprečite, da bi se vaša aplikacija nehala odzivati, ko uporabnik vstopi v predor ali mu zmanjka podatkov, je implementacija lokalnega sistema za shranjevanje . Tukaj pride prav Room, orodje, ki nam omogoča shranjevanje informacij v napravi, tako da je uporabniška izkušnja brezhibna in na voljo kadar koli.
V bistvu Room deluje kot inteligenten most čez SQLite. Čeprav je SQLite zelo zmogljiv, je lahko delo z njim neposredno težavno, saj morate SQL pisati ročno in ne veste, ali ste naredili napako, dokler se aplikacija med izvajanjem ne sesuje. Room to rešuje tako, da nam da abstrakcijsko plast , ki preverja poizvedbe med prevajanjem kode, kar nam prihrani veliko časa za odpravljanje napak in odpravi ponavljajočo se kodo, ki običajno dolgočasi vsakega programerja.

Temeljni stebri Rooma

Za nastavitev baze podatkov s to knjižnico morate razumeti tri ključne dele, ki delujejo skupaj. Najprej imamo podatkovne entitete , ki so preprosto razredi, ki določajo, kako bo tabela videti v bazi podatkov; vsak primerek tega razreda predstavlja vrstico v tabeli.
Nato so tu še objekti za dostop do podatkov (DAO) . Ti vmesniki so srce interakcije, saj tam definirate metode za vstavljanje, brisanje ali iskanje podatkov. Namesto da bi sredi poslovne logike pisali zapletene poizvedbe, preprosto pokličete metodo v DAO in končali ste. Nazadnje je tu še razred baze podatkov , ki je glavna dostopna točka in je odgovoren za upravljanje osnovne povezave.
Konfiguracija in zagon

Za začetek morate v datoteko build.gradle dodati pravilne odvisnosti. Glede na vašo različico lahko Room za obdelavo opomb zahteva KSP (Kotlin Symbol Processing) ali kapt. Bistveno je vključiti izvajalno knjižnico, prevajalnik in, če delate s Kotlinom, razširitev korutine (room-ktx), da preprečite, da bi operacije blokirale uporabniški vmesnik.
Oblikovanje entitet in tabel
Za pretvorbo razreda v tabelo uporabimo anotacijo @Entity. Ime lahko določi razred Room ali pa ga dodelite sami z lastnostjo tableName. Definiranje primarnega ključa z uporabo @PrimaryKey je obvezno ; tega je mogoče samodejno ustvariti, če ne želite ročno upravljati ID-jev. Če imate polja, ki jih ne želite shraniti v zbirko podatkov, na primer pomnilniško intenzivno sliko, jih lahko prezrete z uporabo @Ignore.
V primerih, ko morate shraniti kompleksne podatkovne tipe, ki jih SQLite privzeto ne razume (na primer datum), morate ustvariti pretvornike tipov . Z uporabo `@TypeConverter` naučite Room, kako pretvoriti ta kompleksen objekt v primitivni tip, kot je `Long`, in obratno, nato pa te pretvornike registrirate v glavnem razredu baze podatkov.
Obvladovanje DAO-jev in poizvedb
Čarovnija se dogaja v DAO. Na voljo imate priročne metode, kot so @Insert, @Update in @Delete . Za vstavljanje lahko definirate strategije za reševanje konfliktov, kot je REPLACE, tako da se podatki, ki že obstajajo, samodejno prepišejo. Za bolj specifične poizvedbe uporabljamo @Query , kjer zapišemo SQL. Prostor je odličen, ker če naredite napako v imenu stolpca v SQL-u, vas bo aplikacija opozorila, preden namestite aplikacijo.
Ker so operacije z bazami podatkov počasne, se nikoli ne smejo izvajati v glavni niti . Zato je najbolje, da funkcije za uporabo s Kotlin-ovimi korutinami označite kot `suspend` ali pa naj vrnejo opazovane tipe, kot sta `Flow` ali `LiveData` , kar omogoča vmesniku samodejno posodabljanje takoj, ko se podatki v tabeli spremenijo.
Upravljanje odnosov s podatki
V resničnem svetu so podatki povezani. Room se izogiba lenobnemu nalaganju, da prepreči zamrznitev uporabniškega vmesnika, zato uporabljamo vmesne razrede z `@Relation` . Za relacijo ena proti ena ali ena proti mnogo preprosto definirajte razred, ki vsebuje primarno entiteto in seznam povezanih entitet. Za relacijo mnogo proti mnogo boste morali ustvariti tabelo navzkrižnih referenc, ki povezuje ID-je obeh entitet.
Napredna administracija in migracije
Ko vaša aplikacija raste in morate v tabelo dodati stolpec, ne morete preprosto spremeniti razreda. Povečati morate različico baze podatkov in definirati objekt Migration. Če ne želite pisati migracijskega SQL-a, sodobne različice programa Room ponujajo @AutoMigration , ki namesto vas opravi težko delo vsakič, ko izvozite shemo.
Če selite starejšo aplikacijo, ki že uporablja čisti SQLite, postopek vključuje označevanje modelov, ustvarjanje DAO-jev in definiranje prazne poti selitve, saj se podatkovna struktura ne spremeni, ampak le način dostopa do nje. Za tiste, ki so bolj napredni, je možno tudi razširiti bazo podatkov iz obstoječe datoteke z uporabo `createFromAsset`.
Priporočena arhitektura: Repozitorij in ViewModel

Da bi se izognili kaosu v kodi, je najbolje slediti arhitekturi MVVM. Repozitorij deluje kot posrednik; odloča, ali se podatki pridobivajo iz omrežja ali berejo iz lokalnega predpomnilnika sobe. ViewModel pa je odgovoren za prikaz teh podatkov pogledu. Z implementacijo baze podatkov kot Singleton zagotovimo, da ni hkrati odprtih več instanc, kar bi porabilo preveč virov naprave.
Implementacija Room preoblikuje robustnost aplikacije za Android in omogoča varno, učinkovito in enostavno vzdrževanje shranjevanja podatkov. Z integracijo dobro definiranih entitet, optimiziranih DAO-jev in arhitekture, ki temelji na repozitoriju, dosežete aplikacijo, ki je sposobna delovanja brez povezave in ima vrhunsko hitrost odzivanja, s čimer odpravite ročna tveganja SQLite in izkoristite preverjanje med prevajanjem.