Introduced LifecycleExtensions overloads to set observation schedulers

[LachlanMcKee]

Description

Proposal for allowing developers to set observation scheduler for Binder and lifecycle extensions.

Check list

• I have updated CHANGELOG.md if required.
• I have updated documentation if required.

[CherryPerry]

I think the API a little bit verbose, especially when we do not need to use it most of the time. Can we remove LifecycleBinderSchedulers and make API more lightweight?

lifecycle.createDestroy(scheduler) {
   bind(a to b using c) // implicit .observeOn scheduler
}

lifecycle.createDestroy {
  bind(a to b using c observeOn scheduler) // explicit
}

[CherryPerry]

createDestroy(scheduler) and createDestroy(lifecycleBinderSchedulers) have one issue – when you start applying them to the existing code, you might change subscription order, leading to some unexpected bugs. So it might be helpful to consider only infix observeOn usage.

[LachlanMcKee]

nothing stops developers using observeOn in the version that does not take a scheduler. (It's actually already in this PR).

I am hoping that we WILL use this 'verbose' api as it sets out a strict guideline, and is less boilerplate in case you want to set a schedule in a lot of places.

I could also change it so that you can also call bind outside of main/background and remove unbound

so it could look like

testLifecycleOwner.lifecycle.createDestroy(schedulers) {
    mainThread {
        bind(events to uiConsumer)
    }
    backgroundThread {
        bind(events to analyticsConsumer)
    }
    bind(events to dontSwitchThreadsConsumer)
    bind(events to dontSwitchThreadsConsumer observeOn mainThreadScheduler)
}

[LachlanMcKee]

With regards to unexpected bugs, developers would need to be aware of this change and take that into account if/when migrating. At the moment there is no way to ensure that everything is happening on the main/background threads anyway, so it's likely already an issue

[CherryPerry]

I do not like that I need to create a separate LifecycleBinderSchedulers class instead of injecting schedulers directly.

[LachlanMcKee]

I've changed this in my 3rd attempt at the API.

testLifecycleOwner.lifecycle.createDestroy {
    withScheduler(mainScheduler) {
        bind(events to uiConsumer)
    }
    withScheduler(backgroundScheduler) {
        bind(events to analyticsConsumer)
    }
    bind(events to dontSwitchThreadsConsumer)
    bind(events to dontSwitchThreadsConsumer observeOn mainThreadScheduler)
}