android / android/nowinandroid

[FR]: Use navigateUp() Instead of popBackStack() for Toolbar Up Button Click

Open
#1,817 3 comments 5 reactions 0 assignees View on GitHub
enhancement
Dominant language
Kotlin
Stars
21.8k
Forks
4.6k
Avg merge
19h 20m
Merged PRs (30d)
2

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the problem

I recently reviewed the [principles of navigation in Compose](https://developer.android.com/guide/navigation/principles). From what I understand, the top app bar’s “Up” navigation button should call `navController.navigateUp()` rather than `popBackStack()`, which is intended for handling the device’s back press.

However, in the `NiaNavHost`, the `onBackClick` callbacks in various screens are currently using `popBackStack()`. My understanding is that `onBackClick` is hoisted to handle the toolbar’s “Up” button clicks in these screens.

The current implementation using `popBackStack()` works as expected. However, I would like to understand whether using `navigateUp()` might be a more appropriate approach.

### Describe the solution

## Current
```kotlin
topicScreen(
showBackButton = true,
onBackClick = navController::popBackStack,
onTopicClick = navController::navigateToTopic,
)
```

## Proposed
```kotlin
topicScreen(
showBackButton = true,
onNavigateUp = navController::navigateUp,
onTopicClick = navController::navigateToTopic,
)
```

### Additional context

_No response_

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Contributor guide

Open the contributing guide

Research direction

Start in NiaNavHost and trace the onBackClick callbacks passed to the screens, including the topicScreen example. Compare the toolbar Up behavior with the linked Compose navigation principles, then verify that the affected screens use the intended navigation callback consistently and that existing navigation behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin
Domain
mobile
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.