While using MVVM I have a lot of live data objects inside ViewModel (especially for actions), so I m...

# android

[Kirill Prybylsky]

While using MVVM I have a lot of live data objects inside ViewModel (especially for actions), so I made this:
https://pastebin.com/DhXKEpAA
What cons can it have?
Combined with coroutines it can be like this:
https://pastebin.com/6phjEQZC

[alex009]

something like moko-mvvm EventsDispatcher
https://github.com/icerockdev/moko-mvvm#viewmodel-with-send-events-to-view

good approach - interface much better than separated event classes for every action

[Ronald van D]

If I understand correctly, you’ve got a view that implements LoginAcceptable . The post in the livedata is actually just a method call on that View. But what happens on a configuration change? Then the view is recreated but the viewmodel will hold an old reference. You should not hold a reference of your view in the viewmodel. I like to use sealed classes for this.

[Kirill Prybylsky]

@Ronald van D ViewModel doesn’t hold any reference on view. Basically, VM just send lambda to View and view invokes this lambda on itself.

[Kirill Prybylsky]

@alex009 I think it’s much easier to make typealias and interface rather than all this classes in example, isn’t it?

[alex009]

In sample only interface EventsListener and class EventsDispatcher about this case)

[Ronald van D]

@Kirill Prybylsky Ah, misunderstood it. Looks like a fine approach then 🙂.

[Kirill Prybylsky]

@alex009 ViewModel holds direct reference on the lifecycleOwner, thats ugly.

[alex009]

It’s bind like livedata observe, which automatically unsubscribe

[Kirill Prybylsky]

so dispatcher is like a wrapper of livedata? if so, then ok.

[alex009]

Its similar as livedata in automatically unsubscribing, but also guarantee that call will be only once.

[Kirill Prybylsky]

will take a look, thanks!

[mng]

SingleLiveEvent is also an option for firing an event once and not hanging on to a reference of it. Only catch is there can be only one Observer