How do you pass data between Fragments with Jetpack Navigation?

Tests knowledge of modern, type-safe argument passing. A good answer defines the argument in the nav graph XML, uses the Safe Args plugin to generate Directions/Args classes, navigates with the action, and retrieves the data in the destination via `by…
What's really being asked
This question tests your familiarity with the modern, recommended patterns for Android UI development. It specifically probes whether you know how to use the Jetpack Navigation component's type-safe argument passing mechanism (Safe Args) versus older, more error-prone methods like manually creating Bundles. It's a check for up-to-date, best-practice knowledge.
The full answer
A strong answer walks through four distinct steps. First, define the argument in the navigation graph XML file within the destination fragment's tag, specifying its name and app:argType (e.g., string, integer). Second, enable and apply the Safe Args Gradle plugin in your build.gradle files, which auto-generates type-safe classes. Third, in the source fragment, use the generated NavDirections class to create an action and pass the data as a typed parameter, then navigate using that action object. For example, SourceFragmentDirections.actionToDestination(userId = "abc-123"). Fourth, in the destination fragment, retrieve the arguments using the generated Args class, typically with the by navArgs() Kotlin property delegate.
The mistakes people make
A major red flag is suggesting manual Bundle creation (e.g., val bundle = Bundle().apply { putString("USER_ID", "123") } and passing it to navigate()). This is not type-safe and is the pre-Safe Args way of doing things. It indicates a lack of familiarity with modern tooling. Another less-than-ideal answer is immediately jumping to a shared ViewModel scoped to the Activity. While a valid pattern for sharing complex state, it's overkill for passing a simple, immutable ID from one screen to the next and isn't the direct answer to the question. Using Fragment constructors to pass data is a fundamental anti-pattern and a serious red flag.
What usually comes next
Expect questions like, "When would you choose a shared ViewModel over navigation arguments?" (Answer: For complex, mutable data or state that needs to survive beyond a single navigation event). Or, "How do you pass a custom Parcelable object?" (Answer: You specify the fully qualified class name in the app:argType attribute). A follow-up on the benefits of Safe Args is also common (Answer: Compile-time safety, null safety, and avoiding key/type mismatch errors at runtime).
A concrete example
In nav_graph.xml, the destination has <argument android:name="userId" app:argType="string" />. The source fragment calls val action = FirstFragmentDirections.actionFirstToSecond(userId = "user-99"); findNavController().navigate(action). The destination fragment retrieves it with private val args: SecondFragmentArgs by navArgs() and then accesses the value with args.userId.
Interview question
What is the recommended, type-safe method for passing a user ID from a list fragment to a detail fragment using the Jetpack Navigation component?
- a.Define an argument in the navigation graph, then use the generated NavDirections and NavArgs classes to pass and retrieve the data.Correct
- b.Store the user ID in a shared ViewModel scoped to the parent Activity, and have the detail fragment observe it.
- c.Pass the user ID directly to the destination fragment's constructor when creating its instance.
- d.Create a Bundle, put the user ID into it with a key, and pass the Bundle to the navigate() function.
Why? this is the answer
The correct approach uses the Safe Args plugin to generate type-safe classes for navigation actions and arguments, preventing runtime errors. Manually creating a Bundle is the older, error-prone method that lacks compile-time safety.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #kotlin
- #jetpack
- #navigation
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.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles