Hi I've been doing a deep dive into Compose these last few days. Am I correct in my understanding th...

# compose

[birdsofparadise]

Hi I've been doing a deep dive into Compose these last few days. Am I correct in my understanding that eventually Compose will replace Fragments? Looking at the Compose navigation feature it leads me to believe that.

[rsktash]

Yes there will be only screens

[birdsofparadise]

Thank you, just making sure I was following everything correctly.

[Adam Powell]

It's up to you, really. Combining compose and fragments is just fine, or if you'd prefer to do green-field compose all the way through, that's fine too

[birdsofparadise]

Cool, I was curious to get a vision of what the product would be in 5 years

[Adam Powell]

Compose UI is meant to be flexible and unopinionated at that layer. Over the coming years there are sure to be many app architecture frameworks that come and go; Compose itself just consumes your app state and presents UI, with the intention that it can work with whatever you bring to the table.

[birdsofparadise]

Ok

[birdsofparadise]

I'm just curious if I can easily get away with not using Fragments with a Single Activity App if I use Compose's Navigation system

[Adam Powell]

Yep, you can

[Kshitij Patil]

IMO we should use Fragments for DI and ViewModel initialization and pass Immutable state objects to Composables. This way, you can preview your Screen at different states, test it independently and if suitable, reuse the Screen Composable in multiple Fragments. Passing viewmodel directly to the Composables seems too tight coupling to me as you might end up writing some of the UI logic in ViewModels.

I was also in the similar impression initially but doing it this way seems like getting best of both the worlds as of now.

[birdsofparadise]

Are you finding you are needing to write UI Logic in your fragments with Compose? I thought the promise of Compose is that it removes that requirement.

[Kshitij Patil]

No I'm not. I use data classes to represent the state and mutate it using action methods which are part of a sealed class. It's just I saw some people using MutableState variables inside a ViewModel to hold some UI state which I feel is a bad idea as you won't be able to use same ViewModel with lagacy xml layouts.

And Compose plays excellent with sealed classes so if you're using it right, you'll never write UI logic outside a Composable. It's really a great privilege to be able to use control structures like if else , kotlin's let run with etc. to conditionally show or hide Composables. No more need write binding adapters and stuff, in Compose, you can write plain Kotlin and it'll just work.

You can fire a coroutine right from a Composable, I mean the list just continues.