1

So I have one activity with a listview in it that is dynamically updated via cursors. The cursor object is being reused by simply reassigning a query command to this variable, which returns a whole new set of data. This works fine. The issue is that I have extended SimpleCursorAdapter to work with an AlphaIndexer. Apparently when the cursor is updated or changed, its supposed to clear the indexed cache. This is not happening. The main reason for all of this is to have fast scroll working on different cursors that are passed in and have it work. Right now, in using different cursors, the listview is using indexes from the first listview with trying to fastscroll through the second listview.

class AlphaCursor extends SimpleCursorAdapter implements SectionIndexer {

    AlphabetIndexer alphaIndexer;
    private int list_type;
    public AlphaCursor(Context context, int layout, Cursor c, String[] from, int[] to, int type, String sortBy) {
        super(context, layout, c, from, to);
        // MUST have space in front of alphabet
        int count = c.getCount();
        // this.onContentChanged();doesnt do a thing
        alphaIndexer = new AlphabetIndexer(c, c.getColumnIndex(sortBy), " ABCDEFGHIJKLMNOPQRSTUVWXYZ");
        list_type = type;

Any idea what might be going on or how to clear this cache? I tried onChanged() as well as onContentChanged(). Has anyone seen this or know any suggestions?

The code is being used like such:

    alpha = new AlphaCursor(ClassActivity.this, R.layout.list_item, m_cursor, from, to, TAB_HOME, "name");
    alpha.changeCursor(m_cursor);
mList.setAdapter(alpha);

Keep in mind, I have 4 'tabs' that just requery a cursor and create a new AlphaIndexer. Each time a tab is clicked, the alpha variable is nulled out. It looks like there is view cahcing with the indexer.

Thanks

Du3
  • 1,424
  • 6
  • 18
  • 36
  • Could you please show a piece of code where the cursor is being reused? – Michael Aug 31 '11 at 20:32
  • mind ClassActivity.this passes the activity reference. You should use getApplicationContext(). – weakwire Sep 06 '11 at 15:12
  • I agree. I have made this change with no luck. I am beginning to think its bad architecture and each tab must have it's own cursor. This will take care of the view cache, but will force me to have 4 cursors rather than just one. – Du3 Sep 10 '11 at 09:43
  • I am doing something similiar HERE http://stackoverflow.com/questions/10224233/alphabetindexer-with-custom-adapter-managed-by-loadermanager – Etienne Lawlor Apr 25 '12 at 06:17

3 Answers3

1

Since it seems that the AlphaIndexer becomes tied to the ScrollView when it's first used, it ignores any subsequent changes when a new one is set in the Adapter.

To get around the problem as described in the question, I made the AlphaIndexer a member of the ListFragment and created it once. On subsequent changes to the cursor used in the adapter, I just called alphaIndexer.setCursor(aCursor). This fixed the 'stale' index problem and also the 'offset' alphabet when trying to use setFastScrollEnabled() with false/true.

I assume that this will also work with a ListActivity.

SoftWyer
  • 1,986
  • 28
  • 33
0

Try calling alphaIndexer.setCursor(cursor);

after this

alphaIndexer = new AlphabetIndexer(c, c.getColumnIndex(sortBy), " ABCDEFGHIJKLMNOPQRSTUVWXYZ");

The method setCursor sets a new cursor as the data set and resets the cache of indices.

rogcg
  • 10,451
  • 20
  • 91
  • 133
  • Thanks, but that didn't work either. It's weird because its also passing in the cursor into the constructor. Since it's a new object, you'd think it would be a new cache as well.... It's beyond annoying. – Du3 Jul 16 '11 at 10:34
  • 1
    I was having the same problem, and I solved it calling listview.setFastScrollEnabled(false) and listview.setFastScrollEnabled(true) in sequence after I set the adapter. – rogcg Jul 16 '11 at 18:41
  • 1
    It appears this actually works, however it messes with the position of the fastscroll alphabet. Now, what used to appear in the middle of the screen is absolutely positioned in the upper lefthand corner. Not really sure what can fix that one, as it sounds like it cleared part of the view-cache, but didn't rebuild some of it. – Du3 Jul 17 '11 at 10:59
  • Did you set it to false and to true, right after when you set the adapter?? – rogcg Jul 17 '11 at 22:18
  • Yes, sure did. It's got some weird caching storage method within ListAdapter. I am changing the cursor and setting a new listadapter on the same ListView object each time within the same Activity. Is this similar to what you are doing? I think I am going to have to create on ListAdapter object and toggle the cursor and custom to/from properties being set. – Du3 Jul 17 '11 at 22:23
  • What kind of adapter are you using? Are you calling setCursor(Cursor)? – rogcg Jul 17 '11 at 22:43
  • listing.setAdapter(new AlphaCursor(CalendarActivity.this, R.layout.day_item, m_cursor,from, to, TAB_DAY, "day")); It looks like that, but it has a different parameter everytime I create an adapter. I figured by creating a new adapter each time, it would have a new cache each time. That is not the case. I have tried setCursor in the AlphaCursor, but that doesn't work either. I really think I need one adapter for the entire activity. – Du3 Jul 17 '11 at 22:55
  • Well, I'm not in my computer right now. I'm gonna look at the code later and tell how I did. – rogcg Jul 18 '11 at 01:11
0

You should never have to change the adapter out from under the ListView. See what happens with you call swapCursor() instead of changeCursor().

num1
  • 4,825
  • 4
  • 31
  • 49
  • 1
    This is only for API 11. I need API 8. Also, it changeCursor is better since I want it to close the old cursor. Thanks for the ideas though – Du3 Sep 10 '11 at 08:38