Fixed
Status Update
Comments
da...@sucharda.cz <da...@sucharda.cz> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit ae09f6e6686b32c5677c086d51d5737553e2aeb9
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1373433
Branch: androidx-master-dev
commit ae09f6e6686b32c5677c086d51d5737553e2aeb9
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
jb...@google.com <jb...@google.com> #3
We've fixed this internally and are preparing a DrawerLayout 1.1.1
release with this fix.
da...@sucharda.cz <da...@sucharda.cz> #4
Project: platform/frameworks/support
Branch: snap-temp-L48600000649720827
commit 6e863d72d89137a408907be4c44f5444b51f8dab
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1374836
Branch: snap-temp-L48600000649720827
commit 6e863d72d89137a408907be4c44f5444b51f8dab
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
da...@sucharda.cz <da...@sucharda.cz> #5
Project: platform/frameworks/support
Branch: snap-temp-L11100000649726887
commit 4b1419f8d1c41233b1af357a178c1eb6e71e3fb0
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1374876
Branch: snap-temp-L11100000649726887
commit 4b1419f8d1c41233b1af357a178c1eb6e71e3fb0
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
jb...@google.com <jb...@google.com>
cl...@google.com <cl...@google.com> #6
Project: platform/frameworks/support
Branch: snap-temp-L37200000649809909
commit 8e12fa9761f7d1ad254bd278392ed2020de2cec1
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1375018
Branch: snap-temp-L37200000649809909
commit 8e12fa9761f7d1ad254bd278392ed2020de2cec1
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
ap...@google.com <ap...@google.com> #7
Project: platform/frameworks/support
Branch: snap-temp-L59700000649811929
commit 8c0814d1467e02e617f002b61b09a5737a3a1e94
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1375020
Branch: snap-temp-L59700000649811929
commit 8c0814d1467e02e617f002b61b09a5737a3a1e94
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
pr...@google.com <pr...@google.com> #8
Project: platform/frameworks/support
Branch: snap-temp-L27600000649911717
commit 63fcaff3662ea1236d84e644362f35b7618b56dd
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
https://android-review.googlesource.com/1375064
Branch: snap-temp-L27600000649911717
commit 63fcaff3662ea1236d84e644362f35b7618b56dd
Author: Ian Lake <ilake@google.com>
Date: Mon Jul 27 17:51:04 2020
Ensure open() and close() always work
As per the Javadoc on LOCK_MODE_LOCKED_CLOSED
and LOCK_MODE_LOCKED_OPEN, the app should
still be able to open() and close() the drawer
programmatically.
This change aligns open() and close() with
openDrawer() and closeDrawer() to allow
programmatic usage no matter what LOCK_MODE
is used.
Test: tested in sample app
BUG: 162253907
Change-Id: I74f2f7ea5ff8ce06bfcfeff09aedd980f385ffc7
(cherry picked from commit ae09f6e6686b32c5677c086d51d5737553e2aeb9)
M drawerlayout/drawerlayout/src/main/java/androidx/drawerlayout/widget/DrawerLayout.java
Description
Component used: Navigation
Version used: 2.5.1 and 2.5.2
Last known working version: 2.3.5
Devices/Android versions reproduced on: Huawei P20 Light / AN 9 (EMUI 9.1.0)
So our navigation is kinda complex so I will try to simplify the configuration. If there is a nested graph with arguments which cannot be null (and no default value is supplied) and
popUpTo
is used to remove nested graph during destination (nested) navigation it tries to recreate nested graph as a parent for the destination being navigated to.So now if the navigation is triggered like this:
It will pop fragments from back stack, but it will not change parent for
ChildFragment2
which will be set tochildNavGraph
and since it is not in the back stack anymore it will try to recreate it with default values. ButargumentLong
is not nullable and has no default value so it will crash:Note: Interesting thing is that it does not crash with non-nullable String argument for some reason (ah I see, it is because String NavType is nullable by default:
StringType: NavType<String?>
vsLongType: NavType<Long>
).Possible fixes for us:
popUpTo
to pop parent (navGraph) of a Fragment (node) from XML but usepopBackStack
from code instead.argumentLong
.Basically I am not sure if this an intended behavior or a bug. Gonna mark it as a bug because it worked in 2.3.5. I understand that Destination should have a parent but what is the reason to create a parent that does not exist and will never be displayed in this case, since it was already poped and thus it should not be displayed to the user.
At the moment two solutions come to mind:
LongType
and other types nullable same asStringType
. Again not sure if this can be done and it probably is not a proper solution (change).There might of course be other solutions that I cannot see.
Thank you for your time and help.