Sigurado akong nangyari na ito sa iyo: magbubukas ka ng app na may libu-libong produkto o larawan, at habang nag-i-scroll ka, maayos ang daloy ng lahat, nang walang anumang pagkaantala o walang katapusang paglo-load ng mga screen. Hindi ito mahika, ito ang mahusay na naipatupad na paginationKapag gumagamit ng napakalaking dami ng data, ang pagsubok na i-load ang lahat nang sabay-sabay ay halos garantisadong magdudulot ng pag-crash ng app, na direktang hahantong sa kinatatakutang OutOfMemory (OOM) error, habang napupuno nito ang memorya. RAM ng aparato gamit ang mga bagay na hindi nakikita ng gumagamit.
Para malutas ang gusot na ito, binigyan tayo ng Google ng library Paging ng Jetpack 3Hindi lamang hinahati ng tool na ito ang impormasyon sa mga pahinang madaling pamahalaan, kundi dinisenyo rin ito mula sa simula upang gumana nang maayos sa Kotlin, coroutines, at Flow. Sa esensya, pinapayagan tayo nitong maghatid ng data sa tamang oras, na nag-o-optimize sa mga mapagkukunan ng system at ginagawang mas mahusay ang nabigasyon. lubos na likido at natural para sa sinumang gumagamit ng app.
Paano gumagana ang arkitektura ng Paging 3?
Upang maiwasan ang kaguluhan, ang Paging 3 ay nakaayos sa tatlong napakalinaw na antas na akmang-akma sa Malinis na ArkitekturaUna, mayroon tayong repository layer, kung saan ang pangunahing manlalaro ay ang PagingSourceAlam ng component na ito kung saan nanggagaling ang data, mula man ito sa isang Room database o isang RESTful API, at tinutukoy nito kung paano kinukuha ang bawat impormasyon.
Kung gusto nating mag-level up at gumawa ng app na gumagana offline, ang mga sumusunod ay mahalaga: RemoteMediatorAng taong ito ay gumaganap bilang isang konduktor ng orkestra na namamahala sa isang orkestra. pinagmumulan ng datos na may patong-patongNagda-download ito ng data mula sa network at iniimbak ito sa isang lokal na cache, tinitiyak na palaging nakakakita ang gumagamit ng isang bagay kahit na walang access sa internet.
Paglipat paakyat sa presentation layer, makikita natin ang PagerAng bahaging ito ang siyang lumilikha ng daloy ng PagingData batay sa isang partikular na configuration (PagingConfig), kung saan tayo ang nagpapasya kung ilang item ang ilo-load bawat pahina at kung gaano katagal bago magsimulang mag-load ang susunod na pahina (ang sikat na prefetch) upang hindi mapansin ng user ang transition.
Pagdadala ng datos sa user interface
Kapag nakarating na tayo sa UI, nagiging interesante ang mga bagay-bagay. Kung gagamitin mo Pagsulat ng JetpackAng star tool ay ang function collectAsLazyPagingItems()Kino-convert nito ang daloy ng data sa isang bagay na nagpapaliban ng mga bahagi ng disenyo, tulad ng LazyColumn o LazyRowMaaari silang ubusin nang hindi pinagpapawisan, kaya hindi na kailangang magsulat ng mga kumplikadong adapter o manu-manong lohika ng pagkakaiba-iba.
Para sa mga gumagamit pa rin ng tradisyonal na sistema ng pagtingin, ang PagingDataAdapter Ito ang solusyon. Ito ay isang espesyal na adaptor na nagmamana ng mga bentahe ng ListAdapter, gamit ang DiffUtil para i-update lamang ang mga item na nagbago at awtomatikong humiling ng mga bagong pahina kapag ginagamit ang RecyclerView sa Android kapag nag-i-scroll malapit sa dulo ng listahan.
Pamamahala ng estado at error
Isa sa mga pinakamalaking bentahe ng library na ito ay hindi ka nito iniiwan na naliligaw sa paghawak ng error. Inilalantad ng paging ang estado ng pagkarga sa tatlong kritikal na punto: ang unang load (refresh), ang up load (prepend), at ang down load (append). Ito ay nagbibigay-daan sa atin na ilagay mga tagapagpahiwatig ng pagkarga o mga buton ng muling pagsubok kung saan mismo kailangan ng gumagamit ang mga ito.
Kung gusto nating magmukhang propesyonal ang listahan, maaari tayong magdagdag ng LoadStateAdapterAng component na ito ay lumilikha ng dynamic footer na nagpapakita ng loading spinner habang mas maraming data ang kinukuha, o isang mensahe ng error na may button. "Subukan muli" Kung nabigo ang koneksyon, lahat ng ito ay magagawa nang hindi nakakasagabal sa pangunahing listahan ng data.
Mga estratehiya sa paging sa backend
Para gumana nang maayos ang frontend, kailangan ding maging maayos ang backend. Mayroong ilang mga paraan upang maihatid ang datos na ito. Ang pinakaklasiko ay ang offset at limitasyonkung saan hinihiling namin ang pahina 2 na may 10 aytem, ​​bagama't maaari itong maging mabagal sa napakalaking mga database. Sa kabilang banda, ang paging batay sa cursor Mas gusto ito ng mga higanteng kompanya tulad ng Twitter o Facebook; sa halip na numero ng pahina, gumagamit kami ng bookmark (tulad ng ID ng huling item) upang humiling ng mga susunod, na siyang garantiya na hindi nauulit ang datos kung may mga bagong tala na ipinasok habang tayo ay nagba-browse.
Mayroon ding variant batay sa mga timestampMainam para sa mga log o news feed, kung saan hinihiling natin ang lahat ng nilikha pagkatapos ng isang partikular na petsa at oras. Anuman ang pamamaraan, mahalagang ipatupad ito mga filter at pag-uuri sa API upang hindi na kailangang iproseso ng kliyente ang libu-libong talaan sa memorya, na itinatalaga ang load na iyon sa server.
Mga advanced na tip at pag-optimize
Kung lilipat ka mula sa Paging 2, mapapansin mo na mas simple na ang lahat ngayon dahil ang mga lumang klase ng DataSource ay pinag-isa na sa PagingSourceBukod pa rito, maaari na natin ngayong ipasok ang mga pasadyang divider sa pagitan ng mga elemento ng listahan, tulad ng paglalagay ng letra ng alpabeto bago ang isang grupo ng mga pangalan, gamit ang function na insertSeparators sa daloy ng datos.
Tungkol sa pagsubok, hindi mo kailangang ilunsad ang app sa bawat pagkakataon. Ang library pagsubok sa paging Nag-aalok ang TestPager ng kakayahang gayahin ang pag-scroll at beripikahin kung ang PagingSource ay nagbabalik ng mga tamang pahina at na ang mga navigation key (nextKey at prevKey) Mahusay ang mga ito sa pagkalkula, na tinitiyak na ang pangwakas na karanasan ay matatag. Ibahagi ang impormasyong ito upang mas maraming tao ang matuto tungkol sa paksang ito