Android Navigation Graph: A Map for Your UI
Think of the Navigation Graph as a visual map of your app's screens. It centralizes all navigation logic in one XML file, defining destinations (screens) and actions (paths between them), simplifying transitions and deep linking.
Why it exists
Before the Navigation Component, developers manually managed FragmentTransactions, the back stack, and argument passing between screens. This was boilerplate-heavy and error-prone, making the app's flow hard to visualize and maintain. The Navigation Graph was created to provide a single, centralized source of truth for app navigation.
The mental model
A Navigation Graph is a state machine for your user interface. Each screen (a Fragment or Activity) is a "destination" or state. Each path from one screen to another, triggered by a user event like a button click, is an "action" or transition. This entire map is visually represented in a single XML resource file, making the app's flow easy to understand at a glance.
How it works
You define your app's navigation flow in an XML file inside the res/navigation directory. This file contains <destination> tags for each screen and <action> tags to define the paths between them. In your main activity's layout, you add a NavHostFragment, which acts as a container that displays the current destination from the graph. You use a NavController object in your UI code to trigger navigation by calling its navigate() method with an action's ID. The component handles all the underlying Fragment transactions and back stack management.
When to use it
It's the recommended approach for almost all modern Android apps, especially those following a single-activity architecture with multiple fragments. Use it to simplify argument passing between screens, implement deep links, and create standardized screen transitions and animations.
When not to use it
For extremely simple apps with only one or two screens, it might be slight overkill. Also, if your app's navigation is highly dynamic and cannot be reasonably predefined in an XML graph, you might need a more custom solution, although you can also build graphs programmatically.
One canonical example
A simple app has a LoginFragment and a ProfileFragment. The navigation graph XML defines both as destinations and sets LoginFragment as the start destination. An action with the ID action_login_to_profile connects them. In the LoginFragment's code, after a successful login, you get the NavController and call navController.navigate(R.id.action_login_to_profile). The Navigation Component automatically replaces the LoginFragment with the ProfileFragment and correctly manages the back stack.
Interview question
What is the primary problem the Android Navigation Graph was designed to solve for developers?
- a.The manual, error-prone management of Fragment transactions, argument passing, and the back stack.Correct
- b.The difficulty in creating custom animations and transitions between UI elements.
- c.The complexity of managing data flow and state across different components of an application.
- d.The challenge of designing responsive layouts that adapt to various screen sizes and orientations.
Why? this is the answer
The card explicitly states the Navigation Graph was created because "developers manually managed FragmentTransactions, the back stack, and argument passing between screens. This was boilerplate-heavy and error-prone." While it can help with transitions (B) and argument passing (part of B), its primary purpose is to centralize and simplify the overall navigation flow, not to create custom animations or manage general state. Option D is unrelated to navigation.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #kotlin
- #navigation
- #jetpack
- #ui
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