Új hozzászólás Aktív témák

• thon73 tag

  #2129

  #2126 thon73

  2014-04-24 21:57:38

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  thon73

  tag

  #2126 thon73

  #2126 thon73

  Egy kis olvasás után jobban meg tudom fogalmazni a kérdésem:

  A BaseAdapter legnagyobb része UI szálon fut, tehát használhat a program többi részével közösen egy olyan ArrayList-et, amit a többi rész is csak UI szálon módosít.

  A BaseAdapter egyúttal Filterable is lett, vagyis tartalmaz egy Filter.performFiltering metódust, ami viszont egy Worker thread-en dolgozik, ÉS olvassa a fenti ArrayList adatokat.

  Én úgy látom, hogy csak a Filter.performFiltering területén kell védenem ezt a közös ArrayList-et a módosítástól.

  Mi lenne erre a leghatékonyabb módszer? ((Vehetünk két helyzetet is: kis méretű és extra nagy méretű listák, ahol a filtering is sokáig tarthat))
  Vagy valamit teljesen rosszul értek?

  Természetesen az osztálynevek a felmenőket jelentik, mindegyikből van saját.

  No, úgy tűnik, sikeresen beletenyereltem valamibe, ami messze meghaladja a tudományom. Ami megnyugtat: nem csak az enyémet. Tanulás céljából ajánlom a következő cikket: [link]; szerencse h. az említett professzor volt olyan kedves, és a pórnépnak is csinált biztonságos osztályokat...

  Kibogoztam az ArrayAdapter source-kódját is. A konstruktorban megadhatjuk a felhasználni kívánt ArrayList-et, melyet = jellel tárol a belső változóban.

  Ezt követően a Filter() rész pont azt csinálja, amit én: lock-olja a belső változó hozzáférését, és végigolvassa a tömböt (pontosabban átmásolja egy másikba). Ez azonban NEM szinkronizált cselekedet, uis. időközben egy másik programrész (akár UI szálon,mert a Filter worker-szálon van!) módosíthatja az eredeti tömböt. Vagy összeomlik, vagy exception-t kapunk. A saját változatomban (belassítottam a filtert) sikerült is a hibát produkálni.

  Ált. persze nem lesz hiba, egyszerűen azért, mert a Filter (ha egyáltalán használjuk), sokkal gyorsabban lefut, semmint változna közben a tömb. De ha a Filter lassul - akkor máris előjöhet a hiba, még a legegyszerűbb listában is. Az én problémám nyilván szélsőséges (túl nagy a lista), és valójában a filtert nem is akartam használni (pont a lassúsága miatt), de a logikai hiba az akkor is logikai hiba.

  Elvi megoldást úgy találtam a magam számára, hogy készítek egy ArrayList leszármazottat, amit a Loader fel tud tölteni, távolról változtatható - de csak akkor, ha a Filter nem állítja le a működését. Pl. úgy, hogy a filter teljesen más metódussal vesz ki elemeket; ha a tömb változik, akkor ez a lehetőség lezárul, úgyis megváltozott a szűrni kívánt anyag.

  Gondoltam, megosztom a gondolataimat, hátha mást is érdekel ez a kérdés. De, mint fent írtam, ez kicsit több, mint amit biztonságosan átlátok, így aztán ha hülyeséget gondolk, kérlek, javítsatok!

Új hozzászólás Aktív témák