Status Update
Comments
il...@google.com <il...@google.com> #2
Please provide the below details to investigate this issue further.
1. The file dynamic_action_bar.xml has many dependencies missed out here. So please attach your sample android project which reproduces the issue, zip it and share.
2. Explain the steps to reproduce the issue with your apk. Provide all necessary information to reproduce the issue.
3. Provide clarity on the expected and observed behavior along with the necessary screenshots.
JFYI, the latest support lib released is 26.1.0. So you can check with it and share the details if issue persists.
ur...@gmail.com <ur...@gmail.com> #3
lo...@gmail.com <lo...@gmail.com> #4
Steps to reproduce:
1. Launch the app
2. Scroll to "Title 20"
3. Fling down to show the action bar and the recycler view will stop scrolling at the same time.
4. Click on any item.
5. The click event will not be triggered.
The attachment of the first mail is the screen recording.
You can see more details in the first mail.
As you said that "This is a special release to integrate the Support Library with Lifecycles from Architecture Components. If you are not using the Lifecycles library, you don’t need to update from 26.0.2." on the release notes, so I don' t use the 26.1.0.
an...@zappos.com <an...@zappos.com> #5
il...@google.com <il...@google.com> #6
re...@gmail.com <re...@gmail.com> #7
ne...@gmail.com <ne...@gmail.com> #8
So you fling the RecyclerView, then wait as long as you like - the first item tap will not be recognised. Subsequent taps work just fine. But if you scroll the RecyclerView with no fling gesture, the first item tap will be recognised as expected.
I am also using a RecyclerView nested in a CoordinatorLayout (RV using layout_behavior = appbar_scrolling_view_behavior).
Support Library Version 26.1.0.
be...@gmail.com <be...@gmail.com> #9
I am facing the same issue, it is working correctly with support version 26.0.0-alpha1 and 26.0.0-beta1, but the bug appears starting from the 26.0.0 release, and still present with the 26.0.1.
It seems to be associated with the NestedScrollingChild2 interface. With alpha and beta version, RecyclerView was implementing the NestedScrollingChild interface, and starting from 26.0.0 release, it is implementing NestedScrollingChild2 interface.
To reproduce, just create a sample ScrollingActivity from AndroidStudio, create an adapter holding a list of items, set a click listener on each item, scroll to the bottom of the list. When you are on the bottom of the list, fling from the bottom of your screen to the top and try to click to a specific item. It will do nothing (seems to stop the invisible fling), then if you click again, it will select your item.
vi...@gmail.com <vi...@gmail.com> #10
ma...@gmail.com <ma...@gmail.com> #11
bm...@gmail.com <bm...@gmail.com> #12
an...@backx.org <an...@backx.org> #13
il...@google.com <il...@google.com> #14
mi...@gmail.com <mi...@gmail.com> #15
The original bug is caused by the change in 26.0.0 where flings can continue, even if the view is not actually moving. This was done to allow AppBarLayout to react to "resting" flings through nested scrolling.
The issue here is that once AppBarLayout has finished reacting to the resting fling (reach its end) the fling can still continue. Therefore even though nothing is moving on screen, when the user touches the screen they are just cancelling the invisible fling. Subsequent touches then do as expected (clicks, etc).
The fix here is more of a workaround than a proper fix. Here AppBarLayout detects when it has finished its fling handling, and then stops the nested scroll on the scrolling view (RV, etc).
ev...@willowtreeapps.com <ev...@willowtreeapps.com> #16
If you want to stuff this in a base class and know you're not setting any other behaviors on your appbarlayouts, you can put it in a base class in an overridden setLayoutParameters method
il...@google.com <il...@google.com> #17
@CoordinatorLayout.DefaultBehavior(FixAppBarLayoutBehavior.class)
public CustomAppBarLayout extends AppBarLayout {
// ....
}
That way, you do not have to mess around with your layouts or the LayoutParams.
at...@gmail.com <at...@gmail.com> #18
tt...@appbird.com <tt...@appbird.com> #19
tt...@appbird.com <tt...@appbird.com> #20
[Deleted User] <[Deleted User]> #21
ig...@gmail.com <ig...@gmail.com> #22
mi...@gmail.com <mi...@gmail.com> #23
[Deleted User] <[Deleted User]> #24
il...@google.com <il...@google.com> #25
nobody@google.com <nobody@google.com> #26
se...@gmail.com <se...@gmail.com> #27
jo...@powerschool.com <jo...@powerschool.com> #28
il...@google.com <il...@google.com> #29
de...@gmail.com <de...@gmail.com> #30
il...@google.com <il...@google.com> #31
[Deleted User] <[Deleted User]> #32
[Deleted User] <[Deleted User]> #33
de...@gmail.com <de...@gmail.com> #34
ja...@google.com <ja...@google.com> #35
va...@gmail.com <va...@gmail.com> #36
ni...@gmail.com <ni...@gmail.com> #37
mo...@gmail.com <mo...@gmail.com> #38
um...@gmail.com <um...@gmail.com> #39
ph...@bayfmail.com <ph...@bayfmail.com> #40
rm...@gmail.com <rm...@gmail.com> #41
ri...@gmail.com <ri...@gmail.com> #42
ag...@gmail.com <ag...@gmail.com> #43
Hoping to see a proper solution, currently this is my workaround until then. Not the best workaround, but does work for me:
Override
public void onScrollStateChanged(final int state)
{
super.onScrollStateChanged(state);
if (state == RecyclerView.SCROLL_STATE_SETTLING)
{
this.stopScroll();
}
}
dt...@gmail.com <dt...@gmail.com> #44
[Deleted User] <[Deleted User]> #45
mo...@gmail.com <mo...@gmail.com> #46
da...@gmail.com <da...@gmail.com> #47
ho...@gmail.com <ho...@gmail.com> #49
[Deleted User] <[Deleted User]> #50
al...@gmail.com <al...@gmail.com> #51
mi...@joyn.de <mi...@joyn.de> #52
te...@googlemail.com <te...@googlemail.com> #53
ro...@gmail.com <ro...@gmail.com> #54
ke...@gmail.com <ke...@gmail.com> #55
The issue is that after a fling event, the nested scrolling api has no way of informing the RecyclerView that a fling animation has reached the end of the scroll distance, and thus sometimes, the scroll animation is continuing in the background such that when the first tap occurs, it is interpreted as an interruption to the fling, which puts the RV back into its scrolling state as if the user started scrolling, and thus, the touch events don't propagate down to the child to cause a click to occur.
Some larger changes are needed to fix this (and at least one other) issue, and I'm in the midst of that work.
Sorry for the inconvenience.
ph...@visibacare.com <ph...@visibacare.com> #56
il...@google.com <il...@google.com>
so...@gmail.com <so...@gmail.com> #57
May I ask in this version, fix this issue?
ad...@gmail.com <ad...@gmail.com> #58
ro...@gmail.com <ro...@gmail.com> #59
ha...@live.com <ha...@live.com> #60
When RecyclerView is flung, and it hits the bounds of it's scrollable distance and has a NestedScrollingParent, it continues to animate the fling so that the NestedScrollingParent might receive the events and scroll. RV has no way of knowing if any NestedScrollingParents have hit their bounds, and thus it continues the fling even if nothing is moving.
On top of that, when RV is flinging and is touched, it stops it's fling and prevents the touch event from causing a click, so that a touch meant to stop a fling doesn't cause a click.
Put those two things together and you get the perceived behavior that when an RV is flung, and stops, the next touch event doesn't click.
I'm pursuing a but can't make any promises as to when it will be available. Sorry for the inconvenience.
mo...@gmail.com <mo...@gmail.com> #61
sh...@gmail.com <sh...@gmail.com> #63
mo...@gmail.com <mo...@gmail.com> #64
il...@google.com <il...@google.com> #65
aa...@marinosoftware.com <aa...@marinosoftware.com> #66
am...@gmail.com <am...@gmail.com> #67
il...@google.com <il...@google.com> #68
as...@gmail.com <as...@gmail.com> #69
va...@gmail.com <va...@gmail.com> #70
il...@google.com <il...@google.com> #71
as...@gmail.com <as...@gmail.com> #72
jo...@gmail.com <jo...@gmail.com> #73
af...@gmail.com <af...@gmail.com> #74
yg...@gmail.com <yg...@gmail.com> #75
yg...@gmail.com <yg...@gmail.com> #76
il...@google.com <il...@google.com> #77
ya...@gmail.com <ya...@gmail.com> #78
[Deleted User] <[Deleted User]> #79
I am actively solving this issue. In fact, the CL that makes the necessary changes in RecyclerView has been submitted to aosp (as AndroidX is now developed there):
The fix is coming by way of an update to nested scrolling and thus need to be implemented across multiple classes. For example, for the issue to be fixed when a RecyclerView is in a CoordinatorLayout with the AppBarLayout.Behavior, implementation has to be done in each of those classes.
Unfortunately the rollout of these changes is also going to take some time, but do know that we are taking as seriously as we can.
al...@gmail.com <al...@gmail.com> #80
lv...@gmail.com <lv...@gmail.com> #81
co...@gmail.com <co...@gmail.com> #83
I've tried both java and xml ways but in vain.
Checked on emulator running on 5.0 and physical device running on 7.1.1
Any ideas ?
vu...@gmail.com <vu...@gmail.com> #84
he...@gmail.com <he...@gmail.com> #85
ia...@gmail.com <ia...@gmail.com> #87
an...@gmail.com <an...@gmail.com> #88
Dear Google developers, can you please take it on priority?
gr...@gmail.com <gr...@gmail.com> #89
ib...@gmail.com <ib...@gmail.com> #90
I think it is related with NestedScrollingChild3 and NestedScrollingParent3 and since 1.1.0-alpha01 RecyclerView and CoordinatorLayout implements those.
so...@gmail.com <so...@gmail.com> #91
gu...@gmail.com <gu...@gmail.com> #92
androidx.core 1.1.0-alpha01
androidx.appcompat 1.1.0-alpha01
androidx.coordinatorlayout 1.1.0-alpha01
androidx.recyclerview 1.1.0-alpha01
androidx.swiperefreshlayout 1.1.0-alpha01
(and an upcoming release of the android material design library)
This issue should be fixed!
I'm closing it, but do let me know if it seems to still be happening!
ka...@salesforce.com <ka...@salesforce.com> #93
This is a BottomSheet with a NestedScrollView, it does not contain any RecyclerView:
<?xml version="1.0" encoding="utf-8"?>
<androidx.coordinatorlayout.widget.CoordinatorLayout
xmlns:android="
xmlns:app="
android:layout_width="match_parent"
android:layout_height="match_parent"
android:clipChildren="false">
<com.google.android.material.appbar.AppBarLayout
android:layout_width="match_parent"
android:layout_height="wrap_content">
<!--Other views and tested with and without a Toolbar inside-->
</com.google.android.material.appbar.AppBarLayout>
<androidx.core.widget.NestedScrollView
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="@color/white"
app:layout_behavior="@string/appbar_scrolling_view_behavior">
<LinearLayout
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:orientation="vertical"
android:paddingBottom="8dp"
android:paddingTop="8dp">
<!--Enough views to create a scrollable area-->
</LinearLayout>
</androidx.core.widget.NestedScrollView>
</androidx.coordinatorlayout.widget.CoordinatorLayout>
In this scenario (with or without a Toolbar view in the AppBarLayout parent) whenever you scroll the NestedScrollView to the top or to the bottom and try to tap on any items inside the LinearLayout the first tap will always fail to initiate the expected action, forcing you to do a second tap since after the first one the taps start working. This happens whenever you scroll to the top or bottom of the NestedScrollView every single time, even after you tap for a second or n times.
I am using the library versions or most up to date (a couple were already updated since then) the Assignee listed in his last reply.
il...@google.com <il...@google.com> #94
There isn't a public bug that I'm aware of that is tracking that precise work, but know that your specific issue will be fixed in an upcoming release of the Android Material Design library.
ap...@google.com <ap...@google.com> #95
ap...@google.com <ap...@google.com> #96
ap...@google.com <ap...@google.com> #97
al...@gmail.com <al...@gmail.com> #98
recyclerview-v7:28.0.0
ap...@google.com <ap...@google.com> #99
ap...@google.com <ap...@google.com> #100
The AndroidX version of RecyclerView picks up where that version left off and is currently supported:
ap...@google.com <ap...@google.com> #101
ap...@google.com <ap...@google.com> #102
di...@gmail.com <di...@gmail.com> #103
je...@gmail.com <je...@gmail.com> #104
[Deleted User] <[Deleted User]> #105
ap...@google.com <ap...@google.com> #106
su...@gmail.com <su...@gmail.com> #107
[Deleted User] <[Deleted User]> #108
ap...@google.com <ap...@google.com> #109
but it's working fine if I double tap it quickly
ap...@google.com <ap...@google.com> #110
ap...@google.com <ap...@google.com> #111
Updated my AndroidX dependencies and fixed the issue with appbarlayout/bottomnav/recyclerview. Did not try out MotionLayout
il...@google.com <il...@google.com> #112
As per saveBackStack(name: String)
and restoreBackStack(name: String)
APIs have been added to FragmentManager
in
With the Fragment work complete, the implementation work on the Navigation side of multiple back stacks is next up - you'll continue to see changes added to this CL as that work continues.
As a reminder, that Navigation work includes:
- The generic Navigation API that will allow any Navigator (be it Fragments, Compose, etc) to support multiple back stacks
- Rework of the existing Navigators to support multiple back stacks out of the box
- The APIs in
NavigationUI
and other surfaces to allow you to easily opt in to using multiple back stacks
Also as mentioned before:
I'd ask that you hold your comments on the intermediate steps along the way as much of it will make more sense when taken as a whole once we release the first alphas (still planned for Fragment 1.4.0-alpha01
and Navigation 2.4.0-alpha01
). Definitely expect a more thorough run through of how to use of these APIs via documentation, samples (including updating the NavigationAdvancedSample
to use the new APIs), blog posts, videos, and everything else at that point and onward. Besides seeing each commit come through on this issue, we'll also make sure to point out when a first snapshot is available with working APIs for those of you who would like an early preview before the first alpha releases.
Again, please keep in mind the many people who get emailed for each comment on this issue - let's continue to keep this as a good channel for updates and not for general discussion or requests for additional progress updates. If you'd like to receive updates, please star the issue, not comment on it.
ap...@google.com <ap...@google.com> #113
Branch: androidx-main
commit b3588b98629d9552c5666a0e3a3984927ba80b0d
Author: Ian Lake <ilake@google.com>
Date: Mon Apr 05 15:51:01 2021
Add NavOptions for saving and restoring the back stack
When navigating with the NavController, the primary
mechanism is via calls to navigate(), which simply
adds the new destination to the back stack. NavOptions
are the existing mechanism for modifying that default
behavior (e.g., using launchSingleTop to ensure only
one copy of the destination is on the top of the
back stack).
Therefore NavOptions is one of the surfaces that needs
to be updated to support multiple back stacks in two ways:
- the restoreState boolean controls whether any previously
saved back stack and destination states associated with
the destination you're navigating to should be restored
- the popUpToSaveState boolean controls whether the back
stack and destination states between the current destination
and your popUpTo destination (inclusive or not) should be
saved for later restoration
Note: these APIs are not currently plugged into the
NavController or Navigators. That will be done in
follow up CLs.
Relnote: N/A
Test: Updated tests pass
BUG: 80029773
Change-Id: I7f4db810f027dd83f34c4906d4d21e73e051b35c
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/androidTest/java/androidx/navigation/NavOptionsBuilderTest.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavOptions.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavOptionsBuilder.kt
M navigation/navigation-common/src/main/res-public/values/public_attrs.xml
M navigation/navigation-common/src/main/res/values/attrs.xml
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavInflater.kt
ap...@google.com <ap...@google.com> #114
Branch: androidx-main
commit 17366f6b6a267b39bcf9fab5f3b4b1dec793e748
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue Apr 06 17:08:18 2021
Upgrade Navigation to use Activity 1.2.2, ToT Fragments
In preparation for navigation-fragment using the
multiple back stacks APIs added in the latest
version of Fragments, update the dependencies in
Navigation to use the latest stable Activity release
(1.2.2) and the tip-of-tree version of Fragments.
By necessity, this updates usages of deprecated
Fragment APIs (namely, startIntentSenderForResult()
and onActivityResult) to their replacements.
Relnote: "Navigation Runtime now depends on
[Activity `1.2.2`](/jetpack/androidx/releases/activity#1.2.2)."
Test: existing navigation-fragment tests still pass
BUG: 80029773
Change-Id: Iad6bec4af04c4ad748277fe7f99b87c7f5698ec6
M navigation/navigation-dynamic-features-fragment/src/main/java/androidx/navigation/dynamicfeatures/fragment/ui/AbstractProgressFragment.kt
M navigation/navigation-fragment/build.gradle
M navigation/navigation-runtime/build.gradle
ap...@google.com <ap...@google.com> #115
Branch: androidx-main
commit 95261600fd07bdfc22af2cf64c3ef58034192a1d
Author: Ian Lake <ilake@google.com>
Date: Mon Apr 12 13:57:58 2021
Add saveState parameter to popBackStack()
In addition to being able to add the
popUpToSaveState value to NavOptions, it
should also be possible to save state when
manually popping the stack via popBackStack().
Relnote: N/A
Test: ./gradlew checkApi
BUG: 80029773
Change-Id: I5517c9e86cac63266c4742c67415afdc026d8c34
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #116
Branch: androidx-main
commit bbb3729f948ca4995b15296a40cd9db6353088ee
Author: Ian Lake <ilake@google.com>
Date: Tue Apr 13 11:30:48 2021
Save the NavBackStackEntry state
When using the saveState flag on the pop operation,
all of the state associated with the popped destinations
should be saved. That includes both the saved
instance state (calling saveState() once the destination
is stopped) as well as non-config state in the form of
any ViewModels associated with the destination.
This involves associating that saved state with
the ID of the destination you've popped up to
as well as ensuring that ViewModels are not cleared
as part of the pop (but are still cleared when the
hosting ViewModelStore is cleared).
Relnote: N/A
Test: new NavBackStackEntryTest tests pass
BUG: 80029773
Change-Id: Ia5a35ec712cf5a58c3c310999bacb3c87e8cc522
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntryState.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #117
Branch: androidx-main
commit fde7cd4bf112f37061e036cfdd8c44c3af98ee77
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 21 15:31:38 2021
Decouple NavBackStackEntry from NavControllerViewModel
Rather than having a compile time dependency
on the concrete NavControllerViewModel class
in NavBackStackEntry, create a new interface
that NavBackStackEntry can depend on.
Test: NavBackStackEntry tests still pass
BUG: 80029773
Change-Id: I4345c5d93359b8f0d0c21d68c12912f3ea16112b
M navigation/navigation-common/build.gradle
A navigation/navigation-common/src/main/java/androidx/navigation/NavViewModelStoreProvider.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavControllerViewModel.kt
ap...@google.com <ap...@google.com> #118
Branch: androidx-main
commit f57cd370acf055e004eb4bfb1e95904624a83dca
Author: Ian Lake <ilake@google.com>
Date: Wed Apr 21 15:52:15 2021
Move NavBackStackEntry to navigation-common
Move NavBackStackEntry to live in the same
artifact as Navigator.
Relnote: N/A
Test: existing tests still pass
BUG: 80029773
Change-Id: I84167184c3356e0c27cd61ae191e5ea995d40d26
M navigation/navigation-common/api/api_lint.ignore
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/build.gradle
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
A navigation/navigation-runtime/api/current.ignore
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
A navigation/navigation-runtime/api/restricted_current.ignore
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/build.gradle
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavBackStackEntryTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntryState.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #119
Branch: androidx-main
commit 4ab8db7d2ca746a38bdde67e3ef495e83ddb0aa5
Author: Ian Lake <ilake@google.com>
Date: Fri Apr 23 14:25:17 2021
Build connection between NavController and Navigator state
Introduce the NavigatorState class. This state is owned
by the NavController, but is specifically set at the
Navigator level. Besides giving the Navigator read access
to the set of destinations on its own back stack, it
also encapsulates the add and pop operations in such
a way as to allow the Navigator to push changes back
to the NavController.
To allow for testing of a Navigator independently
of a NavController, a TestNavigatorState, provides
an alternate implementation specifically for testing
purposes.
Relnote: N/A
Test: updated and existing tests pass
BUG: 80029773
Change-Id: Id2afe4c8d428894826d0391173a162cf8c977328
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
A navigation/navigation-common/src/main/java/androidx/navigation/NavigatorState.kt
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/BaseNavControllerTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/api/current.txt
M navigation/navigation-testing/api/public_plus_experimental_current.txt
M navigation/navigation-testing/api/restricted_current.txt
M navigation/navigation-testing/build.gradle
A navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/build.gradle
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
M testutils/testutils-navigation/src/test/java/androidx/testutils/TestNavigatorTest.kt
ap...@google.com <ap...@google.com> #120
Branch: androidx-main
commit ff14ae5dd8a1767597622e9d2c5deb27078b8a01
Author: Ian Lake <ilake@google.com>
Date: Thu Apr 22 13:12:35 2021
Add attach API to Navigators
Rather than doing initialization in the
Navigator's init, give Navigators an initial
callback on when the NavController has started
using the Navigator.
This also changes the behavior such that replacing
a Navigator after the NavController has restored
its state results in an error.
Relnote: N/A
Test: existing tests pass
BUG: 80029773
Change-Id: I2f2b8aac0541d4e084cb4b53175b6a0195a4cc59
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavigatorProvider.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/DialogFragmentNavigator.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #121
Branch: androidx-main
commit 5c911ea7cbe26bff5091a2d0b2f9b126678eb04b
Author: Ian Lake <ilake@google.com>
Date: Mon Apr 26 17:04:31 2021
Introduce multiple back stack compatible Navigator APIs
The current Navigator APIs operated on a single
destination at a time, which made it impossible to
coordinate a set of navigate() calls or a popBackStack()
that would pop multiple destinations at once - both
of which are required to fully support the saving
and restoring of state needed to support
multiple back stacks.
In addition to supporting batch operations, these
new Navigator APIs give the Navigator direct access
to the NavBackStackEntry instance that is being
navigated to. This allows the new APIs to be
backward compatible - translating calls to the new
APIs back into the old API internally while still
allowing a Navigator to fully switch over to the
new APIs (and just not call the superclass
implementation).
The NavController was fully rebuilt to only call
the new APIs while continuing to work with
existing Navigator implementations without any
changes. The previous temporary solution required
for TestNavigator (calling the NavigatorState APIs
from the old navigate/popBackStack() methods) was
removed entirely as the default implementations
correctly update the NavigatorState.
Relnote: N/A
BUG: 80029773
Test: existing tests for all Navigators pass
Change-Id: Ia1ff09a4b76f15a35d6a9c520687033d6f1565a7
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/Navigator.kt
M navigation/navigation-compose/api/current.txt
M navigation/navigation-compose/api/public_plus_experimental_current.txt
M navigation/navigation-compose/api/restricted_current.txt
M navigation/navigation-dynamic-features-runtime/api/current.ignore
M navigation/navigation-dynamic-features-runtime/api/current.txt
M navigation/navigation-dynamic-features-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-dynamic-features-runtime/api/restricted_current.ignore
M navigation/navigation-dynamic-features-runtime/api/restricted_current.txt
M navigation/navigation-fragment/api/current.ignore
M navigation/navigation-fragment/api/current.txt
M navigation/navigation-fragment/api/public_plus_experimental_current.txt
M navigation/navigation-fragment/api/restricted_current.ignore
M navigation/navigation-fragment/api/restricted_current.txt
M navigation/navigation-runtime/api/current.ignore
M navigation/navigation-runtime/api/current.txt
M navigation/navigation-runtime/api/public_plus_experimental_current.txt
M navigation/navigation-runtime/api/restricted_current.ignore
M navigation/navigation-runtime/api/restricted_current.txt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorProvider.kt
M testutils/testutils-navigation/src/main/java/androidx/testutils/TestNavigator.kt
M testutils/testutils-navigation/src/test/java/androidx/testutils/TestNavigatorTest.kt
ap...@google.com <ap...@google.com> #122
Branch: androidx-main
commit cf47135438d553629daa94c42f3d37502eb2fba7
Author: Ian Lake <ilake@google.com>
Date: Tue Apr 27 17:50:04 2021
Convert ComposeNavigator+NavHost to new Navigator APIs
Utilize the new Navigator APIs and specifically
the NavigatorState within ComposeNavigator and
NavHost. This ensures a single source of truth from
the NavController to the NavigatorState to the
NavHost.
Due to the use of DisposableEffect, the NavHost
composes at least once before the graph is set
(and therefore before the NavigatorState is available).
This logic is encapsulated within ComposeNavigator
such that the NavHost can always assume the
back stack is available.
The ComposeNavigatorTest suite was redone to
focus on the logic that ComposeNavigator now contains
around the back stack, thus avoiding duplicating the
logic already tested in the base NavController and
Navigator tests.
Relnote: N/A
BUG: 80029773
Test: updated ComposeNavigatorTest tests pass
Change-Id: I0698d2a5e0e7bf8379bab8636f54882d33a464b3
M navigation/navigation-compose/api/current.txt
M navigation/navigation-compose/api/public_plus_experimental_current.txt
M navigation/navigation-compose/api/restricted_current.txt
M navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/ComposeNavigatorTest.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/ComposeNavigator.kt
M navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
ap...@google.com <ap...@google.com> #123
Branch: androidx-main
commit 6bd5c055e363ec648db8e1c9afa781935d6542ae
Author: Ian Lake <ilake@google.com>
Date: Thu Apr 29 15:17:37 2021
Add support for restoring state
Hook up the restoreState to calls to navigate(),
allowing the NavBackStackEntry state to be restored
back to the state it was originally saved in.
This means that even if the underlying Navigator
does not participate in saving state, the
NavController will still navigate() to the same set
of destinations with the same NavBackStackEntry state
when the saveState/restoreState APIs are used.
BUG: 80029773
Test: New NavControllerTest tests pass
Change-Id: I4b69f189314e6edc998391c29c35ab1c4d35fa2c
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #124
Branch: androidx-main
commit b4edb9532c81542cdc62fb384d9bfb06bfcb73e0
Author: Ian Lake <ilake@google.com>
Date: Mon May 03 16:40:01 2021
Fix popUpTo+restoreState when inclusive=false
In cases where you use popUpTo and inclusive=false,
the back stack state needs to be associated not only
with the destination you've directly passed to
popUpTo, but also with the destination that was
actually popped.
In addition, this state also needs to be associated
with the parents of those destinations specifically
when the destination is the start destination of the
graph so that navigating to the graph itself is
treated the same as navigating to the start destination
when it comes to restoring state.
E.g., let's say you have three nested graphs: A, B, and C,
each with a respective start destination of A', B', and
C'. As per the Principles of Navigation, you should
always keep the start destination of your graph (A') on
the back stack. Therefore, the much more common case
is to use popUpTo(A') with inclusive=false when navigating
to B or C (or back to A). By adjusting the logic around
saving the state, navigating from B to C will save the
state of B to B, even though the popUpTo was set to A'.
Similarly, the state of A' (and notably, any destinations
stacked on top of it) will be restored when you navigate
to A with restoreState=true.
With this change, the BottomBarNavDemo for Navigation Compose
was updated to use the new restoreState and saveState flags
and now the state of the Scrollable destination is properly
saved and restored when you swap between the Scrollable
and Dashboard tabs by tapping on the bottom nav.
BUG: 80029773
Test: new NavControllerTest tests passes
Change-Id: I4ce337d269fe0db5ee424d5f47e64868c5a1a3a9
M navigation/navigation-compose/integration-tests/navigation-demos/src/main/java/androidx/navigation/compose/demos/BottomBarNavDemo.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
ap...@google.com <ap...@google.com> #125
Branch: androidx-main
commit ff325dad7ef332217b2cb9ae1428d24bb10fbc3b
Author: Ian Lake <ilake@google.com>
Date: Wed May 05 14:55:58 2021
Ensure TestNavigatorState updates the Lifecycle correctly
The TestNavigatorState serves the role of
"NavController" when building isolated tests
for a Navigator. As such, it owns the logic for
updating and maintaining the state of each
NavBackStackEntry added to it.
As such, the TestNavigatorState now updates
the Lifecycle of each NavBackStackEntry
as it is added and popped from the state's
back stack, mirroring the behavior of
NavController.
Relnote: N/A
Test: new TestNavigatorStateTest
BUG: 80029773
Change-Id: I92b09989a7d9bc63d52747eef40f04d75a43cc0d
M navigation/navigation-testing/api/current.txt
M navigation/navigation-testing/api/public_plus_experimental_current.txt
M navigation/navigation-testing/api/restricted_current.txt
A navigation/navigation-testing/src/androidTest/java/androidx/navigation/testing/TestNavigatorStateTest.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
M testutils/testutils-navigation/build.gradle
M testutils/testutils-navigation/src/test/java/androidx/testutils/TestNavigatorTest.kt
ap...@google.com <ap...@google.com> #126
Branch: androidx-main
commit ce44b5214ef9ce0a2b478298554c98854d27f1b6
Author: Ian Lake <ilake@google.com>
Date: Thu May 06 15:04:48 2021
Make NavBackStackEntry's ID public
Rather than rely on each Navigator to
construct its own idea of a unique
key for a NavBackStackEntry (e.g., using
its position in the back stack or the
destination ID), we'd like to encourage
using the unique ID of the NavBackStackEntry.
Relnote: "The unique ID of a `NavBackStackEntry`
is now exposed as part of its public API."
Test: ./gradlew checkApi
BUG: 80029773
Change-Id: Ie033a9056cead23ef9bcff1c52e67172c459b0f2
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/src/main/java/androidx/navigation/NavBackStackEntry.kt
M navigation/navigation-common/src/main/java/androidx/navigation/NavViewModelStoreProvider.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerViewModelTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavBackStackEntryState.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavControllerViewModel.kt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #127
Branch: androidx-main
commit 4485a5102b93d0551db020bdbf1f78baa6b47b3b
Author: Ian Lake <ilake@google.com>
Date: Thu May 06 21:55:58 2021
Convert FragmentNavigator to Navigator v2 APIs
Convert FragmentNavigator and its subclass,
DynamicFragmentNavigator, to the Navigator v2 APIs.
Relnote: N/A
BUG: 80029773
Test: updated tests pass
Change-Id: I983269785ad2b5c9e74bd6b52cfee5d5698b0fa4
M navigation/navigation-dynamic-features-fragment/src/main/java/androidx/navigation/dynamicfeatures/fragment/DynamicFragmentNavigator.kt
M navigation/navigation-fragment/api/current.ignore
M navigation/navigation-fragment/api/current.txt
M navigation/navigation-fragment/api/public_plus_experimental_current.txt
M navigation/navigation-fragment/api/restricted_current.ignore
M navigation/navigation-fragment/api/restricted_current.txt
M navigation/navigation-fragment/build.gradle
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
ap...@google.com <ap...@google.com> #128
Branch: androidx-main
commit d4f6ac6d46cec08ee9a11b44955da4c69ec6aec3
Author: Ian Lake <ilake@google.com>
Date: Thu May 06 16:51:03 2021
Convert NavGraphNavigator to Navigator v2 APIs
Convert NavGraphNavigator and its subclass,
DynamicGraphNavigator, to the Navigation v2 APIs.
Relnote: N/A
BUG: 80029773
Test: updated tests pass
Change-Id: I735b94efb92a0275c931af30c4a669be388f9186
M navigation/navigation-common/api/current.txt
M navigation/navigation-common/api/public_plus_experimental_current.txt
M navigation/navigation-common/api/restricted_current.txt
M navigation/navigation-common/build.gradle
M navigation/navigation-common/src/main/java/androidx/navigation/NavGraphNavigator.kt
M navigation/navigation-common/src/test/java/androidx/navigation/NavGraphNavigatorTest.kt
M navigation/navigation-dynamic-features-runtime/build.gradle
M navigation/navigation-dynamic-features-runtime/src/main/java/androidx/navigation/dynamicfeatures/DynamicGraphNavigator.kt
M navigation/navigation-dynamic-features-runtime/src/main/java/androidx/navigation/dynamicfeatures/DynamicInstallManager.kt
M navigation/navigation-dynamic-features-runtime/src/test/java/androidx/navigation/dynamicfeatures/DynamicNavGraphTest.kt
ap...@google.com <ap...@google.com> #129
Branch: androidx-main
commit 5236d8017f82fcf8f193f7ab1bced55d485508e5
Author: Ian Lake <ilake@google.com>
Date: Fri May 07 11:43:37 2021
Connect Navigation and FragmentManager's state save/restore
Update FragmentNavigator to correctly save and restore
the Fragment's state when the NavController uses the
restoreState and saveState APIs.
To enable testing the save/restore separately from
NavController, this added a new restoreBackStackEntry()
API to TestNavigatorState.
Relnote: N/A
Test: new FragmentNavigatorTest tests pass
BUG: 80029773
Change-Id: I4ac261ab2195e276c93ffd63152fe2bcefa3651a
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
M navigation/navigation-testing/api/current.txt
M navigation/navigation-testing/api/public_plus_experimental_current.txt
M navigation/navigation-testing/api/restricted_current.txt
M navigation/navigation-testing/src/main/java/androidx/navigation/testing/TestNavigatorState.kt
ap...@google.com <ap...@google.com> #130
Branch: androidx-main
commit 19cf489673a84b939bc676ba247d983f07c9959a
Author: Ian Lake <ilake@google.com>
Date: Sun May 09 15:39:23 2021
Add restoreBackStack records to the back stack
Delegate to BackStackRecord's generateOps call
in restoreBackStackState() to ensure that
restoreBackStack() results in the exact same
behavior as manually executing each
FragmentTransactions.
Importantly, this ensures that each record
is added to the FragmentManager's back stack.
Test: updated SaveRestoreBackStackTest tests pass
BUG: 80029773
Change-Id: I9f2484c9244f4cca20745623184c695ca842d3d7
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SaveRestoreBackStackTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
bo...@gmail.com <bo...@gmail.com> #131
A question: with all due respect, are these automatic comments really necessary or useful? I'd like to keep my "star" on this issue, and know when it will be fixed. But the noise doesn't help. Thanks a lot!
il...@google.com <il...@google.com> #132
Re #131 - yes, they are necessary. As stated multiple times and seen in the hotlists this bug is associated with, this will be fixed with Fragment 1.4.0-alpha01 and Navigation 2.4.0-alpha01, so if you're looking for only an update on when those are released and not for updates on the progress leading up to that point, you can use the
ap...@google.com <ap...@google.com> #133
Branch: androidx-main
commit 98e0bfd1a040eb1f9f0755f0152a5f30195ea3df
Author: Ian Lake <ilake@google.com>
Date: Sun May 09 16:35:27 2021
Fix restoreBackStack() when saveBackStack() is pending
Any FragmentTransaction happens as separate stages:
1) Generate the set of transactions that need to be applied
2) Execute the transactions
3) Move the Fragments to their expected state
When calling saveBackStack() followed by restoreBackStack()
without any intervening time or specifically calls to
executePendingTransactions(), step 1 is applied to both
the saveBackStack() and restoreBackStack() commands without
step 2 and 3 actually being executed yet.
This means that saveBackStack() needs to capture enough
state while executing step 1 such that the
restoreBackStack() has enough information to generate
the proper set of FragmentTransactions. As such, the
previous approach of using an "execute runnable"
(which would only run in step 2) is not sufficient.
Instead, saveBackStack() now creates a deep copy of
the full BackStackRecord and immediately saves its
state as part of step 1, thus ensuring that it is already
available when step 1 for restoreBackStack() is available.
On the flip side, because step 2 and 3 haven't been
executed yet when restoreBackStack()'s step 1 executes,
the Fragments that would not have had their state saved
and been destroyed, meaning that BackStackState must
now consider the case where the Fragment still exists
prior to trying to find the saved state of the previously
destroyed fragment.
Test: new SaveRestoreBackStackTest test passes
BUG: 80029773
Change-Id: I147cc168d712d49f7533f51e56776506b3c7698c
M fragment/fragment/src/androidTest/java/androidx/fragment/app/SaveRestoreBackStackTest.kt
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackRecord.java
M fragment/fragment/src/main/java/androidx/fragment/app/BackStackState.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentManager.java
M fragment/fragment/src/main/java/androidx/fragment/app/FragmentTransaction.java
ap...@google.com <ap...@google.com> #134
Branch: androidx-main
commit 62c022f23c6bcd52fa94150eba8ef3e6c09e742b
Author: Ian Lake <ilake@google.com>
Date: Sun May 09 16:49:28 2021
Enable saving state in NavigationUI by default
Ensure that any usages of NavigationUI's
onNavDestinationSelected() API or APIs that
use it internally (such as the
setupWithNavController() methods for
NavigationView and BottomNavigationView)
use the popUpTo API with saveState = true
and setRestoreState(true) to ensure that
any popped destinations have their state saved
and restored when you navigate back to that
destination (either via selecting the
same menu item again or manually using the
setRestoreState(true) API.
This means that BottomNavigationView and
NavigationView users will automatically get
multiple back stack support just by using
NavigationUI and upgrading their version
of Navigation to one that supports multiple
back stacks.
Relnote: "The `NavigationUI` methods of
`onNavDestinationSelected()`,
`BottomNavigationView.setupWithNavController()` and
`NavigationView.setupWithNavController()` now
automatically save and restore the state of
popped destinations, enabling automatic support
for multiple back stacks."
Test: tested in navigation-integration-tests testapp
BUG: 80029773
Change-Id: Ie07ca3089faca25e56e58293b49f32b795e1f30a
M navigation/navigation-ui/src/main/java/androidx/navigation/ui/NavigationUI.kt
ap...@google.com <ap...@google.com> #135
Branch: androidx-main
commit a55cf6688ef4c844adb5718331d367a8ceceefe6
Author: Ian Lake <ilake@google.com>
Date: Mon May 10 13:12:16 2021
Re-enable launchSingleTop in BottomBarNavDemo
When returning to the first item, we still
only want one instance - this is the exact
use case for launchSingleTop.
Test: manual testing of the demo app
BUG: 80029773
Change-Id: If71dfec3986c70e064c28535944118a93c5f7974
M navigation/navigation-compose/integration-tests/navigation-demos/src/main/java/androidx/navigation/compose/demos/BottomBarNavDemo.kt
il...@google.com <il...@google.com> #136
With these last changes and snapshot build #7351514, we've completed all of the required changes to support multiple back stacks in:
-
Fragments (i.e., without using the Navigation Component at all): this is an opt in change by using the new FragmentManager APIs of
saveBackStack
andrestoreBackStack
. -
The core Navigation Runtime: adds opt-in new
NavOptions
methods forrestoreState
andsaveState
and a new overload ofpopBackStack()
that also accepts asaveState
boolean (defaults to false). -
Navigation with Fragments: the
FragmentNavigator
now utilizes the newNavigator
APIs to properly translate the Navigation Runtime APIs into the Fragment APIs by using the Navigation Runtime APIs. -
NavigationUI
: TheonNavDestinationSelected()
,BottomNavigationView.setupWithNavController()
andNavigationView.setupWithNavController()
now use the newrestoreState
andsaveState
NavOptions
by default whenever they would pop the back stack. This means that every app using thoseNavigationUI
APIs will get multiple back stacks without any code changes on their part after upgrading the Navigation 2.4.0-alpha01. -
Navigation Compose:
NavHost
and theComposeNavigator
have also been updated to support saving and restoring the state by using the Navigation Runtime APIs. An example of using therestoreState
+saveState
APIs with a bottom nav can be seen in the .BottomBarNavDemo
All of these changes will be available in the upcoming Fragment 1.4.0-alpha01 and Navigation 2.4.0-alpha01 releases. (Note that Navigation Compose versioning has been merged into the rest of Navigation as per
That being said:
- there's a lot more documentation and samples that need to be updated. We'll be tackling as much of this as possible between now and the alpha01 release.
- As you may have seen, there's been a huge number of changes needed to make this happen across all levels. As such, please file separate bugs as you discover any edge cases that we need to handle and we'll make sure those changes are addressed in an alpha02 release.
I'd like to thank you for your patience and respectfulness in not spamming this issue with comments.
al...@gmail.com <al...@gmail.com> #137
so...@gmail.com <so...@gmail.com> #138
em...@gmail.com <em...@gmail.com> #139
ga...@gmail.com <ga...@gmail.com> #140
sh...@gmail.com <sh...@gmail.com> #141
ar...@gmail.com <ar...@gmail.com> #142
bo...@gmail.com <bo...@gmail.com> #143
to...@appsfactory.de <to...@appsfactory.de> #144
mi...@gmail.com <mi...@gmail.com> #145
With the new version, how can I navigate to the destination in another graph? Let's say, I would want to navigate from Title to UserProfile screen in the NavigationAdvancedSample app.
Calling navigate() throws an exception "Navigation action/destination xx cannot be found from the current destination". Is it supported by 2.4.0-alpha01 release?
th...@gmail.com <th...@gmail.com> #146
il...@gmail.com <il...@gmail.com> #147
I'm also facing a couple of new issues. The first one is related to a transition crash:
java.lang.IndexOutOfBoundsException: Index: 10, Size: 10
at java.util.ArrayList.get(ArrayList.java:437)
at androidx.fragment.app.FragmentTransitionImpl.setNameOverridesReordered(FragmentTransitionImpl.java:182)
at androidx.fragment.app.DefaultSpecialEffectsController.startTransitions(DefaultSpecialEffectsController.java:665)
at androidx.fragment.app.DefaultSpecialEffectsController.executeOperations(DefaultSpecialEffectsController.java:114)
at androidx.fragment.app.SpecialEffectsController.executePendingOperations(SpecialEffectsController.java:294)
at androidx.fragment.app.Fragment$3.run(Fragment.java:2760)
at android.os.Handler.handleCallback(Handler.java:938)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:223)
at android.app.ActivityThread.main(ActivityThread.java:7656)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:592)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:947)
MaterialContainerTransform
is used here.
And the second one is related to a significant performance drop. It seems like the app is almost freezing for a fraction of a second on the bottom navigation stacks swap.
br...@gmail.com <br...@gmail.com> #148
java.lang.IllegalArgumentException:
at androidx.fragment.app.FragmentManager.saveBackStackState (FragmentManager.java:2052)
at androidx.fragment.app.FragmentManager$SaveBackStackState.generateOps (FragmentManager.java:3172)
at androidx.fragment.app.FragmentManager.generateOpsForPendingActions (FragmentManager.java:1953)
at androidx.fragment.app.FragmentManager.execPendingActions (FragmentManager.java:1643)
at androidx.fragment.app.FragmentManager$4.run (FragmentManager.java:480)
at android.os.Handler.handleCallback (Handler.java:883)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loop (Looper.java:241)
at android.app.ActivityThread.main (ActivityThread.java:7617)
at java.lang.reflect.Method.invoke (Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:941)
I appreciate the work you guys are putting on this, thanks ;)
il...@google.com <il...@google.com> #149
Please always file a new issue instead of commenting on already marked as Fixed bugs.
mi...@iotashome.com <mi...@iotashome.com> #150
il...@google.com <il...@google.com> #151
Re #150 - no, please always file a new issue. That way each issue can be triaged separately for the appropriate release and deduped against one another.
dh...@bacancy.com <dh...@bacancy.com> #152
lk...@gmail.com <lk...@gmail.com> #153
ph...@gmail.com <ph...@gmail.com> #154
sa...@google.com <sa...@google.com> #155
Re #154: Please file a separate issue so we can more appropriately track your issue.
ph...@gmail.com <ph...@gmail.com> #156
am...@gmail.com <am...@gmail.com> #157
What if I don't want to use popUpTo() and want to keep my bottomNavBar stack growing?
Is it too crazy to ask for a backstack in each destination? - The destination itself will have its own backstack without the need to save/restore. Soon as the destination is visible/active it will query its internal Backstack and present the proper child screen it host. That will make a lot easier to design Apps like Instagram, which is probably the reason why many of us are here.
Description
- scroll position should be maintained between tabs
- pressing the tab again should reset its' backstack and scroll
- pressing back should go back in the current tab's backstack and then exit the app (it should not switch between tabs)
- each tab should have it's own backstack
(I am not sure which parts of this are already implemented, but the scroll/backstack support isn't there)."