a

    alexsullivan114

    3 years ago
    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.
    Manuel Wrage

    Manuel Wrage

    3 years ago
    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.
    540grunkspin

    540grunkspin

    3 years ago
    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.
    Zach Klippenstein (he/him) [MOD]

    Zach Klippenstein (he/him) [MOD]

    3 years ago
    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

    3 years ago
    @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.
    Adam Powell

    Adam Powell

    3 years ago
    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
    louiscad

    louiscad

    3 years ago
    Navigation arch component will not be needed for fully Compose apps, right?
    themishkun

    themishkun

    3 years ago
    @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?
    a

    alexsullivan114

    3 years ago
    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.
    themishkun

    themishkun

    3 years ago
    @alexsullivan114 You probably would have some top-level
    when
    clause dispatching all of your screens.
    Adam Powell

    Adam Powell

    3 years ago
    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