<https://proandroiddev.com/android-components-arch...

# feed

[Madalin Valceleanu]

https://proandroiddev.com/android-components-architecture-in-a-modular-word-7414a0631969

[Joost Klitsie]

I like the article and I think the github repo gives a very good example about the modularization.
I do have a question in regards to the usage of MVVM, and please correct me if I am wrong:
Why do you halfway map things to a UI object in the ViewModel, only to later on do some more state interpretation in your views?
For example, you map the character list and pass on the list of view items to the UI, yet you also have this in your XML:
app:visible="@{viewState.isLoaded || viewState.addLoading || viewState.addError || viewState.NoMoreElements}">
If you have MVVM, why not put this logic also in the ViewModel? Then you can expose 1 ui state containing the list as well as the visibility of the recyclerview.
This xml logic (where you have 4 options) is difficult to test (I mean do you really want to write 5 espresso tests to test this?)

I think a viewState object containing the actual state of your view (instead of the state of the app) does make more sense in general, and mapping the app states (isLoaded) to view states (isVisible = true) within the view should require a presenter layer, as now you are basically mapping twice. It is hard to understand: Where do I put the logic? Because now you have a ViewModel that maps a state to the UI, the UI that maps states to events and XML that maps states to actually displaying something.

With UI that maps states to event, I mean for example within the CharacterDetailFragment:
when (viewState) { is CharacterDetailViewState.Loading -> progressDialog.show(R.string.character_detail_dialog_loading_text)

[Joost Klitsie]

Is there a reason for this fragmentation in the view layer?

[Madalin Valceleanu]

First of all thanks for your message Joost. I’m absolutely agree with you that there are different ways to handle that. At the xml level, view or ViewModel. Because in my case the logic start to begin more complex about the visibility of the specific component it’s good handle that more on the View level, because ViewModel in that case contains view logic. Imagine in the future you have different condition for each visual component. Making you ViewModel containing a lot of logic about presentation components

[Joost Klitsie]

But theoretically speaking, how much should your ViewModel know about presentation? I always imagined that the ViewModel and the View are (although not with contracts) quite coupled, as this is how I imagine it, but I could be wrong:

With MVP (to be fair this is my favourite still), the model is pure data, then the presenter maps the data and updates the view through a contract. The view in this way has 0 logic within (no if/else/when) and the presenter and view are tightly coupled.

I always imagined with MVVM, this is the same, but different 😄 Where the Model holds the data, the ViewModel maps the data into a ViewState (could be multiple states, one for the view, one for navigation, one for events etc..), and the View simply observes this data. In this case the View also holds 0 logic within (no if/else/when, maximum view.Visibility = if (state.isVisible) VISIBLE else GONE)

For both MVP and MVVM, shared business logic can then go into the Model, for example by the use of UseCases.