Status Update
Comments
jb...@google.com <jb...@google.com> #2
I tried applying this in a trial project and found that there is a lot of room for improvement. I tried improving it as much as I could based on a project I'm working on. It should scale as much as it could and be reusable in other projects.
I have attached the project in this comment. The package structure might be confusing as it is not separated by modules.
You can see there 2 MainScreen
. MainScreen
is implemented with my Navigation Structure (Not working due to no non-reified api). MainScreenB
is implemented with manually hard-coded navigation and partially using MainNavigation
for BottomNavigation
.
There is also Screen3RootA
and Screen3RootB
which is implemented in the same fashion but Screen3RootB
is implemented manually using DestinationComposable
.
You might notice there are reified functions inside the companion object
of the classes which is supposedly in the class directly but I tried hacking my way through the reified navigation apis
for demonstration purposes.
There is one weird bug when navigating to Screen2
from Screen3
then tapping Screen2
in the BottomNavigation
but it could be mitigated by returning from the function call if the tab is currently selected.
You may find the Classes and Interfaces I used in navigation
package
ti...@google.com <ti...@google.com> #3
The requests needed here are also inlined with
il...@gmail.com <il...@gmail.com> #4
I noticed some inconsistencies between MainScreen
and MainScreenB
so I did some adjustments.
ti...@google.com <ti...@google.com> #5
I did something illegal and Suppressed RestrictedApi
Lint Checks
Now the whole ComposeNavigation
is working. I added KSerializer<T>
as a parameter on DestinationComposable
so that I could get the DestinationObject
through NavBackStackEntry.toRoute()
under the hood. Adding the KSerializer
as a parameter also helps in making sure that the Destination
is Serializeable
.
I just can't get around the bug wherein Screen2 doesn't retain its arguments and creates a new one including the viewModel. I'm not sure if it's an intended feature or not since it is the startDestination of the nestedGraph. I can probably get around it by providing a separate savedStateHandle Key. I'll just create a new issue with a trimmed down version just in case.
ti...@google.com <ti...@google.com> #6
Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <
Link:
Add non-reified overloads for toRoute
Expand for full commit details
Add non-reified overloads for toRoute
NavBackStackEntry.toRoute and SavedStateHandle.toRoute overloads that take a KClass<*> as route and returns T.
Test: existing tests pass
Bug: 366291612
Relnote: "Added non-reified overload for NavBackStackEntry.toRoute and SavedStateHandle.toRoute that takes in a KClass<*> as route"
Change-Id: Ic1bf09bdd59e0d96db7edb89276ac31a977d6602
Files:
- M
navigation/navigation-common/api/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/SavedStateHandle.kt
Hash: 2c4a084bdbe543ded4b6d203c6636fc825e7e301
Date: Wed Nov 06 16:22:20 2024
al...@gmail.com <al...@gmail.com> #7
I think its also better to add non-reified dialog
. I might have a use case for it soon.
ho...@gmail.com <ho...@gmail.com> #8
Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <
Link:
Add non-reified overload for composable and navigation
Expand for full commit details
Add non-reified overload for composable and navigation
Overloads that take a KClass<*> as the route for composable destination and nested graph
Test: existing tests
Bug: 366291612
Relnote: "Added overloads for NavGraphBuilder.composable and NavGraphBuilder.navigation that takes a KClass<*> as the route."
Change-Id: If56a553a4d2608a5eb059ea684e566a4feae955b
Files:
- M
navigation/navigation-compose/api/current.txt
- M
navigation/navigation-compose/api/restricted_current.txt
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavGraphBuilder.kt
Hash: 9cd16b12e255b5e7ad3c8cc7fca08dc63faf9e52
Date: Wed Nov 27 14:08:15 2024
es...@gmail.com <es...@gmail.com> #9
Fixed internally and available in navigation-2.9.0-alpha04
pr...@gmail.com <pr...@gmail.com> #10
Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <
Link:
Add non-reified NavGraphBuilder.dialog safe args api
Expand for full commit details
Add non-reified NavGraphBuilder.dialog safe args api
Test: ./gradlew navigation:navigation-compose:cC
Bug: 366291612
Relnote: "Added non-reified NavGraphBuilder.dialog API to create a composable dialog with KClass<T>"
Change-Id: Iba4ee26b906c09e7ec47b7e940cf689788c117e8
Files:
- M
navigation/navigation-compose/api/current.txt
- M
navigation/navigation-compose/api/restricted_current.txt
- M
navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavGraphBuilderTest.kt
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavGraphBuilder.kt
Hash: f96150f5be412aa3d660efd83ba07d439e1da211
Date: Wed Dec 04 13:51:14 2024
al...@gmail.com <al...@gmail.com> #11
Project: platform/frameworks/support
Branch: androidx-main
Author: Clara Fok <
Link:
Update non-reified composable and navigation
Expand for full commit details
Update non-reified composable and navigation
Added <T : Any> type parameter to the API
Test: ./gradlew navigation:navigation-compose:cC
Bug: 366291612
Relnote: "Non-reified composable and navigation API expects route from KClass<T> instead of KClass<*>"
Change-Id: Icd47da4061103edd8462a729ae168e724d833d36
Files:
- M
navigation/navigation-compose/api/current.txt
- M
navigation/navigation-compose/api/restricted_current.txt
- M
navigation/navigation-compose/src/androidTest/java/androidx/navigation/compose/NavGraphBuilderTest.kt
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavGraphBuilder.kt
Hash: 653f2ea988ff3744ecf3de08c3221c4ee8c64917
Date: Wed Dec 04 13:41:46 2024
cl...@gmail.com <cl...@gmail.com> #12
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-common:2.9.0-alpha04
androidx.navigation:navigation-compose:2.9.0-alpha04
ap...@google.com <ap...@google.com> #13
Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <
Link:
Stop incorrect scaling animation when using NavHost
Expand for full commit details
Stop incorrect scaling animation when using NavHost
There is a case where if you can trigger a navigate call right before the
LaunchEffect that is responsible for managing the end of the
AnimatedContent's transition is called, you will get an incorrect scale
animation.
The reason for this is that the call to navigate adds the proper entries
to the visibleEntries list and then the LaunchedEffect immediately
remove it. Then when the AnimatedContent attempts to find this removed
entry it is not there and AnimatedContent thinks it is animated from
nothing and just scales from a blank screen.
Since this is an interrupt case the the AnimatedContent has not actually
finsihed with transition, we should not be hitting the `LaunchedEffect`
and marking the transition complete at all, but that needs to be
addressed by the Animation library so this change provides a workaround
in the mean time that just keeps from incorrectly marking the visible
entry's transition as complete.
RelNote: "Added a workaround to fix an issue that caused an unexpected
scale animation when using Navigation Compose."
Test: tested in sample app
Bug: 353294030
Change-Id: I26cb142affb046e94b34b9501e5405ddcf276fcf
Files:
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
Hash: c270d4e53585ab6033d53a2eef1f5327da39e20d
Date: Thu Dec 05 23:09:52 2024
ap...@google.com <ap...@google.com> #14
Project: platform/frameworks/support
Branch: androidx-main
Author: Jeremy Woods <
Link:
Avoid race condition for transitions in NavHost
Expand for full commit details
Avoid race condition for transitions in NavHost
This is cleaning up the code added in aosp/3393408. The issue is caused
by a race condition where the previous animation has ended but the
current animation has yet to start because `animateTo` is still waiting
to acquire the `mutatorMutex`.
We need to verify that what `AnimatedContent` believes is the
`targetState` is the same thing that is on top of the back stack before
we mark the entries as complete.
RelNote: "Fix an issue that caused an unexpected scale animation when
using Navigation Compose."
Test: tested extensively in sample app
Bug: 353294030
Change-Id: I480f4d89ffc7e2dfa536a592a8fc7b6c759be1a4
Files:
- M
navigation/navigation-compose/src/main/java/androidx/navigation/compose/NavHost.kt
Hash: 4fbe698e1ff01037c6ed1a74538c0c1628ac1730
Date: Fri Dec 06 01:10:47 2024
jb...@google.com <jb...@google.com> #15
This has been fixed internally and will be available in the Navigation 2.8.5
release.
pr...@google.com <pr...@google.com> #16
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.8.5
cl...@gmail.com <cl...@gmail.com> #17
Seems solid on my end
na...@google.com <na...@google.com> #18
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.navigation:navigation-compose:2.9.0-alpha05
Description
Component used: Navigation Compose
Version used: 2.8.0-beta05
Devices/Android versions reproduced on: Emulators, Pixel 8 Pro
Hello!
We occasionally encounter an issue where the NavHost randomly applies a default transition animation instead of the one specified for a particular composable/route. Please take a look at the sample project and screen recording I've attached. Even though composable<DefaultRoute> consistently defines slideInHorizontally/slideOutHorizontally transitions, you may sometimes observe a scale/fade animation instead. This bug is inconsistent and may require multiple attempts to reproduce. One observation is that this issue occurs more frequently when a new transition is requested just as the enter animation of a previous one is nearing completion.
Sample project:https://github.com/smelfungus/NavHostAnimationIssue
Screen recording:https://drive.google.com/file/d/1FPZavURTkuPmnAWJ49pFhIWvz3Qq-M7x/view?usp=sharing