IssueTracker

One thought I had was to leverage the reflect package in Compose.

Perhaps you could have a navigation-fragment-compose artifact that allowed you to add a <composable> destination to your fragment navigation graph built in XML where the XML would allow you to use the android:name to define the fully qualified name for the composable function you want to use as your destination.

We could then write a ComposableFragment class that's sole responsibility is to load that composable function via reflection. Instances of that ComposableFragment would be what would be added to the NavHostFragment back stack when you navigate to that destination.

Effectively, from a developer perspective, you have destinations that are completely implemented as a composable function, but are actually interoperable with a fragment back stack.

This wouldn't give you full access to the Fragment APIs (i.e., you couldn't define what AndroidX Transition your Fragment uses), but if you needed that for a particular destination, you could still create a Fragment that uses ComposeView directly like you can do today.

Did a rough prototype of Ian's idea in https://github.com/arriolac/IncrementalNav which generally looks promising

• Nav graph: https://github.com/arriolac/IncrementalNav/blob/main/app/src/main/res/navigation/nav_main.xml
• ComposeFragment: https://github.com/arriolac/IncrementalNav/blob/main/app/src/main/java/com/example/incrementalnav/ComposeFragment.kt

Some considerations with this approach:

• Navigating to a screen-level composable to be contained with a ComposeFragment would need to provide the composable name and the containing Kotlin file (so you know which Class to do the reflection against). In my prototype, have the composable within ComposeFragment though in a real-world app you'd have a different structure.
• The screen-level composable in my prototype doesn't include any parameters though that would have to be taken into account. As in parameters to the composable need to be passed in via NavBackStackEntry

Re comment#5 - it would allow incrementally moving each screen of your app to Compose, continuing to use Navigation with Fragments until you don't actually have any Fragments left. Once you don't have any fragments left, then and only then would you migrate to Navigation Compose.

We are currently incrementally migrating to compose and we have been creating wrapper fragments for our new compose screens which isn't so bad. But one issue is around dialogs and bottom sheets. They cannot be easily migrated because putting the dialog composables inside a dialog fragment creates two dialog windows (one from compose and one from the fragment). For that reason it would be create if we could add composable destinations along side fragment destinations.

why it is not possible to pass de backStackEntry to the composable function in order to get the some arguments inside the composable function?. This feature is very nice but it solves only a part of the problem, the majority of destinations have arguments being passed down.

Re comment#15 - if you look at the test added in comment#14 where we added LocalFragment, you'll see retrieving arguments is exactly the use case for that API using LocalFragment.current.requireArguments()

Is there a way to make this work with the Safe Args plugin? As soon as I add an action to a composable destination like so:

<composable
  android:id="@+id/home_screen"
  android:name="com.example.HomeScreenKt\$HomeScreen" >
  <action
    android:id="@+id/action_home_screen_to_other_fragment"
    app:destination="@id/other_fragment" />
</composable>

My project build fails on the :app:generateSafeArgs task with the following error:

Can't escape identifier `HomeScreenKt\$HomeScreenDirections` because it contains illegal characters: \

Re comment#17 - please file a new issue to track that issue.