ah, I found the solution: https://medium.com/the-kotlin-chronicle/why-you-should-use-class-delegation-in-kotlin-fb0a3ebf151e

Author for both articles here 👋🏻 Delegation is certainly optional and it really depends on your own unique circumstances.

yeah, noticed your picture in the thread above 😄

Depending on how much you're using Rx though, it can make sense to extract a smaller interface over CompositeDisposable, something like

DisposableHandler

, and then that would maintain creating the

CompositeDisposable

and ensuring the correct function is invoked. I used this at a previous company to share code with the Activity, Fragment, and ViewModel. Albeit there is a bit of ceremony going on and you'd still likely end up with a

DisposableActivity

,

DisposableFragment

, and

DisposableViewModel

, but that's one way delegation could play into it.

yeah thanks! I don't like the idea of "overriding" the

onCleared

function via interface composition or delegates though. The compiler wouldn't detect if the view model's

onCleared

was renamed, for example

Yeah the main benefit is honestly keeping the CompositeDisposable behind a facade so it can be a bit more decoupled, in the grand scheme of things though it usually plays out to being contained in 3 top level classes so also not a ton of duplicated code either

agree with the first part. Concerning the second, Im probably missing something. With the interface (and without inheritance) I still need to have in every class using it 1) the val declaration and 2) overriding

onClear()

(or equivalent) to call the interface's method, so it's pretty much the same amount of code than without the interface.

So the interface might look something like this:

interface DisposableHandler {
    fun addDisposable(disposable: Disposable)

    fun addDisposables(disposables: List<Disposable>)

    fun clearDisposables()
}

Then the implementation (what would be delegated to the Activity, Fragment, ViewModel) would use a

CompositeDisposable

as the property to proxy those. There are some more advanced techniques you could use, such as having

Application.ActivityLifecycleCallbacks

registered to invoke

clearDisposables

when

onDestroyed

is called. There is a similar callback for Fragments too, but I'm unsure if ViewModels have anything similar... That'd be one way to avoid having a base class though.

yes, what I mean is that the implementation would still have to call

clearDisposables

on the interface, which would result in the same amount of code than just managing them itself (assuming usage of

CompositeDisposable

)

ActivityLifecycleCallbacks

would probably improve this though.

Yeah, it's very much on the fringe of overengineering. It's one of those things that I wouldn't necessarily push for but I also wouldn't be against if it were there