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

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

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.

@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.

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

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

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

It’s bind like livedata observe, which automatically unsubscribe

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

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

will take a look, thanks!

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