<@U0N8HQET0> I believe it depends on your use case...

# android-architecture

[gildor]

@ghedeon I believe it depends on your use case.
In general LiveData is more simple and light weight abstraction than channels, but with much mire limited use case: observable hot property that works as RxJava BehaviorSubject or ConflatedBroadcastChannel.
Also LiveData is always about delivery results on Main thread, but Channels provide much more in terms of passing messages between threads

[ghedeon]

yes, conceptually I'm aware of that, I'm more curious about practical application.

Assume that I go with LiveData (UI) + Coroutines (below UI), as the majority tutorials suggest. I post data from coroutine to LiveData, works fine. Now, the next day I decide to go with MVI, I need a loopback communication stream of events, from UI to ViewModel. Now I'm kinda stuck, right? Because LiveData doesn't work backwards, I can use channels, but then it's super weird, to use LiveData in one direction and channel in another.

[gildor]

Now, the next day I decide to go with MVI

I think it’s pretty big decision
Not sure that you can implement full-blown MVI with LiveData

[gildor]

Also with Channels it also will be probably not so good at least now, without cold streams

[gildor]

I need a loopback communication stream of events, from UI to ViewModel

But you can use LiveData for that, or am I miss something?

[ghedeon]

iriic, you should never observe LiveData in ViewModel. It's a one trick pony: main thread, one direction.

[gildor]

main thread, I understand, but why you cannot handle events on VM on main thread?

[gildor]

I do not tell that this is works for 100% cases

[gildor]

but in most cases it should work

[gildor]

I really just don’t know, what is real concern for that except main thread (which may be fine)?

[ghedeon]

mainly, because you don't (and shouldn't?) have lifecycle owner in the ViewModel?

[ghedeon]

from documentation:

However ViewModel objects must never observe changes to lifecycle-aware observables, such as LiveData objects.

[gildor]

Yes, it’s an issue of lifecycle and general architecture. In perfect world VM never should observe any views

[gildor]

which is your concern about LiveData

[gildor]

but in general, I see no problem to have some “detach” method of ViewModel and unsubscribe from all observables (LiveData, Channel, Observable)

[gildor]

but it shouldn’t be a case, when VM listen some UI

[gildor]

and it’s not different between LiveData and Channels

[ghedeon]

hm.. that's actually leads to a fundamental question about MVI. Before, my understanding was, that ViewModel observes events from View. And that's not possible with LiveData. But it's possible to flip the roles: the View creates the event stream, immideattely observers it by itself (empty observer), and ViewModel is only listening to this stream.

[ghedeon]

Because of that empty trigger observer, I always thought it's an ugly hack. But now I'm actually thinking that it's quite idiomatic, to make view responsible for all the subscriptions. This way you don't even need any detach, clean subscription methods in VM.

[gildor]

Yes, exactly, this is my point

[gildor]

ViewModel only provides events and some setters

[ghedeon]

awesome stuff. Thank you!

[gildor]

But on practice it cause sometimes pretty tricky and non-naturally looking code, but has own benefits of course