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

Thanks for the report - do you have any reproduction steps?

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

Nevermind, this has been fixed and will be available in an upcoming release.

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

An unfortunate side effect of this seems to be that the adapter is set to null before any pending fragment animations are completed.

In my project I add a PreferenceFragmentCompat to the backstack, specifying custom enter and exit animations. Now, when the user presses the back button I call FragmentManager.popBackStack() which in turn starts the custom exit animation.

The problem is that popBackstack() internally calls onDestroyView() on the PreferenceFragmentCompat to be removed. The PreferenceFragmentCompat calls unbindPreferences() which calls getListView().setAdapter(null).

The effect is that the list of preference items is cleared instantly before the exit animation even starts! This causes a white flicker and is clearly noticeable, the preference items disappear, then the view fades out.

Could you prevent setAdapter(null) from being called in this scenario? Maybe unregister the data observer instead?

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

Marked as fixed.

Since the Fragment 1.2.0-alpha02 release fragments wait until exit animations are complete before onDestroyView() is called so this should not be an issue in any current Fragment versions.

Please file a bug against Fragments the with a sample project that reproduces this issue and we will be happy to take a look at what's going on.

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

I can confirm that using fragment 1.2.2 resolves the issue, thank you!

Without an explicit dependency declaration version 1.1.0 was still used (transient dependency of appcompat 1.1.0).

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

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-runtime:2.9.0-alpha04
androidx.navigation:navigation-common:2.8.5
androidx.navigation:navigation-runtime:2.8.5

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

The fix is missing from the release notes:
https://developer.android.com/jetpack/androidx/releases/navigation#2.8.5
https://developer.android.com/jetpack/androidx/releases/navigation#2.9.0-alpha04

Can you add it there, please?

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.