ActionBarSherlock
ActionBarSherlock copied to clipboard
JakeWharton
Inconsistencies vs. Native Regarding Invalidation
There's some disconnect between ABS and the native action bar when creating and invalidating menus in a manner consistent with a ViewPager's operation.
The following example will exhibit all the problems (assets can be found in the guages for android repo)
public class ABSBuggggssActivity extends SherlockFragmentActivity {
boolean mShow = true;
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Button b = new Button(this);
b.setOnClickListener(new OnClickListener() {
public void onClick(View v) {
mShow = !mShow;
invalidateOptionsMenu();
}
});
setContentView(b);
}
public boolean onCreateOptionsMenu(Menu menu) {
if (mShow) {
menu.add("Refresh").setIcon(R.drawable.ic_action_refresh).setShowAsAction(MenuItem.SHOW_AS_ACTION_IF_ROOM);
}
return true;
}
public boolean onMenuItemSelected(int featureId, MenuItem item) {
ImageView iv = (ImageView) LayoutInflater.from(this).inflate(R.layout.refresh_action_view, null);
Animation r = AnimationUtils.loadAnimation(this, R.anim.clockwise_refresh);
r.setRepeatCount(Animation.INFINITE);
iv.startAnimation(r);
item.setActionView(iv);
return true;
}
}
On ICS you'll get the rendering issue when clicking the action item, and then toggling the action item visibility with the content button.
If you change to use a native Activity (and correct the menu imports) you'll observe the bug does not occur. If you return false when the menu doesn't exist (as you should) it will work with SherlockFragmentActivity but we still want to mimic native.
Use pre-Honeycomb always exhibits the rendering problem no matter what you return. This is likely due to FragmentActivity's handling of menus since it thinks we want to use it rather than our own implementation.
I've recently bumped into this issue as well. I've got an activity which contains a fragment viewpager. When swiping between the fragments in the viewpager the actionbar items goes wierd and non-clickable, just like in this issue.
Want me to create a small project using a viewpager which causes this too?
What version are you using? There was a touch-related bug with RC1 that is no longer present in the latest from 4.0-wip.
This issue doesn't deal with non-clickable action items but only the double-rendering effect. If your behavior is different please make an example project as you said and post a .zip to the mailing list: http://abs.io/forum
Thanks!
@JakeWharton I've updated to bd157f8450616546bf74672af477307fd73728f8 and my issues with actionbar items being non-clickable seems to be resolved. Cannot recreate them, and they don't occur where they used to. Great!
I have to write this down lest I forget:
Idea: toggle a flag in SherlockFragmentActivity when calling up to FragmentActivity to signal that we will be dispatching the create event through the fragment manager. Read that flag in all of the SherlockFragment* classes and aggregate the results of unwrapping the mules and calling the sherlock fragment create method. Once back in SherlockFragmentActivity read the aggregated booleans as the true result of creation and reset the initial flag to false.
Made partial headway with fca84af8ee296d510cf6e85eb7c556717845f378 but I'm still getting behavior differences between native and compat. Still under investigation.
I'm running into this bug on pre-ICS devices. Is there a fix on the horizon? Or any known workaround?
I am getting this issue on pre-ICS devices as well. Here is a SO question I posted about it:
http://stackoverflow.com/questions/15181631/actionbar-icons-overlaying/15182432
and here
http://stackoverflow.com/questions/15178207/actionbar-retaining-menu-item-in-gingerbread-and-below
I ended up just checking the SDK version and not animating the menu item for pre-ICS devices. Not ideal, but not much I can do.
