Kung nagtatrabaho ka sa mobile development, malamang napansin mo na ang mabilis na pag-unlad ng code organization. Malamang ay nabasa mo na ang terminong reaktibong arkitektura At, mas partikular, sa MVI pattern, na lumilikha ng maraming ingay sa mga komunidad ng Android dahil sa kakayahan nitong magdala ng kaayusan sa kaguluhan ng mga estado ng interface.
Minsan parang nabubuhay ka sa ilalim ng bato kapag nagpapahinga ka mula sa mga proyekto, at pagkatapos, pagbalik mo, lumilitaw ang mga konsepto na tila bagong pamantayan. Ang MVI (Model-View-Interpreter o Intent) ay hindi lamang isang uso, kundi isang tugon sa pangangailangan para sa iwasan ang mga hindi pagkakapare-pareho sa mga application kung saan ang screen ay palaging nagbabago ayon sa mga kilos ng gumagamit.
Ano nga ba ang arkitektura ng MVI?
Sa madaling salita, ang MVI ay isang disenyo na naglalayong gawing mas malinis at mas madaling mapanatili ang code. Sa ecosystem na ito, ang eksklusibong hinahawakan ang vista mula sa pagpo-project ng datos at pagkuha ng mga kilos ng gumagamit, habang pinoprotektahan ng modelo ang lohika ng negosyo at purong impormasyon.
Ang pangunahing bahagi ay ang interpreter, na gumaganap bilang utak na nagpoproseso ng mga intensyon ng gumagamit. Isinasalin nito ang mga aksyon at sinasabi sa modelo kung ano ang babaguhin upang ma-update ang view. Ang pangunahing bentahe dito ay ang pagpapatupad nito ng isang daloy ng datos na unidireksyonalNangangahulugan ito na ang impormasyon ay palaging naglalakbay sa parehong direksyon, na pumipigil sa code na maging isang mahirap intindihin at gusot na gulo.
Sa pamamagitan ng paghahati-hati ng sistema sa maliliit at magagamit muli na mga piraso, mas madali nating mababasa ang proyekto. Ito ay lalong kapaki-pakinabang kapag ginagamit ang mga istrukturang naka-nest na datos o napakakumplikado, gaya ng nangyayari kapag Paggamit ng RecyclerView sa Androidkung saan ang isang pagbabago sa isang lugar ay maaaring makasira sa isang bagay sa iba kung wala tayong mahigpit na kontrol.
Praktikal na pagpapatupad gamit ang Kotlin
Para maging simple ito, isipin natin ang isang simpleng counter. Sa Kotlin, tutukuyin natin ang isang hindi nababagong estado sa pamamagitan ng isang klase ng datos at ang mga posibleng aksyon ng gumagamit sa pamamagitan ng isang selyadong klase. Ang huli ay susi upang gawing mahuhulaan ang sistema at maiwasan ang mga aksyon na "multo".
Sa view layer (tulad ng MainActivity), hindi natin direktang minamanipula ang data. Nagsa-subscribe lang tayo sa state ng ViewModel gamit ang isang observer, at kapag nag-click ang user sa isang button, nagpapadala tayo ng action gamit ang method tulad ng sendAction()Natatanggap ng ViewModel ang signal na ito, binibigyang kahulugan ang intensyon at ina-update ang estado gamit ang function na copy(), sa gayon ay inaabisuhan ang view na mag-refresh.
MVI vs. MVVM: Ang walang hanggang debate
Normal lang na magtaka kung ang MVI ba ay nilalayong palitan ang MVVM. Ang totoo ay hindi sila magkaaway, kundi magkaibang kagamitan. Ang MVVM ang kasalukuyang pamantayan dahil sa suporta ng Jetpack ViewModel at LiveDataNamumukod-tangi ito dahil sa pagiging simple at sa maayos na learning curve nito na nagbibigay-daan sa iyong mabilis na ilunsad ang mga MVP.
Gayunpaman, maaaring mahirapan ang MVVM sa mga aplikasyong lubos na dinamiko. Minsan ay nagdudulot ng mga problema ang bidirectional na komunikasyon. ang mga estadong ito ay nagiging hindi pare-parehoMaaari itong humantong sa mga bug na mahirap subaybayan sa mahahabang porma o sabay-sabay na mga daloy ng trabaho. Dito nagniningning ang MVI, dahil ang pagkakaroon ng tanging pinagmumulan ng katotohananAng bawat estado ay maaaring kopyahin at mas madaling i-debug.
- MVVM: Mainam para sa mga simpleng proyekto, na may mabilis na pagpapatupad at malawak na opisyal na dokumentasyon.
- MVI: Perpekto para sa magagaling na interface, kumplikadong display, at mga proyekto kung saan kritikal ang kontrol sa estado.
Sa mga proyektong pinansyal o lubos na interaktibo, kung saan hindi mo kayang mag-isyu ng status error, ang paggamit ng Daloy ng Kotlin at Daloy ng Estado Kasama ang MVI, ito ang pinakaligtas na paraan upang magarantiya ang pangmatagalang katatagan.
Mga dapat isaalang-alang bago pumili ng pattern
Hindi lahat ay maganda sa MVI. Dapat nating malaman na mayroon itong mas matarik na kurba ng pagkatutoKung ang pangkat ay hindi mahusay sa reactive programming, ang pagsisimula ay maaaring nakakadismaya. Bukod pa rito, para sa napakaliit na mga aplikasyon, maaari itong maging masyadong masinsinan, na nagdaragdag ng mga layer ng code na hindi nagbibigay ng tunay na halaga sa negosyo.
Ang susi ay ang pagtatasa ng kasalimuotan ng proyekto at ang karanasan ng mga developer. Hindi ito makatuwiran. pagsamahin ang parehong mga diskarte sa parehong aplikasyon kung kinakailangan ito ng disenyo, sinasamantala ang pagiging simple ng MVVM sa mga static screen at ang lakas ng MVI sa mas kumplikadong mga seksyon.
Kung gusto mong sumubok, ang pinakamagandang lugar para magsimula ay sa dokumentasyon ng Jetpack at mag-eksperimento sa unti-unting paglipat mula sa LiveData patungong StateFlow. Ipatupad mahigpit na pagsubok sa yunit Papayagan ka nitong patunayan na ang daloy ng data ay kumikilos ayon sa inaasahan mo bago simulan ang produksyon.