Nice shot Joost Klitsie! You are absolutely right about that approach. And if honestly, I didn’t know about its existence. Just want to point out a couple of small but yet important details:

1. This solution uses coroutines, which is fine in most cases since we using Kotlin and might consider using coroutines in our project. In case of other approaches (rx, threads) this solution in fact just encapsulates working with scopes and dispatchers inside and gives a nice API to the user. However, we should remember, that this solution involves coroutines. If you don’t want to use them in your project at all, probably this solution will not work out for you (this case is rare, I agree, but in big enough team we can have some agreements and etc).
2. Your solution is just a nice couple of lines to help to eliminate my self-written code and it solves the main problem with managing lifecycles. Unfortunately, it will not solve the problem of unique delayed actions, which I describe in the middle of the post. For instance, you want to scroll to some element of the list. And you want to do that with some delay. And you want to do that only once because you want to avoid unnecessary “jumps” visible to the user. With my solution applying new delay cancels the old one automatically. With your solution, we still need to think about it.

I’m not telling that your solution is bad. Vice versa! We just still need to make some base work (but with less amount of code) to achieve that interchangeability :)