Kapag bumubuo ng mga aplikasyon na humahawak ng malaking dami ng nakabalangkas na datos, napagtanto natin na hindi tayo laging maaaring umasa sa koneksyon sa internet. Dito lumalabas ang posibilidad ng i-save ang impormasyon nang lokalDahil dito, gumagana ang app kahit nasa airplane mode o sa mga lugar na mahina ang sakop. Ang pinakakaraniwang senaryo ay ang paglikha ng caching system upang maipagpatuloy ng user ang pag-browse sa kanilang nilalaman nang walang pagkaantala.
Para makamit ito nang hindi nababalot ng code, iniaalok ng Google ang Room library. Sa madaling salita, ito ay isang layer ng abstraksyon sa ibabaw ng SQLite Inaalis nito ang marumi at paulit-ulit na gawain sa ating mga balikat, na nagbibigay-daan sa atin na gamitin ang buong kapangyarihan ng isang relational database sa mas moderno at ligtas na paraan. Kalimutan ang pagsusulat ng standard code na madaling magkamali; Tinitiyak ng Room na mas magkakasya ang lahat.
Bakit pipiliin ang Room kaysa sa tradisyonal na SQLite?
Ang paggamit ng mga native API ng SQLite ay maaaring maging isang tunay na sakit ng ulo dahil ito ay isang low-level na sistema. Isa sa mga pinakamalaking panganib ay ang mga SQL statement ay hindi sinusuri hangga't hindi tumatakbo ang app, na nangangahulugang Ang isang simpleng error sa pagta-type ay maaaring maging sanhi ng pagsasara ng application. hindi inaasahan. Nilulutas ito ng Room sa pamamagitan ng pagpapatupad ng isang Pag-verify ng query sa oras ng pag-compile, na nag-aalerto sa iyo kung may mali bago pa man ilunsad ang app sa device.
Bukod pa rito, ang Room ay maayos na nakakapag-integrate sa arkitektura ng Jetpack, na lubos na nagpapadali sa pagkakapare-pareho ng data sa lahat ng screen. Kapag ginagamit mga tala ng kaginhawahanMalaki ang nababawasan nito sa paulit-ulit na code (ang sikat na boilerplate), na ginagawang mas napapanatili at nasusukat ang proyekto sa pangmatagalan.
Mga mahahalagang bahagi ng arkitektura
Para gumana ang Silid, kailangan nating i-coordinate ang tatlong pangunahing elemento na gumagana bilang isang pangkat:
- Mga entidad: Ito ang mga klase ng Kotlin na kumakatawan sa mga talahanayan ng database. Ang bawat instance ng isang entity ay tumutugma sa isang hilera sa kaukulang talahanayan.
- Mga Bagay sa Pag-access ng Datos (Datos Access Objects o DAOs): Ito ang mga interface kung saan tinutukoy natin ang mga pamamaraan para sa pag-query, paglalagay, pagbura, o pag-update ng impormasyon. Ito ang tulay sa pagitan ng lohika ng app at ng data.
- Klase ng Database (RoomDatabase): Ito ang pangunahing access point at ang abstract class na nagpapanatili ng koneksyon at tumutukoy kung aling mga entity ang bahagi ng system.
Teknikal na konpigurasyon at mga dependency
Para simulan ang pagnenegosyo sa Room, kailangan muna nating ihanda ang file build.gradleMahalagang idagdag ang mga dependency ng oras ng pagpapatakbo at ang tagatalaKung gumagamit ka ng Kotlin, dapat mong gamitin ang kapt o ksp Para sa pagproseso ng anotasyon; tandaan na huwag isama ang pareho upang maiwasan ang mga conflict. Lubos ding inirerekomenda ang pagdaragdag ng extension. room-ktxna siyang nagpapahintulot sa paggamit mga tungkulin ng suspensyon at mga coroutinepinipigilan ang pagyeyelo ng user interface kapag nagsasagawa ng mabibigat na operasyon.
Hakbang-hakbang na pagpapatupad ng data layer
Una nating tukuyin ang EntityGinagamit namin ang anotasyon @Entity para sabihin sa Room na ang klaseng ito ay isang table. Sa loob, dapat nating markahan ang isang field gamit ang @PrimaryKey para gawing kakaiba ang bawat record; kung gusto nating awtomatikong italaga ng database ang ID, ginagamit natin autoGenerate = true. Magagamit din natin @ColumnInfo kung gusto nating magkaroon ng ibang pangalan ang column sa SQLite kaysa sa variable sa Kotlin.
Pagkatapos ay magpapatuloy tayo sa DAODito tayo lilikha ng isang annotated interface na may @DaoPara sa mga simpleng operasyon tulad ng pagsingit o pagbura, gumagamit kami ng mga anotasyon. @Insert, @Update y @DeleteGayunpaman, para sa mga pasadyang paghahanap, ginagamit namin ang @Query, kung saan direkta nating isinusulat ang SQL statement. Isang napaka-kapaki-pakinabang na trick ay kaya nating ibalik ang LiveData o DaloyNagbibigay-daan ito sa interface na i-update ang sarili nito sa sandaling magbago ang data sa talahanayan.
Panghuli, na-configure namin ang RoomDatabaseAng klaseng ito ay dapat na abstrak at umaabot mula sa RoomDatabaseAng sumusunod na anotasyon ay idinagdag: @Database na nagpapahiwatig ng lahat ng entity na nilalaman nito at ang bersyon ng database. Upang maiwasan ang pagbubukas ng maraming instance ng database nang sabay-sabay, ang mainam na solusyon ay ipatupad ang Patern na singleton sa pamamagitan ng a companion object na may pamamaraan getInstance.
Pagsasama sa arkitektura at mga repositoryo ng MVVM
Para magmukhang propesyonal ang app, hindi natin dapat direktang tawagin ang database mula sa view. Sa isip, dapat tayong gumamit ng... Pag-iimbakAng repository ay gumaganap bilang tagapamagitan na nagpapasya kung ang data ay kukunin mula sa network o sa lokal na cache. Halimbawa, maaari nating i-program ang app na unang subukang kumuha ng data mula sa DAO at, kung ang listahan ay walang laman at mayroong koneksyon, gawin ang kahilingan sa server sa pamamagitan ng isang REST API.
Ang daloy na ito ay nagtatapos sa ViewModelna siyang responsable sa paglalantad ng datos sa fragment o aktibidad. Kapag ginagamit AndroidViewModelmayroon kaming access sa konteksto ng aplikasyon para maisagawa ang database. Sa ganitong paraan, nakakamit natin ang paghihiwalay ng mga responsibilidad kung saan ang view ay nagmamasid lamang sa katayuan ng datos at wala itong pakialam kung saan sila nanggaling o kung paano sila iniimbak.
Iba pang mga tampok at pag-optimize
Binibigyang-daan ka ng Room na pangasiwaan ang mga kumplikadong ugnayan sa pagitan ng mga talahanayan gamit ang mga dayuhang susi at ang kakayahang mag-embed ng mga entidad sa loob ng iba gamit ang @EmbeddedKung sakaling kailanganin nating baguhin ang istruktura ng talahanayan (halimbawa, magdagdag ng kolum), iaalok sa atin ng Room mga na-optimize na ruta ng migrasyon para hindi mawala ng user ang kanilang data kapag ina-update ang application.
Para sa mga naghahangad na dalhin ang pagtitiyaga sa susunod na antas, may mga experimental tool na nagbibigay-daan sa iyong bumuo ng mga HTTP endpoint batay sa mga Room DAO, na nagpapadali sa tuluy-tuloy na komunikasyon sa pagitan ng isang Kotlin server at isang Android app sa ilalim ng pilosopiyang... offline munatinitiyak na ang karanasan ng gumagamit ay palaging maayos anuman ang kanilang koneksyon.
Binabago ng pagpapatupad ng Room ang pamamahala ng datos sa Android, inaalis ang kahinaan ng SQLite at nagbibigay ng matatag na daloy ng trabaho batay sa mga bahagi ng Jetpack. Sa pamamagitan ng pagsasama-sama ng malinaw na mga entity, mahusay na mga DAO, at isang sentralisadong database gamit ang Singleton pattern, nakakamit namin ang mas mabilis na mga aplikasyon na maaaring gumana nang offline at napakadaling panatilihin salamat sa pagsuri ng error habang nagko-compile. Ibahagi ang impormasyong ito upang mas maraming tao ang matuto tungkol sa paksa.