Android's callback APIs are well sequenced and works as expected for most of the time. However, i ran into this problem where in a ListView's onItemClick() was invoked after the fragment's view was destroyed. Some search suggested that this could be because of the delay in processing Fragment Transactions, especially as they are posted to the main thread and executed in the next available slot and not immediately.
But after spending some time in Fragment transaction, it turns out that this was an issue with frameworks's AbsListView. Besides, this was seen only with a ListView in a Fragment and not with other AdapterViews or custom views. As and when the Fragment is being destroyed, all the views attached to the activity window has to be detached. AbsListView has a custom logic when it is detached from the parent window,
@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
...
...
...
if (mTouchModeReset != null) {
removeCallbacks(mTouchModeReset);
mTouchModeReset.run();
}
}
The runnable method of mTouchModeReset basically triggers a click event which in turn invokes the callback onItemClick on the registered interface.
mTouchModeReset = new Runnable() {
@Override
public void run() {
...
...
if (!mDataChanged && isAttachedToWindow()) {
performClick.run();
}
}
};
This is how onItemClick() could be invoked after a call to onDestroyView(). Fortunately, this was confirmed to be a platform bug and is fixed in new Android versions starting from 5.0.
commit 462c2177f73754458821cfc0441a863c1fa527e4
Author: Alan Viverette <alanv@google.com>
Date: Mon Feb 24 12:24:11 2014 -0800
Check for ongoing detachment in AbsListView
BUG: 13167767
Change-Id: Ie1a828eadbb99daef46af77544f233fee09fd1bc
But after spending some time in Fragment transaction, it turns out that this was an issue with frameworks's AbsListView. Besides, this was seen only with a ListView in a Fragment and not with other AdapterViews or custom views. As and when the Fragment is being destroyed, all the views attached to the activity window has to be detached. AbsListView has a custom logic when it is detached from the parent window,
@Override
protected void onDetachedFromWindow() {
super.onDetachedFromWindow();
...
...
...
if (mTouchModeReset != null) {
removeCallbacks(mTouchModeReset);
mTouchModeReset.run();
}
}
The runnable method of mTouchModeReset basically triggers a click event which in turn invokes the callback onItemClick on the registered interface.
mTouchModeReset = new Runnable() {
@Override
public void run() {
...
...
if (!mDataChanged && isAttachedToWindow()) {
performClick.run();
}
}
};
This is how onItemClick() could be invoked after a call to onDestroyView(). Fortunately, this was confirmed to be a platform bug and is fixed in new Android versions starting from 5.0.
commit 462c2177f73754458821cfc0441a863c1fa527e4
Author: Alan Viverette <alanv@google.com>
Date: Mon Feb 24 12:24:11 2014 -0800
Check for ongoing detachment in AbsListView
BUG: 13167767
Change-Id: Ie1a828eadbb99daef46af77544f233fee09fd1bc
No comments:
Post a Comment