does the logic in the observe method belong into t...

# android-architecture

[Florian]

does the logic in the observe method belong into the ViewModel?

[streetsofboston]

In my opinion, yes.
That would also make it easier to test

[Florian]

thank you

[streetsofboston]

In my opinion, any ‘if’ or ‘when’ statement in your Activity/Fragment is a possible code smell.

Not for ’if’s or ’when’s that are just super simple translations (eg textView.visible = if (uiData.isVisible) View.VISIBLE else View.GONE), but anything a bit more complex should be in a ViewModel.

[Florian]

thank you, that's a useful guideline

[Florian]

what do you use to communicate events back from the viewmodel to the fragment?

[streetsofboston]

Depends what architecture pattern you use.

For plain MVVM, the Activity/Fragment just calls a method on the ViewModel and it does what needs to be done.

If you use MVI, you probably want to have the Activity/Fragment emit an action-event into the ViewModel’s state stream.

[Florian]

I use MVVM

[Florian]

but still when all the logic is in the ViewModel I have to trigger some events in reaction to it

[Florian]

like Snackbars or navigation events

[Orhan Tozan]

Use Flows with BroadcastChannel(1) for events😉

[streetsofboston]

^^^ Yup. And you can wrap that inside your own Flow implementation (eg create your own EventFlow)

[Florian]

thank you

[Joost Klitsie]

@streetsofboston you can even get rid of most with some extension functions: textView.isVisible = uiDate.isVisible

[Florian]

sure I guess he just wanted to give an example for an if/else

[Jean Carlos]

@streetsofboston

I think that in MVVM the ViewModel's behavior isn't like a Presenter in MVP.

Since a ViewModel can be shared for more than 1 View, for me, doesn't make sense it be aware about specific View logic.

So yes, it's ok if you have view logic on View/Fragment in MVVM.

[streetsofboston]

It depends.... 😀

We usually model the ViewModel very very close to the actual UI (View). A ViewModel is basically a testable UI 😀. Use cases, business logic, is implemented by other code/classes.

But if your ViewModel is more like a use case, which can be reused by more than one UI/View/Activity/Fragment, then this changes like you described.

[Orhan Tozan]

@Jean Carlos I also have to disagree with sharing a ViewModel with more than 1 view.

[Joost Klitsie]

@Jean Carlos I disagree, the term ViewModel basically means: Model of your View

[streetsofboston]

@Joost Klitsie and @Orhan Tozan
I agree with you, but one could argue to use ViewModels subclasses as use cases. I wouldn’t do it, but I don’t think it is totally wrong:

Basically your architecture pattern is then to have use cases interface with Activities/Fragments directly, sub-class from ViewModel to be able to use ViewModel’s lifecycle, but treat these subclasses as use-cases. Unit test these ViewModels/use-cases and instrumentation-test your UI.

Not my choice, but not wrong either, in my opinion.

[Joost Klitsie]

Well the point of these architectures is to get logic out from the view and do it in such a way that it is testable without instrumentation tests

[Joost Klitsie]

because instrumentation tests are difficult to run

[Joost Klitsie]

so any MV-whatever architecture should result in the view basically being the adapter between logic and view input so you don't really have to test it

[Jean Carlos]

Not exactly. Sometimes we tend to get confused between ViewModel and MVP's Presenter.
ViewModel is not a Presenter.

A testable UI is a concern of MVP with passive View approach. On the other hand, ViewModel basically is the Model of a View.
https://docs.microsoft.com/en-us/archive/blogs/johngossman/introduction-to-modelviewviewmodel-pattern-for-building-wpf-apps

Reading the first post about MVVM, my interpretation was that it is not so bad if you have some UI logic on View in MVVM. Is it right?

@Joost Klitsie @Orhan Tozan It's not about opinion. Take a look at this paper.

"Microsoft MVVM allows every View to have its own View Model, while each View Model can have several Views. This allows displaying the same data in different ways, possibly simultaneously." - Syromiatnikov, A Journey Through the Land of Model-View- Design Patterns.*