How one should structure a new android project with the hope of migrating to Compose later in order to make migration smoother as possible? MVVM, MVI, BLOC? @romainguy

Isn’t compose only suppose to replace the view layer ? So, I would at least follow the recommanded architecture: • MVVM View: fragment with a composable view ViewModel: to handle rotation (+ SaveState to handle process death) And then for your business logic Business entities + use cases with uses repositories

there is no fragments in compose. there will be changes for navigation, state management. state management seems to be like in reactjs as seen in https://codelabs.developers.google.com/codelabs/jetpack-compose-basics/#4 Probably they will introduce pattern like Redux/MVI for state management. Presentation layer is also expected to change.

there is no fragments in compose

That is not strictly true. You can have a fragment display a composable. I would imagine that many fragment-centric apps will migrate to Compose by having fragments render composables first, then work on removing the fragments themselves.

Why would VM be unnecessary because you have States and Models? I don’t see that….

One of the ViewModel's jobs to be a single source of truth for the view state. (it also helps with code separation and making the app more unit-testable). But if you don't need to worry about maintaining state, because compose handles it with simple annotation, you probably won't have a ViewModel. You still might want some other class handling IO and other responsibilities, but it won't be managing state. It may be a Presenter, or something else depending on the architecture.

I know what a viewmodel is, but if you just revert to state annotated fields in the view, that’s going back to the controller just comes in and ferries things in and out, and there is no logic.. the other idea of a viewmodel is that the model is often not bindable to the view, e.g. if I made a form to have someone apply for a job, I have to get

Applicant

information and build an

Application

but the form needs things like options for some of the selections, etc. Those would not come from an Applicant or even Application model.

Sorry, I didn't mean any offense. I think we might be misunderstanding each other. What I meant by model is the Compose model annotation. I didn't mean that you don't need model classes. Just that if Compose manages state, then the VM is free of that responsibility.

I enjoy watching these discussions 🙂

@Brady Aiello sorry if my response sounded snippy, I was a fan of the MVVM stuff introduced a few years ago, hoping something like it will survive the newer changes.. not a huge fan of Rx et al: it glories a bit too much in exposing all the venting, like a room with pipes and ducts everywhere.. I would rather have those things in the wall.. Bertrand Meyer makes a lot of arguments about even slight disruptions of code coherence (sticking to its own logical purpose) can render it unreadable, I agree with that…