Intr-un UITableView , in fiecare cell , trebuie sa aduc 5 poze care se gasesc la o adresa web ( rcaleImagineProdus in codul de mai jos ).
Pentru a nu fi nevoit sa astepti , folosesc performSelectorInBackground astfel :
Daca esti suficient de iute , sau ai o conexiune slaba , dupa ce faci scroll , in loc sa iti apara poza aferenta randului existent pe ecran (adica poza din pozitia numarRand*5+pozitieInCell ), pozele sunt afisate una dupa alta , in final afisind imaginea dorita .
Intrebarea este : cum ma sfatuiti sa “marchez” obiectul astfel incit sa nu mai apara succesiunea de imagini ? Orice alte sugestii sunt binevenite .
Io nu ma pricep la programarea in ObjectiveC, dar cum ar fi sa incarci in prealabil in locul respectiv o imagine locala - o imagine complet alba sau un checkerboard de ala si dupa aia sa incarci pozele deasupra.
inainte de a incarca imaginea , deasupra codului postat mai sus , pentru fiecare UiImageView setez image = nil .
cind ajung repede la randul n , se afisaza nil , imagen-3 , imagen-2 , imagen-1, image n
nu ai cum sa eviti reciclarea celulelor. pe baza asta e construit un TableView. ai putea sa faci un cache pe disk la imagini si sa le preiei de-acolo. ar fi o solutia viabila in opinia mea.
si apropo… felul in care asignezi imaginile aferente celulelor e “wrong on so many levels”.. pai tu trimiti pointer catre instanta celulei, cand tu stii ca celulele se refolosesc? practic tu intr-un tableView nu ai mai multe celule decat ai pe ecran din cauza ca se refolosesc. trebuie sa schimbi doar informatia din ele, pe care o iei din UITableViewDataSource delegate. datele alea se pasteaza in delegate, nu in interiorul celulei. hope I made myself clear! spor la codat!
prefer sa evit GCDu cat mai mult, pentru ca pot aparea probleme de sync intre threaduri si e mult mai dificil de debug-uit! in majoritatea cazurilor performSelectorInBackground isi face treaba! apropo, vezi ca-ti lipseste NSAutoreleasePool-ul din updateImageView!
Threading is dead .
GCD asigura sincronizarea , garanteaza ordinea operatiilor , pune cozile de asteptare in grupuri si ai multiple cozi care asteapta simultan , daca vrei , poti sti cind o coada este goala, etc .Eu sunt mai mult decit incintat .
Am citit toata noaptea . Eu zic sa te mai gindesti si ai sa vezi ca este mult mai bine , si chiar mai usor , sa folosesti GCD .
“The key innovation of GCD is shifting the responsibility for managing threads and their execution from applications to the operating system.
As a result, programmers can write less code to deal with concurrent operations in their applications, and the system can perform more efficiently on single-processor machines,
large multiprocessor servers, and everything in between. ”
“KISS is an acronym for the design principle articulated by Kelly Johnson, Keep it simple, Stupid!.[1] Variations include “keep it short and simple”, “keep it simple sir”, “keep it simple or be stupid”, “keep it simple and stupid”, “keep it simple and straightforward” or “keep it simple and sincere.”[2] The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.”
Stabileste tu care este mai usor de intretinut , de gandit , de scris , si care corespunde principiului KISS .
Poti sa iei in calcul si exemplul din link-ul postat .
Cred ca abordarea asta functioneaza pentru o lista relativ mica. Daca ai o lista de 100+ (sa zicem), si faci scroll usurel prin ea iar conexia nu este tocmai stralucita ai sa ai o gramada de download-uri inutile care nu vor face decat sa incetineasca si mai mult lucrurile. Daca-mi amintesc corect o abordare mai inteligenta era printr-un exemplu de la Apple unde se folosea NSOperationQueue, fiecare operatie avand un NSURLConnection (care bineinteles suporta cancel).
)
