For grabbing fragments out of a ViewPager there are a lot of answers on here and on other related SO threads / blogs. Everyone I have seen is broken, and they generally seem to fall into one of the two types listed below. There are some other valid solutions if you only want to grab the current fragment, like this other answer on this thread.
If using FragmentPagerAdapter
see below. If using FragmentStatePagerAdapter
its worth looking at this. Grabbing indexes that are not the current one in a FragmentStateAdapter is not as useful as by the nature of it these will be completely torn down went out of view / out of offScreenLimit bounds.
THE UNHAPPY PATHS
Wrong: Maintain your own internal list of fragments, added to when FragmentPagerAdapter.getItem()
is called
- Usually using a
SparseArray
or Map
- Not one of the many examples I have seen accounts for lifecycle events so this solution is fragile. As
getItem
is only called the first time a page is scrolled to (or obtained if your ViewPager.setOffscreenPageLimit(x)
> 0) in the ViewPager
, if the hosting Activity
/ Fragment
is killed or restarted then the internal SpaseArray
will be wiped out when the custom FragmentPagerActivity is recreated, but behind the scenes the ViewPagers internal fragments will be recreated, and getItem
will NOT be called for any of the indexes, so the ability to get a fragment from index will be lost forever. You can account for this by saving out and restoring these fragment references via FragmentManager.getFragment()
and putFragment
but this starts to get messy IMHO.
Wrong: Construct your own tag id matching what is used under the hood in FragmentPagerAdapter
and use this to retrieve the page Fragments from the FragmentManager
- This is better insomuch as it copes with the losing-fragment-references problem in the first internal-array solution, but as rightly pointed out in the answers above and elsewhere on the net - it feels hacky as its a private method internal to
ViewPager
that could change at any time or for any OS version.
The method thats recreated for this solution is
private static String makeFragmentName(int viewId, long id) {
return "android:switcher:" + viewId + ":" + id;
}
A HAPPY PATH: ViewPager.instantiateItem()
A similar approach to getItem()
above but non-lifecycle-breaking is to this is to hook into instantiateItem()
instead of getItem()
as the former will be called everytime that index is created / accessed. See this answer
A HAPPY PATH: Construct your own FragmentViewPager
Construct your own FragmentViewPager
class from the source of the latest support lib and change the method used internally to generate the fragment tags. You can replace it with the below. This has the advantage that you know the tag creation will never change and your not relying on a private api / method, which is always dangerous.
/**
* @param containerViewId the ViewPager this adapter is being supplied to
* @param id pass in getItemId(position) as this is whats used internally in this class
* @return the tag used for this pages fragment
*/
public static String makeFragmentName(int containerViewId, long id) {
return "android:switcher:" + containerViewId + ":" + id;
}
Then as the doc says, when you want to grab a fragment used for an index just call something like this method (which you can put in the custom FragmentPagerAdapter
or a subclass) being aware the result may be null if getItem has not yet been called for that page i.e. its not been created yet.
/**
* @return may return null if the fragment has not been instantiated yet for that position - this depends on if the fragment has been viewed
* yet OR is a sibling covered by {@link android.support.v4.view.ViewPager#setOffscreenPageLimit(int)}. Can use this to call methods on
* the current positions fragment.
*/
public @Nullable Fragment getFragmentForPosition(int position)
{
String tag = makeFragmentName(mViewPager.getId(), getItemId(position));
Fragment fragment = getSupportFragmentManager().findFragmentByTag(tag);
return fragment;
}
This is a simple solution and solves the issues in the other two solutions found everywhere on the web
Fragment
in aWeakReference
to guarantee you don't prevent a destroyed fragment from being garbage collected? Just seems like the right thing to do... – Springwood