How one should structure a new android project wit...

# compose

[Kaushalya Pradeep]

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

[satyan]

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

[Kaushalya Pradeep]

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.

[Kaushalya Pradeep]

I was seeking some advice from the compose team, how would they advice devs to structure the code for new projects with hope of moving to compose in 2,3 years down the line? while making migration less painful as possible.

[Mark Murphy]

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.

[codeslubber]

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

[Brady Aiello]

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.

[codeslubber]

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.

[Brady Aiello]

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.

[Adam Powell]

I enjoy watching these discussions 🙂

[Adam Powell]

Compose itself is aiming for being agnostic to app architecture, you can bring your own. Jetpack as a whole will undoubtedly end up adapting and updating the various architecture components libraries as one opinion on things

[Adam Powell]

as to the higher level question of how to get ready for it, lean into observable data and one-way data flows. Views don't own sources of truth, they are reflections of the app's sources of truth. State should be pushed into views when that state changes, and events from views should signal the app's higher layers to take action on that state.

[codeslubber]

@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…

[codeslubber]

The agnosticism is a good idea, but it might be nice to have a few samples that show Compose doing basic updates with various underpinnings, the architecture patterns were amazing that way: you could get a LiveData/ViewModel combo going in no time that gave you free view updates and didn’t require a lot of ugly circuit soldering… 🙂