I recently came across a problem when using the excellent actionbarsherlock library (v4.1) – the action items would often only respond to a user click once the user done some other interaction with the UI. In this case, the Activity has a ViewPager with two Fragments so the user can swipe from one to the other. Each Fragment called setHasOptionsMenu(true) in onCreate, and implemented onPrepareOptionsMenu to create the Fragment-specific action items.
If the user clicked on one action item, the onOptionsItemSelected method should’ve been called immediately, but it wasn’t. It was as if all the clicks were queued up until swiping to the other fragment, at which point they’d be handled in a rush.
Turns out that I fell foul of two bugs – one in ABS: https://github.com/JakeWharton/ActionBarSherlock/issues/272 and one in Android itself: http://b.android.com/29472.
The first thing I tried was in the comments of the ABS issue – to modify ActionMenuView (part of ABS) so it inherits from LinearLayout instead of the custom IcsLinearLayout. This worked for 2.2+, but broke 2.1 devices – the action bar wouldn’t show at all until swiping.
Further reading of the comments in that issue led me to the Android bug, whereby handling onPrepareOptionsMenu in each Fragment causes a race condition (which in turn prevents the UI from responding to clicks).
The solution: implement onPrepareOptionsMenu (or onCreateOptionsMenu) in the containing Activity class, and use setHasOptionsMenu(false) in each Fragment (or don’t use it all).