https://kotlinlang.org logo
#compose
Title
# compose
a

alexsullivan114

08/06/2019, 2:31 PM
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.
m

Manuel Wrage

08/06/2019, 2:40 PM
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.
👍 4
u

540grunkspin

08/06/2019, 3:10 PM
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.
👍 3
z

Zach Klippenstein (he/him) [MOD]

08/06/2019, 4:07 PM
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.
a

alexsullivan114

08/06/2019, 4:35 PM
@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.
a

Adam Powell

08/06/2019, 11:06 PM
Kind of all of the above is the plan. In the limit I want
Copy code
@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
😍 12
👍🏻 8
l

louiscad

08/07/2019, 6:06 AM
Navigation arch component will not be needed for fully Compose apps, right?
😁 2
t

themishkun

08/07/2019, 9:46 AM
@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?
👍 1
a

alexsullivan114

08/07/2019, 11:11 AM
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.
t

themishkun

08/07/2019, 12:06 PM
@alexsullivan114 You probably would have some top-level
when
clause dispatching all of your screens.
a

Adam Powell

08/07/2019, 12:50 PM
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
It's not "needed" for apps before compose either, but it serves a need in managing a certain kind of complexity
3 Views