I have a question about the general philosophy moving forward with compose. Is the the thought that in the future we'll typically move away from activities and fragments and just have compose views all the way down? Or is the plan to integrate compose and activities/fragments to retain some of the current approaches to navigation.

I guess we will eventually use a single activity + compose functions only. It's already possible to create a flutter like navigator function to switch between screens.

If we could get a healthy alternative to Fragments I would be happy. I still think however that Activities will remain. Sometimes you just have a flow that should be decoupled from the rest of the app. Activities are still perfect for that sort of thing.

I would expect activities to remain, since they are (one of) the Android system's entry point into apps. Redesigning that interface just for Compose would be a huge project, be tied to OS version, and probably not provide much value.

@Manuel Wrage put into words what I was thinking. At a certain point, it becomes more painful than anything else to deal with multiple activities and/or fragments. The only benefit I see to continue using (multiple) activities is that you can handle saving state after process death (semi) easily. But passing information around between activities is so painful that I'm hoping Compose will allow us to circumnavigate all of it.

Kind of all of the above is the plan. In the limit I want

@MainActivity
@Composable
fun Hello() {
    Text("Hello, world!")
}

to be a complete Android app. I expect that incremental adoption will be the most common scenario at the level of individual custom views, layouts, fragments, etc. As for navigation, the navigation arch component library was written specifically with pluggable navigators to handle things like compose for destinations

Navigation arch component will not be needed for fully Compose apps, right?

@louiscad Why would you need to write some XML to navigate between screens when you can just switch your underlying model and compose will just rerender new screen from it?

The GUI could still be helpful though, right? I don't mind being able to open a file and see all of the "screens" in my eye. RN and Flutter still both have the concepts of like a full "screen", so I don't think the entire concept is necessarily thrown away.

@alexsullivan114 You probably would have some top-level

when

clause dispatching all of your screens.

The navigation XML is only one thing the nav arch component lib does, you can also build the navigation graph by dsl if you choose. Past a certain complexity of app a simple

when

probably won't cut it, but by all means keep using something nice and simple for as long as it works for you