Skip to content
tezvyn:

How to pass data between Fragments with Jetpack Navigation?

Source: developer.android.comEasyHow cards are made

How to pass data between Fragments with Jetpack Navigation?

This tests your knowledge of type-safe argument passing in Jetpack Navigation. A good answer defines the argument in XML, uses the Safe Args plugin to generate code, passes data via the Directions class, and retrieves it with the Args class.

What's really being asked

This question tests your knowledge of the modern, recommended pattern for passing data between destinations in Android. The key is demonstrating an understanding of type safety and compile-time checks, which are the primary benefits of using the Safe Args Gradle plugin over older, manual methods. It separates candidates who know the modern Jetpack way from those still using error-prone manual Bundle manipulation.

The full answer

A strong answer walks through four distinct steps in order. First, you define the argument in the navigation graph XML file by adding an <argument> tag to the destination fragment, specifying its name and argType. Second, you enable the Safe Args Gradle plugin in your build.gradle files, which triggers code generation. Third, in the source fragment, you use the auto-generated Directions class to create a type-safe action, passing the data as a parameter (e.g., HomeFragmentDirections.actionHomeToProfile(userId)). This returns a NavDirections object that you pass to navController.navigate(). Fourth, in the destination fragment, you retrieve the data using the generated Args class, typically with the 'by navArgs()' Kotlin property delegate.

The mistakes people make

The most common wrong answer is describing how to manually create a Bundle, put data into it with a string key, and pass that Bundle to the navigate() function. While this works, it's the old, error-prone method that Safe Args is designed to replace. It signals a lack of familiarity with modern Android development practices. Another red flag is suggesting a shared ViewModel for this simple use case. While ViewModels are great for sharing complex, observable state across a flow, they are overkill for simple, one-way argument passing and indicate a misapplication of architectural patterns.

What usually comes next

Expect follow-up questions like: "When would you use a shared ViewModel instead of navigation arguments?" (Answer: For complex data, two-way data flow, or state that needs to be shared by multiple destinations in a flow). Another is "How do you pass a custom Parcelable object?" (Answer: You set the app:argType to the fully qualified class name of your Parcelable object). Finally, "What are the benefits of Safe Args?" (Answer: Type safety, null safety, and compile-time checks, which eliminate a class of runtime crashes).

A concrete example

To pass a userId string from HomeFragment to ProfileFragment: In your nav_graph.xml, add <argument android:name="userId" app:argType="string" /> inside the ProfileFragment destination. In HomeFragment, you'd call val action = HomeFragmentDirections.actionHomeFragmentToProfileFragment(userId = "user-123") and then findNavController().navigate(action). In ProfileFragment, you'd retrieve it with val args: ProfileFragmentArgs by navArgs() and then use args.userId to get the "user-123" value.

Interview question

Which approach is recommended for passing simple, one-way data between Fragments using Jetpack Navigation?

  • a.Define arguments in the navigation graph XML and use the generated Safe Args classes.Correct
  • b.Manually create a Bundle with string keys and pass it to the navigate function.
  • c.Utilize a shared ViewModel to store and retrieve the data between fragments.
  • d.Store the data in a global static variable or SharedPreferences.
Why?

The card highlights that defining arguments in the navigation graph XML and using the generated Safe Args classes is the modern, type-safe, and recommended approach. Manually creating Bundles is an older, error-prone method that Safe Args was designed to replace.

Just read this? Test yourself on what you have been reading.

Read the original → developer.android.com

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.

See open roles