CursorAdapter e Filter

Creo un'altra discussione visto che l'argomento è un po' diverso da quello dell'altro giorno...

Ho una ListView popolata tramite un cursore che fa una select sul DB.
Utilizzo una mia classe che estende CursorAdapter, fin qui tutto normale.

Ora però vorrei poter filtrare i dati in base al valore di alcuni campi (es: "colonnaX=1"), sull'Adapter esiste un metodo getFilter che restituisce un oggetto di tipo Filter che ha un metodo filter(CharSequence) che dovrebbe servire a filtrare i risultati, ma come dovrebbe essere usato con un cursore??
Ho provato a fare una cosa del genere:
<br /> adapter.getFilter().filter("NomeColonna=1");<br /> adapter.notifyDataSetChanged();<br />
ma non ha funzionato, vedo sempre tutti i risultati... ho provato pure aggiungendo questo:
<br /> adapter.getCursor().requery();<br />
ma niente ancora.
In un'altra applicazione avevo una ListView popolata da un ArrayAdapter e ho dovuto estendere Filter e nel metodo performFiltering() scorrevo l'array e restituivo i dati che volevo, ma col cursore come si dovrebbe fare?

Quote:

---

Originariamente inviato da Orochi

In un'altra applicazione avevo una ListView popolata da un ArrayAdapter e ho dovuto estendere Filter e nel metodo performFiltering() scorrevo l'array e restituivo i dati che volevo, ma col cursore come si dovrebbe fare?

---

Hai trovato qualche esempio sui filter? Purtroppo google restituisce dozzine di pagine con gli intent filter :-[ e l'argomento è interessante.

Secondo me, comunque, una reimplementazione è comunque necessaria. Qual è il problema con i cursori? Sono una classe diversa dall'array, ma anche loro hanno i loro bei metodi per pastrugnarli, no?

Sì, l'avevo trovato qualche esempio, non ricordo dove, comunque ho il codice che ho scritto l'altra volta, avevo esteso le classi ArrayAdapter e Filter, e dentro l'adapter conservavo l'array con i dati completi e con quelli filtrati, nel Filter nel metodo performFiltering() non si fa altro che scorrere l'array e riempire l'array dei risultati da restituire nella struttura di ritorno (che in questo istante non ricordo di che tipo è). Se ti interessa dimmelo che lo posto.

Il mio dubbio sull'uso del cursore è evitare di fare "schifezze" poco ottimizzate scorrendo e riscorrendo il cursore per poi restituire non so neanche che cosa fuori.... un altro cursore?
Non so, magari l'unico modo è rifare la query da capo, ma mi sembra stupido e poco ottimizzato..
Purtroppo esempi con filter per CursorAdapter non li ho trovati :'(

Quote:

---

Originariamente inviato da Orochi

Se ti interessa dimmelo che lo posto.

---

Se non è supersegreto sarebbe una bella cosa, in questo forum dopotutto si imparano sempre cose nuove! :cool:

Quote:

---

Originariamente inviato da Orochi

Il mio dubbio sull'uso del cursore è evitare di fare "schifezze" poco ottimizzate scorrendo e riscorrendo il cursore per poi restituire non so neanche che cosa fuori.... un altro cursore?
Non so, magari l'unico modo è rifare la query da capo, ma mi sembra stupido e poco ottimizzato..
Purtroppo esempi con filter per CursorAdapter non li ho trovati :'(

---

Rifare la query potrebbe essere in realtà, il metodo più ottimizzato perché non c'è niente di più agile di un DB per cercare le robe. Ovviamente, da un punto di vista di programmazione potrebbe non essere il metodo più pulito (se si trattasse di una query da ripetere molte volte o in più punti, sicuramente) e sicuramente in una selezione java potresti mettere un'intelligenza diversa, magari più facilmente che tramite SQL.
Per quello che riguarda il cursor... bhe, da quello che vedo alla fine la performFilter restituisce un FilterResult quindi puoi sentirti libero di recuperare il risultato nella forma migliore che credi, anche non un Cursore. Per quello che riguarda manipolare il cursore di partenza, invece, non credo che sia molto più sporco che maneggiare un array, anzi, dovrebbe avere metodi migliori...

Ho risolto!!!!!!!!

All'inizio ho trovato questo sistema che è praticamente uno di quelli usati quando si lavora con i content providers per fare tipo il filtro dei dati con l'autocompletamento, non è proprio quello che dovevo fare io, ma il risultato è lo stesso, filtrare i dati:
<br /> // questo metodo sta nel mio CustomAdapter che estende il CursorAdapter<br /> @Override<br /> public Cursor runQueryOnBackgroundThread(CharSequence constraint) {<br /> if(constraint == null) {<br /> return getCursor();<br /> }<br /> <br /> <br /> Cursor c = db.readMyList(constraint.toString());<br /> return c;<br /> }<br />
Qui db è la mia classe helper per il database. Successivamente nella onClick di qualche bottone dell'activity faccio questo:
<br /> adapter.getFilter().filter(myFilter); //myFilter è una stringa<br /> adapter.notifyDataSetChanged();<br />
In pratica la stringa myFilter viene passata come parametro constraint al metodo runQueryOnBackgroundThread che effettua di nuovo la query.
Il problema di questa soluzione è quello che dicevo prima, creo un nuovo cursore, incorporo nell'adapter persino la chiamata alla classe helper per fare ciò, ed è una schifezza immane! :p

Fortunatamente però spulciando tra i javadoc dell'SDK ho visto per caso che esisteva questo metodo:
<br /> public void setSelectionArguments (String[] selectionArgs) <br /> Changes the selection arguments. The new values take effect after a call to requery(). <br />
Problema: il metodo è presente solo nella classe SQLiteCursor... e quando si eseguono le query si ottiene una generica interfaccia Cursor che in realtà è una classe wrapper diversa da cui non è possibile ottenere/castare quell'oggetto lì!
Dopo un po' di sbattimenti e un errore visto nel LogCat riguardo un "Leak", in pratica non chiudevo bene i cursori roftl, sono andato a cercare cosa fare per chiudere questi benedetti cursori e ho scoperto che il metodo startManagingCursor dell'activity che pensavo lo facesse lei in realtà non lo fa, e da qui cercando la soluzione a questo problema ho trovato pure la soluzione all'altro!
Per assicurarsi di chiudere la connessione all'SQLiteDatabase, un tizio estendeva un po' di classi (compreso il cursore) per poter poi mantenere nel cursore il riferimento al db e chiamarci la close() nel metodo close() del cursore. La cosa interessante è che per fare ciò ha esteso la CursorFactory per farsi restituire il proprio cursore custom, ed ecco risolto il problema!
Un po' di codice vale più di 1000 parole ;)
<br /> // classe del cursore che estende l'SQLiteCursor che interessa a me e chiude pure i leak!<br /> public class CustomCursor extends SQLiteCursor {<br /> <br /> private final SQLiteDatabase db;<br /> <br /> public CustomCursor(SQLiteDatabase db, SQLiteCursorDriver driver, String editTable, SQLiteQuery query) {<br /> super(db, driver, editTable, query);<br /> this.db = db;<br /> }<br /> <br /> @Override<br /> public void close() {<br /> super.close();<br /> if(db != null) {<br /> db.close();<br /> }<br /> }<br /> }<br /> <br /> // la CursorFactory che istanzia il CustomCursor<br /> public class CustomCursorFactory implements CursorFactory {<br /> <br /> public Cursor newCursor(SQLiteDatabase db, SQLiteCursorDriver masterQuery, String editTable, SQLiteQuery query) {<br /> return new CustomCursor(db, masterQuery, editTable, query);<br /> }<br /> <br /> }<br /> <br /> // la classe helper per il DB, che usa la CustomCursorFactory nel costruttore!<br /> // prima lì ci passavo null...<br /> public class DatabaseManager extends SQLiteOpenHelper {<br /> <br /> private static final String DB_NAME = "nome_db";<br /> private static final int DB_VER = 1;<br /> <br /> private final Context context;<br /> <br /> public DatabaseManager(Context context) {<br /> super(context, DB_NAME, new CustomCursorFactory(), DB_VER);<br /> this.context = context;<br /> }<br /> <br /> // ...ometto una caterva di metodi banali...<br /> <br /> // ... ne lascio giusto 1 di esempio<br /> public Cursor readList(String selectionArg) {<br /> try {<br /> String select = null;<br /> String[] args = null;<br /> if(selectionArg != null) {<br /> select = "NomeColonna=?";<br /> args = new String[] {<br /> selectionArg<br /> };<br /> }<br /> <br /> SQLiteDatabase db = getReadableDatabase();<br /> Cursor c = db.query("NomeTabella", null, select, args, null, null, null);<br /> return c;<br /> } catch(Exception ex) {<br /> Log.e("PROJECT-B", "readList Failed!", ex);<br /> }<br /> return null;<br /> }<br /> }<br /> <br /> // infine nell'activity, nel solito onClick, adesso invece uso questo:<br /> ((CustomCursor)adapter.getCursor()).setSelectionArguments(new String[] {<br /> newArgs<br /> });<br /> ((CustomCursor)adapter.getCursor()).requery();<br />

Quindi tutto questo casino non fa altro che cambiare il parametro args che ho passato prima alla query dal mio metodo readList(String selectionArg) rieseguendo la stessa query roftlroftl
Alla fine la query credo la faccia lo stesso, ma non rialloca niente, riutilizza al massimo l'adapter, il cursore, la connessione al db, ecc... e credo che sia anche il sistema "giusto" da seguire in questo caso!
E' stata una faticaccia, ma che soddisfazione :D
Alla faccia dei tutorial online!

Spero che sia utile a qualcun'altro tutto questo popo' di codice ;)