AppBarConfiguration(Menu) constructor sets graph IDs, not graph start destination IDs, as top level destinations [238496771]

Fixed

Bug

Status Update

No update yet.

Description

st...@gmail.com

created issue #1

Jul 10, 2022 02:44PM

Component used: Navigation Version used: 2.4 Devices/Android versions reproduced on: all

AppCompatActivity::setupActionBarWithNavController can be called to automatically update app bar content when navigation destination changes. In particular, setupActionBarWithNavController promises to automatically hide the Up arrow for "top-level" destinations and show the Up arrow for all other destinations. To achieve this, setupActionBarWithNavController needs to infer or be told which destinations are "top-level".

When using a BottomNavigationView, I wanted

the root screen of each tab to have no Up arrow, and
all other screens to have an Up arrow.

I tried calling setupActionBarWithNavController and passing a custom AppBarConfiguration constructed using the Menu instance from the BottomNavigationView:

AppBarConfiguration.Builder(
  topLevelMenu = bottomNavigationViewMenu
).build()

Unfortunately, when passed a Menu whose entries correspond to navigation graph IDs, AppBarConfiguration::Builder sets the graph IDs as top-level destination IDs, rather than the setting the graph start destination IDs as top-level destination IDs. The result is that the AbstractAppBarOnDestinationChangedListener applied by setupActionBarWithNavController mistakenly classifies every destination as top-level and no screens have an Up arrow.

This can be worked around by explicitly passing the IDs of the start destinations of each tab's graph when constructing the AppBarConfiguration builder:

AppBarConfiguration.Builder(
  topLevelDestinationIds = setOf(
    tab1StartDestinationId,
    tab2StartDestinationId,
    tab3StartDestinationId,
  )
).build()

However, the behavior of AppBarConfiguration.Builder(Menu) remains surprising and it would be good to investigate whether that constructor could be made to behave as I anticipated!

Android Study Group Slack thread: https://androidstudygroup.slack.com/archives/CAZCL8AVB/p1656470310000929?thread_ts=1655997032.467509&cid=CAZCL8AVB

Comments

il...@google.com <il...@google.com> Jul 13, 2022 11:54PM

Assigned to jb...@google.com.

il...@google.com <il...@google.com> Sep 13, 2022 07:50PM

Reassigned to cl...@google.com.

ap...@google.com <ap...@google.com> #2Sep 23, 2022 03:56PM

Some new information? This issue is already over a year old, it was just shifted, and the new ticket here seems to be ignored. This should have a higher Priority then P3.

I feel like this is a serious issue that should get more attention. When working with RecyclerViews you had the possibility of setting up if a ViewHolder is able the be recycled.

All the solutions to circumvent this problem here are either hacks in regards to how the Keyboard is opened, or you ditch LazyColumn completely and use a Column, which is not a solution for complex layouts.

cl...@google.com <cl...@google.com> #3Sep 26, 2022 05:12PM

Marked as fixed.

1.2.0-beta02 it still remains

st...@gmail.com <st...@gmail.com> #4Sep 26, 2022 06:11PM

and cause the other focusable element could not access touch

na...@google.com <na...@google.com> #5Oct 5, 2022 05:14PM

We should have some API to pin an item to indicate that we want to keep it around and not dispose it.

Please don't make this API internal, make it public for everyone to use and also allow this API to be used with any kind of items inside of LazyLayout's (not only focusable items). I have described why I need it in this issue https://issuetracker.google.com/issues/236279213 Thanks.

Issue 238496771