Introduction

Retrieving a fragment from a ViewPager sounds simple, but the answer depends on how the adapter manages fragment instances. With ViewPager, fragments may be created, cached, restored, or destroyed by the adapter and fragment manager, so reaching for a fragment by position only works reliably if you understand that lifecycle.

The Most Practical Approach: Ask the FragmentManager

For classic ViewPager with FragmentPagerAdapter or FragmentStatePagerAdapter, the fragment manager stores fragments under a predictable tag pattern. That lets you retrieve the currently managed fragment by position.

1fun findFragment(viewPagerId: Int, position: Int): Fragment? {
2    val tag = "android:switcher:$viewPagerId:$position"
3    return supportFragmentManager.findFragmentByTag(tag)
4}

This works because the pager adapter uses that naming convention internally for attached fragments.

Why Position Alone Is Not Enough

A common mistake is to keep a simple list of fragments and assume those references always match what the ViewPager is actually displaying. With FragmentStatePagerAdapter, off-screen fragments may be destroyed and recreated, so stale references can become misleading.

That is why querying the fragment manager is often more reliable than keeping your own unmanaged cache.

If You Control the Adapter, Track Fragments Carefully

Sometimes you do want the adapter to keep references intentionally.

1class MyPagerAdapter(fm: FragmentManager) : FragmentStatePagerAdapter(fm) {
2    private val fragments = mutableMapOf<Int, Fragment>()
3
4    override fun getItem(position: Int): Fragment {
5        return when (position) {
6            0 -> FirstFragment()
7            else -> SecondFragment()
8        }
9    }
10
11    override fun instantiateItem(container: ViewGroup, position: Int): Any {
12        val fragment = super.instantiateItem(container, position) as Fragment
13        fragments[position] = fragment
14        return fragment
15    }
16
17    override fun destroyItem(container: ViewGroup, position: Int, obj: Any) {
18        fragments.remove(position)
19        super.destroyItem(container, position, obj)
20    }
21
22    fun getFragment(position: Int): Fragment? = fragments[position]
23}

If you do this, the cache must stay synchronized with the adapter lifecycle. Otherwise the references become incorrect.

Sometimes Retrieval Is the Wrong Design Goal

In many cases, directly grabbing a fragment is not the cleanest solution. Shared ViewModels, callbacks, fragment results, or adapter-driven state updates are often better patterns than reaching into the pager to manipulate a fragment instance directly.

If the need to "retrieve a fragment" comes from one screen wanting to push data into another screen, shared state or explicit communication channels usually scale better.

ViewPager2 Changes the Context

If the project uses ViewPager2, the adapter and fragment behavior differ, and old ViewPager advice does not always transfer directly. That is why the exact pager implementation matters before copying a fragment-retrieval snippet.

Retrieving the Current Page Is a Special Case

If you only need the fragment for the currently visible page, start from viewPager.currentItem and then ask the fragment manager for the tag tied to that position. That is often simpler than trying to maintain references for every page when the immediate need is only to interact with the active one.

Common Pitfalls

• Assuming fragment position maps permanently to one live fragment object.
• Keeping references without respecting FragmentStatePagerAdapter lifecycle behavior.
• Retrieving fragments directly when a shared ViewModel or result API would be cleaner.
• Mixing ViewPager and ViewPager2 solutions as if they were identical.
• Debugging stale fragment references instead of asking the fragment manager for the active instance.

Summary

• The safest classic ViewPager retrieval technique is often FragmentManager.findFragmentByTag(...).
• Adapter-managed fragment references can work, but only if they stay lifecycle-aware.
• Fragment destruction and recreation make naive position-based caching unreliable.
• Sometimes fragment retrieval is a design smell and shared state is the better solution.
• ViewPager and ViewPager2 should not be treated as interchangeable APIs.