În înțelegerea principiului general de acțiune și a desemnării unui adaptor, acest răspuns vă poate ajuta.
Apoi, de ce starea casetelor de selectare se schimbă atunci când derulați.
Când creați un curent de articole adaptor nu creează întotdeauna aspectul său de la zero, pentru a accelera munca, el foloseste un aspect creat anterior pentru produse care nu sunt vizibile în prezent pe ecran, deoarece este identic pentru toate lista articole. În acest caz, în cazul în care forța nu umple datele curente în metoda elementelor adaptor getView (), este nevoie de ceea ce a fost părăsit ultima dată în forma în care a fost la ultima (re) utiliza. Din aceasta și există un efect atunci când un stat widgeturi la întâmplare „salt“. Din toate acestea, în special, faptul că nu „blocare“, bifați casetele nu va rezolva problema, pentru că doar vedeți pe ecran sunt elemente care au fost mai mari (mai mici) de pe listă, iar acum a dispărut în spatele marginea ecranului.
Soluția este simplă. Atunci când creați fiecare element, este obligatoriu să setați stările corespunzătoare poziției afișate în mod curent pe ecran. Pentru a face acest lucru, trebuie să salvați aceste stări separat. Deoarece lucrați cu clasa de model și ați alocat un câmp special pentru stocarea stării casetei, atunci ar trebui să fie utilizat. Când se schimbă starea casetei (făcând clic pe ea sau pe toate elementele), noua stare trebuie să fie scrisă în model. Pentru a face acest lucru, trebuie să monitorizați clicul prin orice clic pe ascultător și să efectuați toate manipulările în el.
În propriul cod, nu există nicio salvare a modificărilor de stare când faceți clic. Pentru a vă rezolva problema, deoarece nu aveți nevoie de un ascultător separat în caseta de selectare și modificarea de stat se efectuează făcând clic pe toate elementele, trebuie să implementați metoda de setare în adaptor. care va schimba modelul acestui adaptor, păstrând starea schimbată. Va trebui să apelați această metodă din Activare, când procesarea ascultătorului face clic pe lista OnItemClickListener ().
După cum este necesar să se prevadă revenirea stărilor modificate ale adaptorului (Metoda getter), atunci când toate marcajele necesare sunt făcute ca la ieșirea adaptorului activitã Combo și, respectiv, modelul, transmis va fi pierdut și marca va fi irosit.
Un exemplu de implementare ar putea arăta astfel:
Doar câteva comentarii:
Dacă lucrați cu o bază de date, atunci este mai bine să utilizați clase destinate să lucrați cu baze de date, de exemplu cursorul și moștenirea de la SimpleCursorAdapter (). care returnează înregistrările ID din baza de date sau utilizează un fel de ORM.
În special, acum aveți o astfel de situație pe care o scrieți în baza de date despre poziție. dar ID-ul în baza de date nu este egal cu valoarea poziției din adaptor, atunci când faceți / ștergeți date din baza de date, poziția și ID-ul vor fi diferite, deoarece ID-ul este întotdeauna asociat contului următor. Adică, prin ștergerea celei de-a treia înregistrări din baza de date (de la, să zicem, cinci) veți obține următoarea secvență de ID-uri în baza de date: 0,1,3,4,5, în timp ce pozițiile din listă vor fi: 4. Veți primi o eroare și veți scrie datele greșite.
De asemenea, este recomandat să faceți un clasar-wrapper pentru a lucra cu baza de date, care va implementa metodele de scriere, citire și operații TP CRUD, și nu va trimite cereri "crude", așa cum faceți acum.
Trimiteți-le prietenilor: