11 Navigation Between Screens

Overview

Navigation between screens is at the core of how users experience your Android app. Every time a user taps a button to open a new screen, goes back, shares content, or opens another app from yours, you are dealing with navigation.

In Android, a "screen" is usually represented by an Activity or a Fragment. In this chapter, you will focus on navigation between activities and the key concepts that make it work. Detailed mechanics of intents, passing data, and the back stack will be handled in their own dedicated chapters that follow.

This chapter gives you the big picture: what navigation means in Android, which tools you use for it, and how a typical multi screen flow is structured.

Screens and Activities

In most traditional Android apps, each major screen is implemented as an Activity. When you want to open a new screen, you start a new activity. When the user presses the Back button, Android usually finishes the current activity and returns to the previous screen.

Think of an app with three screens: a login screen, a list of items, and a detail screen. You might have:

• LoginActivity for authentication.
• ListActivity to display items.
• DetailActivity to show details of one item.

Navigation between these activities is what makes the app feel like a connected experience rather than three isolated pieces.

Although fragments can be used for more granular screens inside a single activity, at this stage you should understand navigation primarily in terms of moving from one activity to another.

The Role of Intents in Navigation

The main tool for navigation between activities is the Intent. You can think of an Intent as a request describing what you want to do, for example "open this other screen" or "let another app share this text".

For navigation, you commonly use explicit intents, which specifically mention the target activity class that you want to open in your own app. Implicit intents are used when you want another app to handle an action, such as opening a web page in a browser or sending an email in a mail app.

When your code wants to move from one screen to another, it typically creates an intent that names the target activity and then tells the system to start that activity. The system takes care of creating the new screen and placing it on top of the back stack so that the user can return with the Back button.

Although you will explore the exact intent syntax and usage later, for now it is important to understand that intents are the core mechanism that connects screens inside your app and also connect your app to other apps.

Typical Multi Screen Flows

Most non trivial apps are made of multiple screens. Navigation patterns can vary, but the basic ideas are similar.

A very common flow is a linear progression, like onboarding. A user starts on a welcome screen, goes to a sign in or sign up screen, then finally reaches the main content. Each navigation step uses an intent to open the next activity, and in many cases intermediate screens are finished so that the user cannot go back to them with the Back button.

Another typical flow is a list to detail pattern. A user sees a list of items, chooses one, and navigates to a detail screen that shows more information about that item. The detail screen is started with an intent and can receive information about which item to show. When the user presses Back, the system finishes the detail activity and returns to the list.

You can also have branching flows. For example, from a settings screen users might go to several different configuration screens. All of these paths share the same basic navigation idea. Each navigation action starts a new activity, and each back action removes the current activity to reveal what was underneath.

Back Navigation and User Expectations

Navigation is not only about going forward to new screens, it is also about going back in a way that feels natural. Android users expect the system Back button to take them backwards through their recent screens in a logical order, eventually exiting the app when there are no more screens left.

Android enforces this behavior with the activity back stack. Each time a new activity is started in the standard way, it is pushed onto this stack. When the user presses Back, the top activity is popped off and destroyed, and the previous activity becomes visible again.

If you break these expectations, for example by trapping the Back button without a good reason, or by closing the app abruptly instead of moving backward through screens, the user experience becomes confusing. Good navigation design respects the default back behavior as much as possible.

You can still customize how navigation works, but those customizations should be consistent and predictable. Complex patterns such as deep linking, nested navigation flows, or bottom navigation tabs build on top of this model, but the basic back navigation principle remains the same.

Single Activity vs Multiple Activities

Historically, many apps used one activity per screen. Today, a common approach is to use a single "host" activity and place different fragments inside it to represent different screens. Both styles still rely on the same underlying navigation ideas, and both still use intents when moving between activities.

In a multi activity architecture, most navigation is between activities with intents. In a single activity architecture, most navigation is within one activity using fragment transactions, while intents are reserved for entering or leaving the app in a larger sense, for example opening your app from a notification or jumping from your app to a different app.

As you progress, you will see how intent based navigation between activities and fragment based navigation within an activity can coexist in the same app.

Internal vs External Navigation

Navigation does not always stay inside your app. Sometimes you want to open another app to perform a task. Examples include opening the phone dialer, showing a location in a maps app, sending an email, or sharing text with a messaging app.

From the user’s perspective, this is still part of navigation. They tap something in your app, something else appears, they press Back, and they come back to your app. Under the hood, Android uses intents in both directions to make this work.

Internal navigation usually uses explicit intents that target your own activities. External navigation uses implicit intents that describe an action and some data, and the system chooses an appropriate external app to handle it. Understanding this distinction will help you design flows where your app cooperates gracefully with others, instead of trying to do everything itself.

Deep Links and Entry Points

Not all navigation starts from your main screen. Users might enter your app from a notification, from a link in a browser, from another app, or from a saved shortcut. These alternate entry points are handled through deep links and special intent filters declared in your manifest.

Deep links allow the system to open a specific screen inside your app directly. For example, a link in an email might take the user straight to a detail screen for one item, instead of just opening the home screen.

From a navigation perspective, this means your app needs to handle multiple starting points gracefully. The internal navigation flow should still make sense no matter which screen the user starts on. Once inside, they still expect Back to behave in a way that feels natural, even if the app did not start at the usual entry activity.

Navigation Design Considerations

Effective navigation is not just a technical detail, it is also a design question. When you plan navigation between screens, you should ask how users will move through tasks, what information they need at each step, and how they will get back if they change their mind.

Too many screens can make navigation feel slow and complicated. Too few screens can make a single screen crowded and hard to understand. You need to find a balance that fits the complexity of your app.

Patterns such as top app bars, bottom navigation, navigation drawers, and tabs help structure navigation visually. Underneath those visual elements, you are still using the same navigation fundamentals: starting activities, managing the back stack, and moving between logical states of the app.

How This Chapter Fits With The Next Ones

This chapter has focused on the overall idea of navigating between screens and the user experience that results. The following chapters in this section go deeper into specific tools that make navigation work.

You will learn how to use intents to start activities and interact with other apps, how to pass data between activities so that information can flow through your screens, and how the activity back stack behaves in more detail. Together these topics will give you the practical skills to build apps that are not just a single screen, but complete and navigable experiences.