Which is the architecture recommended by google to develop android applications with Compose? MVVC? ...

# compose

[Pablo]

Which is the architecture recommended by google to develop android applications with Compose? MVVC? MVP? MVC?

[Adel Ayman]

Hu @Pablo , architecture recommended by google is MVVM and you can see it clearly here https://developer.android.com/topic/architecture?gclid=CjwKCAiAy_CcBhBeEiwAcoMRHNmBG7wXEEI9sxjgfkzRZVm5i5Qe5k-ZtR3ZhxOz_yhCTSfpwlNVuxoCmC8QAvD_BwE&gclsrc=aw.ds
They use mvvm definitions
But why mvvm?
1. android libraries support it
2. No tight coupling between vm and view unlike mvp there is tight coupling between view and presenter
3. In MVP presenter can access to view so it make testing more difficult and violates the dependency rule of clean arch so MVVM IS BETTER
4. In MVP you need to create much interfaces to connect between layers unlike MVVM
5. In MVVM business logic
separated from ui layer so code will be more testable and maintainable
And other..

[mattinger]

I would also add to the above statement:
• Immutable ui state data. Your UI state that lives in your ViewModel should be in an of itself an immutable object (usually a data class) that gets put into a MutableState object (or LiveData if you really want, but if you're pure compose, I prefer MutableState). So when anything in the state changes, you create a copy of the state along with the mutations and set it's new value on the MutableState. This lets your composables automatically subscribe to the changes. Most people keep a single UIState object, though you could use multiple ones if you really wanted.
• Unidirectional data flow. Your VM should expose your UIState either as a State (not MutableState as you don't want outside classes to change the value direction) or as a kotlin Flow. Your composables then use the State (or convert a flow using observeAsState) to render themselves. The UI then can trigger mutations by asking the VM to do operations, which internally would mutate the state.
• Keep your composables layered and VM agnostic. I typically create a composable which will take the UIState object along with lambda functions for callbacks, and render the screen for one particular state. On top of that, i'll create another composable which will interact with the view model by accessing the state and passing to the first composable, and by creating lambda functions that talk to the viewmodel. This keeps the view layer pure and easily testable.

[mattinger]

This is a very simplified (and coded up in here, so no it won't compile) example of what i'm talking about:

data class UIState(
  val someValue: Int
)

class MyVM: ViewModel() {
   private val _state = mutableStateOf(UIState())
   val state: State<UIState> get() = _state

   fun somethingWasSelected() {
     _state.value = _state.value.copy( /* apply mutations here *?)
   }
}

@Composable
fun MyViewLayer(uiState: UIState, somethingSelected: () -> Unit) {
   // draw your UI here
}

@Composable
fun MyView(viewModel: MyVM) {
   MyViewLayer(
     viewModel.state.value,
     { viewModel.somethingWasSelected() }
   )
}

[Colton Idle]

It is interesting that the docs doesn't say include "MVVM" anywhere