Support List<Enum> route parameters for type-safe navigation [375559962]

Fixed

Feature Request

Status Update

No update yet.

Description

cs...@supercharge.io

created issue #1

Oct 25, 2024 02:42PM

Component used: Navigation
Version used: 2.8.3

@Serializable
class MyRoute(
val platforms: List<Platform>
)

enum class Platform {
ANDROID, IOS
}

composable<MyRoute> { MyScreen() }

This will result in an exception:

java.lang.IllegalArgumentException: Route MyRoute could not find any NavType for argument platforms of type kotlin.collections.ArrayList - typeMap received was {}

Please support list of enums by default.

Comments

jb...@google.com <jb...@google.com> Oct 25, 2024 04:05PM

Assigned to cl...@google.com.

cs...@supercharge.io <cs...@supercharge.io> #2Oct 31, 2024 12:19PM

Using navigation version 2.6.0 and 2.7.1 the issue still persists.

After further investigation, the behaviour can be corrected by filtering on backstack entries where current state is at least started. In my opinion the name visibleEntries is misleading if it contains entries that are not actually visible or in transition.

jb...@google.com <jb...@google.com> #3Oct 31, 2024 03:52PM

Note that as per the visibleEntries documentation, it is expected that there are entries that are in the CREATED state - those are the entries that are in the process of being removed (i.e., they are no longer in the back stack, but have not yet marked their transition as complete).

It is a bug that those entries aren't removed when their exit animation completes and that's what we'll be looking into.

cs...@supercharge.io <cs...@supercharge.io> #4Nov 8, 2024 03:10PM

Project: platform/frameworks/support
Branch: androidx-main

commit f61da31809827bfac89af629c88ad9b8423e88b6
Author: Clara Fok <clarafok@google.com>
Date: Wed Sep 06 14:14:11 2023

Fix entry not marked complete after view is destroyed

As part of a fix for

b/279644470

in aosp/2566210, when the fragment view is destroyed, we would mark the transitioning (outgoing) entry as complete only if the entry has also been removed from backstack. However, in the simple navigate() case where the outgoing entry is not popped and remains in the backstack, this entry is not marked complete and ends up in the visibleEntries even though the view has been destroyed.

Now the backstack check in ON_DESTROY is no longer necessary to fix the original

b/279644470

bug -- the view being destroyed should be the right signal for completing entries regardless of whether transitioning effects are used. So this check is removed.

Test: ./gradlew navigation:navigation-fragment:cC
Test: ./gradlew navigation:navigation-runtime:cC
Bug: 288520638
Change-Id: I5caa9af1b5bd7084e76d7daf9515f7430bf2489d

M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/FragmentNavigatorTest.kt
M navigation/navigation-fragment/src/androidTest/java/androidx/navigation/fragment/NavControllerWithFragmentTest.kt
M navigation/navigation-fragment/src/main/java/androidx/navigation/fragment/FragmentNavigator.kt
M navigation/navigation-runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M navigation/navigation-runtime/src/main/java/androidx/navigation/NavController.kt

https://android-review.googlesource.com/2743918

ap...@google.com <ap...@google.com> #5Nov 19, 2024 08:14PM

Marked as fixed.

Fixed internally and will be available in navigation 2.7.3

cl...@google.com <cl...@google.com> #6Nov 19, 2024 09:00PM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-fragment:2.7.3
androidx.navigation:navigation-runtime:2.7.3

pr...@google.com <pr...@google.com> #7Dec 11, 2024 06:27PM

The issue no longer persists in version 2.7.3. Thank you all for the update.

cs...@supercharge.io <cs...@supercharge.io> #8Dec 12, 2024 09:22AM

The following release(s) address this bug.It is possible this bug has only been partially addressed:

androidx.navigation:navigation-fragment:2.8.0-alpha01
androidx.navigation:navigation-runtime:2.8.0-alpha01

Message last modified on Dec 12, 2024 09:23AM

il...@google.com <il...@google.com> #9Jan 17, 2025 11:23PM

We've added a note to the release notes - thanks again!

In the future, note that you can add a Relnote: line in the pull request's description to ensure it gets into the release notes automatically.

ko...@gmail.com <ko...@gmail.com> #10Feb 19, 2025 01:02PM

Thanks! I followed the Github contribution guide, there is no information about Relnote:, maybe it should be added there.