I filed a bug <http://code.google.com/p/android/issues/detail?id=19203> a few weeks ago which was reported to me by a user of my library and finally got around to finding a workaround yesterday (posted as a patch but I have a more refined implementation as of today). I'm hoping to get more opinions on the proper direction to take this in order to solve the problem.
*Problem:* When using fragments with a ViewPager two two fragments which are adjacent to the currently selected page are instantiated and cached to provide smooth scrolling in either direction with as little lag as possible. If these fragments contribute menus to the activity options menu then their items will appear when positioned in these adjacent positions. *My solution:* Currently I chose to solve this by adding two booleans to Fragment, mViewPagerParticipant and mViewPagerSelected. When FragmentPagerAdapterinstantiates or destroys a fragment it updates mViewPagerParticipant with the appropriate value. Through the addition of a non-abstract method in PagerAdapter, updateSelectionState(Object object, boolean selected), FragmentPagerAdapter will set the fragment (cast from the object) mViewPagerSelected value to match the selected argument. ViewPager was then modified to properly call mAdapter.updateSelectionState(...) appropriately when pages were moving in and moving out of being selected. The FragmentManager was also updated to only dispatch menu events if the fragment was not participating in a ViewPager or was currently selected in a ViewPager. This is a wholly internal solution that requires no modification of code by anyone implementing the library. It Just Works™. The problem with this, however, is that it modifies internal APIs that exist outside the scope of the ViewPager and the library itself. Fragment and FragmentManager are built-in APIs in SDK 11+ and even though they are not used when using the ViewPager, we are now diverging the implementations between the SDK and compat lib. *Other possible solution:* * * The user who reported the problem to me wants to modify the OnPageChangeListener interface and add a deselected method. This would provide a callback for when a fragment was no longer the selected page on the screen and allow for the implementation to call setHasOptionsMenu(false). The ViewPager would make the appropriate calls like it would above except directly to the listener. This solution places the burden on the implementation on the user of the library but requires only changes in the ViewPager class. Since the class is maintained independently of the SDK (at least as of API 13) this would be ideal but is arguably not optimal. I'd like to get opinions and thoughts on these two solutions (or any additional ones you can come up with). The opinion of a Googler would also be welcome as I don't want to take my library in a direction that would differ from future iterations of the compatibility library. If you are interested in the original discussions for this bug please see: https://github.com/JakeWharton/ActionBarSherlock/issues/48 -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
