Introduction

Passing data from one Android Fragment to another is a common task, but the right solution depends on what kind of data you are moving. If the destination fragment needs initial input when it is created, use fragment arguments. If both fragments need to observe shared changing state, use a shared ViewModel.

Trying to pass data through fragment constructors or by reaching directly into another fragment instance usually creates lifecycle bugs. Android gives you better tools, and using the right one makes fragment communication predictable.

Use Fragment Arguments for Initial Input

The safest pattern is to package the required values into arguments before the destination fragment is attached.

1import android.os.Bundle
2import androidx.core.os.bundleOf
3import androidx.fragment.app.Fragment
4
5class DetailsFragment : Fragment(R.layout.fragment_details) {
6
7    companion object {
8        private const val ARG_USER_ID = "user_id"
9
10        fun newInstance(userId: String): DetailsFragment {
11            return DetailsFragment().apply {
12                arguments = bundleOf(ARG_USER_ID to userId)
13            }
14        }
15    }
16
17    override fun onCreate(savedInstanceState: Bundle?) {
18        super.onCreate(savedInstanceState)
19        val userId = requireArguments().getString(ARG_USER_ID)
20        checkNotNull(userId) { "user_id is required" }
21    }
22}

And from the sending fragment:

1parentFragmentManager.beginTransaction()
2    .replace(R.id.container, DetailsFragment.newInstance("42"))
3    .addToBackStack(null)
4    .commit()

This works well because arguments are lifecycle-aware. Android can recreate the fragment after configuration changes and still restore the same input bundle.

Use a Shared ViewModel for Shared State

If the data changes over time and both fragments need to observe it, arguments are not the best tool. A shared ViewModel scoped to the parent activity is usually cleaner.

1import androidx.lifecycle.MutableLiveData
2import androidx.lifecycle.ViewModel
3
4class SharedProfileViewModel : ViewModel() {
5    val selectedUserId = MutableLiveData<String>()
6}

Sender fragment:

1import androidx.fragment.app.activityViewModels
2
3class ListFragment : Fragment(R.layout.fragment_list) {
4    private val viewModel: SharedProfileViewModel by activityViewModels()
5
6    fun onUserClicked(userId: String) {
7        viewModel.selectedUserId.value = userId
8    }
9}

Receiver fragment:

1import androidx.fragment.app.activityViewModels
2
3class DetailsFragment : Fragment(R.layout.fragment_details) {
4    private val viewModel: SharedProfileViewModel by activityViewModels()
5
6    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
7        viewModel.selectedUserId.observe(viewLifecycleOwner) { userId ->
8            // Refresh UI for the selected user.
9        }
10    }
11}

This pattern is ideal when the destination fragment is already on screen or when multiple fragments must react to the same selection.

Which Pattern Should You Choose

A simple rule works well:

• Use arguments for one-time navigation input.
• Use a shared ViewModel for ongoing shared state.
• Use the Fragment Result API when a child fragment should return a result back to a previous fragment.

If you use the Navigation component, Safe Args gives you a typed version of the arguments pattern. The underlying idea stays the same: treat navigation input as explicit state passed through the fragment manager, not as a direct object reference.

Keep the Payload Small

Passing large objects between fragments is a bad habit. Prefer sending an ID, key, or lightweight value and loading the full object from a repository or ViewModel.

For example, pass userId = "42" rather than serializing an entire profile object. That keeps bundles small and makes process recreation much safer.

Common Pitfalls

• Using a custom fragment constructor. Android may recreate the fragment later without calling your custom constructor the way you expect.
• Writing directly to fields on another fragment instance. That breaks as soon as the destination is recreated.
• Passing large or complex objects in a Bundle. Binder transaction size limits and lifecycle issues can appear quickly.
• Observing shared state with the wrong lifecycle owner. Use viewLifecycleOwner inside fragments to avoid leaks and stale observers.
• Using arguments for data that is supposed to keep changing after navigation.

Summary

• Fragment arguments are the default choice for passing input into a new fragment.
• A shared ViewModel is better when multiple fragments need to observe the same changing data.
• Avoid custom constructors and direct fragment-to-fragment references.
• Pass small stable identifiers instead of large serialized objects.
• Choosing the right communication pattern upfront prevents most fragment lifecycle bugs.