There is an issue with View reuse about stickylistheaders

[androidmoney]

My tester confirmed that if I remove the caches from StickyListHeadersCursorAdapter, the problem goes away.

I don't really follow the use of the caches -- it appears that it's assumed that each cache will contain only one view at most? I

[androidmoney]

By limiting the cache to one item only, the problem also goes away:

public View getView(int position, View convertView, ViewGroup parent) {
    View v = super.getView(position,axtractHeaderAndListItemFromConvertView(convertView),parent);
    boolean useCache = (headerCache.size() <= 1) && (wrapperCache.size() <= 1) && (dividerCache.size() <= 1);
    if(position == 0 || getHeaderId(position)!=getHeaderId(position-1)){
        v = attachHeaderToListItem(getHeaderWithForPosition(position, useCache),v, useCache);
        v.setTag(true);
    }else{
        v = attachDividerToListItem(v, useCache);
        v.setTag(false);
    }
    headerCache.clear();
    wrapperCache.clear();
    dividerCache.clear();
    return v;
}

But there is a noticeable performance penalty with this. So I am not sure how the cache with multiple items is supposed to work, but looks like the various caches can get out of sync and the wrong view is used. Maybe having a single Object with the 3 views and caching those would be better???? I don't know.

[rciovati]

Can you build a sample project where the problem is visible?

[androidmoney]

Hi, no, as I mentioned, it doesn't happen on my Galaxy Nexus. But it's obvious by looking at the code that it relies on the order in which getView() is called for the various rows. Since the caches are just queues (FIFO), If called out of order, they can end up with more than one item which are not retrieved in the right order causing this problem. This doesn't seem to happen on my device, but it happens reproducibly did on my tester's device. My "fix", which is a huge hack, throws away the cache if any of them end up with more than one item. In effect, the cache just because a single variable.

[androidmoney]

Maybe changing the data structure from a queue to a stack might also help.

[emilsjolander]

I really don't see why this would happen. When you say it displays the wrong data, what do you mean?

[androidmoney]

It sometime displays data from the header that belongs to a different list item. I fixed it by the code above.

[emilsjolander]

so let's say you have an alphabetical list and the header is the first letter. This bug causes the header to be "B" when it should say "C" ?

[androidmoney]

Yes, exactly. Your caching code seems to assume a certain order of things happening, that, under some circumstances, don't.

[androidmoney]

The thing is, I could never duplicate this issue on my Galaxy Nexus, but one of my testers could repeatable duplicate it on his phone, which was not a Nexus device. I forgot what skin it used.

[emilsjolander]

yeah, the thing is that i am having a hard time understanding what would cause this. But i am looking into it ATM and will update

[androidmoney]

Yes, I never understood the real issue, either. But limiting the cache fixed it and it caused no noticeable performance issues.

[emilsjolander]

I have theory that this might have to do with issue #25 (fixed now, will push tomorrow probably) . Does that sound possible? Because i don't feel like pushing a work around when i don't know the underlying problem.

[androidmoney]

Not likely. It happens for the tester when there is a long list. He would scroll the header out and then back in and it would appear wrong. The data is not changed.

I asked him what phone and version of Android he is on. Waiting for an answer.

[emilsjolander]

ok great, will continue to investigate

[androidmoney]

He says it was a Samsung Galaxy S II with stock 2.3.6. So that's TouchWiz.

[emilsjolander]

I will continue checking this out but i don't have that model with that software version at my disposal.

[JakeWharton]

This should be closable since the behavior has changed significantly since the report.

[emilsjolander]

I was thinking the same thing. Never could see the bug anyways so hard to see if is gone. @androidmoney you can open a new issue if this persists with after recent changes