Kung nahirapan ka nang ipaalam sa isang bahagi ng sistema kung ano ang nangyayari sa iba, malalaman mo na ang paglilipat ng data sa Android ay maaaring maging isang tunay na sakit ng ulo. Kapag mayroon kang isang application na may ilang magkakaugnay na screen, ang pag-synchronize ng impormasyon Mahalaga ito para hindi maramdaman ng user na sira ang app o nawawala ang data kapag inikot ang screen.
Ang pinakamatibay at modernong solusyon na mayroon kami ay ang Ibinahaging ViewModelSa madaling salita, ito ay isang imbakan ng datos na hindi nabibilang sa iisang fragment, kundi nakaangkla sa aktibidad na naglalaman ng lahat ng ito. Sa ganitong paraan, maaaring magbasa o magsulat ng impormasyon ang anumang screen nang hindi kinakailangang malaman ang tungkol sa iba, na pinapanatiling malinis ang code at pinipigilan ang pag-crash ng app dahil sa mga error. mga pagbabago sa pagsasaayos.
Ano nga ba ang isang shared ViewModel?
Sa madaling salita, ang ViewModel ay isang klase na idinisenyo upang mag-imbak at pamahalaan ang datos na may kaugnayan sa user interface. Kapag sinabi nating ito ay ibinahagiAng ibig naming sabihin sa "saklaw" ay ang saklaw nito ay ang host activity. Hangga't buhay ang activity, mananatili ang ViewModel, ibig sabihin kung ang user ay mag-navigate sa pagitan ng mga fragment, lahat sila ay titingin sa iisang "data box."
Ang arkitekturang ito ang hiyas sa korona dahil ganap na paghiwalayin ang mga pirasoHindi mo na kailangang gumawa ng mga kumplikadong interface o magpasa ng walang katapusang mga bundle bilang mga argumento. Iniimbak ng Fragment A ang data, pinapanatili ito ng ViewModel, at inoobserbahan at tinutugunan ito ng fragment B. Ito, sa madaling salita, ang pinakaepektibong paraan upang maiwasan tumagas ang memorya at mga pagkakamali ng siklo ng buhay ng isang aktibidad.
Hakbang-hakbang na pagpapatupad at mga pinakamahusay na kasanayan
Para maitayo ang sistemang ito, ang unang hakbang ay ang paglikha ng isang klase na magmamana mula sa ViewModelSa loob nito, ang mithiin ay hindi direktang ilantad ang mga baryabol. Ang ginintuang tuntunin ay ang paggamit MutableLiveData pribado (halimbawa, may underscore) _quantity) at ilantad ang isang read-only na bersyon sa pamamagitan ng LiveDataPinipigilan nito ang anumang panlabas na klase na baguhin ang data nang kusa at magdulot ng hindi pangkaraniwang pag-uugali.
Ang sikreto ng saklaw
Dito nagkakamali ang maraming tao. Kung gagamit ka ng delegasyon viewModels()Ang bawat fragment ay magkakaroon ng sarili nitong instance at walang magiging komunikasyon. Para maibahagi ito, dapat mong gamitin ang activityViewModels() o ipasa ang aktibidad sa tagabuo ng ViewModelProviderSa pamamagitan ng paggawa ng May-ari ng ViewModel Anuman ang aktibidad, tinitiyak mo na ang lahat ng mga fragment ay makakatanggap ng parehong instance.
Reaktibong pag-synchronize gamit ang LiveData at Data Binding
Ang tunay na mahika ay nangyayari kapag pinagsama natin ang ViewModel sa Pagbubuklod ng DataSa halip na magsulat ng paulit-ulit na code para i-update ang bawat TextView, maaari nating i-bind ang variable na ViewModel nang direkta sa XML. Para gumana ito, mahalagang italaga ang lifecycleOwner sa fragment; kung hindi, hindi malalaman ng interface na nagbago ang data at maiiwan kang nakatitig sa isang static na screen.
Mga Advanced na Teknik: Mga Transpormasyon at Resulta
Minsan ayaw nating ipakita ang hilaw na datos, kundi isang naka-format na bersyon. Para dito, may mga... Mga Pagbabago ng LiveDataHalimbawa, kung mayroon tayong presyo bilang isang decimal na numero, maaari nating gamitin ang Transformations.map() para awtomatikong i-convert ito sa isang text string na may lokal na simbolo ng pera. Pinapayagan nito ang lohika ng presentasyon manatili sa ViewModel at huwag kalat-kalat ang klase ng fragment.
Alternatibo: Ang Fragment Results API
Hindi natin laging kailangan ng ViewModel. Kung gusto lang nating magpasa ng iisang partikular na data (tulad ng resulta ng pag-scan ng QR code), ang API ng Resulta ng Fragment Ito ang pinakamagaan na opsyon. Ginagamit ng tool na ito ang FragmentManager tulad ng isang sentral na mailbox: itinatatag ng isang fragment ang resulta gamit ang isang partikular na key at pinakikinggan ito ng tumatanggap na fragment sa pamamagitan ng isang nakikinigIto ay mainam para sa mabilis at one-way na komunikasyon na hindi nangangailangan ng tiyaga.
Mga kaso ng paggamit at arkitektura sa totoong mundo
Isipin ang isang screen ng order ng cupcake. Sa unang hakbang, pipiliin mo ang dami, sa pangalawa ang lasa, at sa pangatlo ang petsa ng pagkuha. Salamat sa Shared ViewModel, maa-access ng summary screen ang lahat ng mga nakaraang desisyon nang hindi kinakailangang magpadala ng kahit ano nang tahasan ang mga naunang fragment. Maaari pa nga nating kalkulahin ang kabuuang presyo sa totoong oras Pagdaragdag ng mga surcharge kung pipiliin ng user na kunin ang order sa parehong araw.
Isa pang tipikal na senaryo ay ang master-detail view sa mga tablet. Kapag tinapik mo ang isang item sa isang listahan sa kaliwang fragment, nag-a-update ang ViewModel, at ang kanang fragment, na tumitingin sa parehong data na iyon, I-refresh ang detalyadong impormasyon Agad-agad. Nangyayari ang lahat ng ito nang hindi kinakailangang aktibong makialam ang aktibidad sa koordinasyon, nagsisilbi lamang itong lalagyan na nagpapanatili sa estado na buhay. Ibahagi ang gabay na ito at mas maraming user ang makakaalam tungkol sa paksang ito.