IssueTracker

Just FYI, yeah it is strong guarantee that was specially designed this way. I keep it open as request to improve documentation

hmm i a bit confused, why are you not writing

val owner: LifecycleOwner
launchWhenCreated {
    val ui = Ui(view!!)
    whenStarted {
        viewModel.states
            .onEachInternal { ui.render(it) }
            .collect()
    }
}

you don't need nested launches, whenStarted will already scope it to the started state of the lifecycle, suspend if lifecycle stops and cancel if lifecycle is destroyed.

Sorry if my answer is unrelated, it is end of day and i just got out of a 2hr meeting :).

Does the suggestion recommended by Yigit violate structured concurrency? I may (hopefully) be wrong. whenStarted { .. } can refer to the outer LifecyclerOwner from the Fragment, which is incorrect when the View's should be used. For example:

class MyFragment : Fragment() {

    init {
        viewLifecycleOwnerLiveData.observe(
            this,
            Observer { lifecycleOwner: LifecycleOwner ->
                // incorrect `lifecycleScope`, using the `Fragment`'s when I should be using the scope from its View's `LifecycleOwner`
                lifecycleScope.launchWhenCreated {
                    val ui = Ui(requireView())
                    // incorrect `LifecycleOwner.whenStarted`, using the `Fragment`'s when I should be using the scope from its View's `LifecycleOwner`
                    whenStarted {
                        viewModel.states
                            .onEachInternal { ui.render(it) }
                            .collect()
                    }
                }
            }
        )
    }
}

One of the best things about structured concurrency is that when you nest launches, you get the correct scope always, unless you do something weird.

launch { // scope 1
  launch { // scope 2
    launch { // scope 3 
    } 
  }
}

Assuming the following is safe:

class MyFragment : Fragment() {

    init {
        viewLifecycleOwnerLiveData.observe(
            this,
            Observer { lifecycleOwner: LifecycleOwner ->
                lifecycleOwner.lifecycleScope.launchWhenCreated {
                    val ui = Ui(requireView())
                    // Is this safe? `whenStarted` refers to a `lifecycleOwner` defined OUTSIDE of `launchWhenStarted`
                    // I'm thinking it MAY be because the suspending function injected into `whenStarted` below will
                    // use the `CoroutineScope` emitted by `launchWhenCreated` above
                    lifecycleOwner.whenStarted {
                        viewModel.states
                            .onEachInternal { ui.render(it) }
                            .collect()
                    }
                }
            }
        )
    }
}

I've created the following extension functions:

// emits `LifecycleOwner`. Not named `viewLifecycleOwner` to avoid name conflict with with `fragment.getLifecycleOwner()`
fun Fragment.viewLifecycle(block: LifecycleOwner.() -> Unit) {
    viewLifecycleOwnerLiveData.observe(
        this,
        Observer { it -> block(it) }
    )
}

fun LifecycleOwner.launchWhenCreated(block: suspend CoroutineScope.() -> Unit): Job = launchWhenCreated(block)

fun <T> Flow<T>.launchWhenStartedIn(lifecycleOwner: LifecycleOwner): Job = lifecycleOwner.lifecycleScope
    .launchWhenStarted {
        this@launchWhenStartedIn.collect()
    }

Which allows me to write code in a Fragment's init block like:

init {
    viewLifecycle { // emits `LifecycleOwner` to replace the `LifeyclceOwner` reference to `Fragment`
        launchWhenCreated {
            val ui = Ui(requireView())
            viewModel.states
                .onEachInternal { ui.render(it) }
                .launchWhenStartedIn(this@viewLifecycle)
        }
    }
}

Replacing the this reference to LifecycleOwner is critical to prevent developer error where the wrong LifecycleScope is referred to. However the following double nesting is a bit verbose:

viewLifecycle { // emits `LifecycleOwner`
  launchWhenCreated {

Ideally an API could be created to allow code to be written like:

viewLifecycle.launchWhenCreated { // would need to emit both `LifecycleOwner` AND `CoroutineScope` as its parameter
}

I managed to reduce nesting and achieve the above with the following code, but was not able to return a Job from the launchWhenCreated function.

val Fragment.viewLifecycle get(): ViewLifecycle = ViewLifecycleImpl(this)

// unfortunately `LifecycleCoroutineScope` is a class, so cannot implement it
interface ViewLifecycle {
    /**
     * See [LifecycleCoroutineScope.launchWhenCreated]
     */
    fun launchWhenCreated(block: suspend LifecycleOwnerCoroutineScope.() -> Unit)
}

/**
 * A class that is both a [LifecycleOwner] and [CoroutineScope]
 */
interface LifecycleOwnerCoroutineScope : LifecycleOwner, CoroutineScope

@Suppress("UNCHECKED_CAST")
private class ViewLifecycleImpl(
    private val fragment: Fragment
) : ViewLifecycle {

    override fun launchWhenCreated(block: suspend LifecycleOwnerCoroutineScope.() -> Unit) {
        Job()
        fragment.viewLifecycleOwner {
            lifecycleScope.launchWhenCreated {
                block(LifecycleOwnerCoroutineScopeImpl(this@viewLifecycleOwner, this))
            }
        }
    }
}

private class LifecycleOwnerCoroutineScopeImpl(
    lifecycleOwner: LifecycleOwner,
    coroutineScope: CoroutineScope
) : LifecycleOwnerCoroutineScope, LifecycleOwner by lifecycleOwner, CoroutineScope by coroutineScope

Apologies for the giant comment!

So in summary, I believe I am asking for the APIs to achieve the following things:

1. .launchWhenStartedIn(..) lifecycle extension functions on Flow<T>
2. reduce change of developer error (referring to wrong LifecycleOwner, Lifecycle, and LifecycleCoroutineScope) by preventing incorrect this references to Fragment's LifecycleOwnwer when the reference is intended for the view's LifecycleOwner.
3. Improvements to avoid excessive nesting

---

#1 can be achieved by:

fun <T> Flow<T>.launchWhenStartedIn(lifecycleOwner: LifecycleOwner): Job

#2 can be achieved by:

fun Fragment.viewLifecycleOwner(block: LifecycleOwner.() -> Unit)
fun LifecycleOwner.launchWhenCreated(block: suspend CoroutineScope.() -> Unit): Job = lifecycleScope.launchWhenCreated(block)

Which creates an API like:

init {
    viewLifecycle {
        launchWhenCreated {

#3 can be achieved by providing a:

init {
  viewLifecycle.launchWhenCreated { // emits as its receiver a class that implements `LifecycleOwner` AND `CoroutineScope` 

note: the extensions I use to achieve something like this are:

https://gist.github.com/ZakTaccardi/aadfc8675ab8928d11cbca920359f854