Coroutine scope for Presenters

[clarksandholtz]

Coming from typical MVVM architecture, Android ViewModels provide viewModelScope for working with coroutines. I'm trying to figure out how I should provide a coroutine scope for Circuit Presenters.

Presenters don't have any kind of lifecycle, right? So there is nowhere to cancel a coroutine context. I've seen in the sample apps that sometimes the produceState scope is used, but creating an initial state can be hairy on screens with more complex state.

I am thinking that maybe the right way to do this would be to just create a scope that is shared across presenters and have that injected to the presenter. Anyone else with more Circuit or DI experience have any better ideas than what I've outlined in the example below?

If that is a good approach, any tips on making a coroutine scope for this kind of thing? Anything I need to avoid to make sure I'm not leaking memory in my presenters?

Thanks in advance!

interface WidgetRepository {
    val widget: StateFlow<Widget?>
    suspend fun createWidget(): Widget
}

@Parcelize
object WidgetScreen : Screen {
    data class State(
        val widget: Widget?,
        val widgetLoading: Boolean,
        val eventSink: (Event) -> Unit
    ) : CircuitUiState

    sealed interface Event : CircuitUiEvent {
        object ClickCreateWidget : Event
    }
}

class WidgetPresenter @Inject constructor(
    private val widgetRepo: WidgetRepository,
    @PresenterScope private val presenterScope: CoroutineScope,
) : Presenter<WidgetScreen.State> {

    @Composable
    override fun present(): WidgetScreen.State {
        val widget: Widget? by widgetRepo.widget.collectAsState()
        var widgetLoading by remember { mutableStateOf(false) }
        return WidgetScreen.State(
            widget = widget,
            widgetLoading = widgetLoading,
        ) { event ->
            when (event) {
                WidgetScreen.Event.ClickCreateWidget -> presenterScope.launch {
                    widgetLoading = true
                    widgetRepo.createWidget()
                    widgetLoading = false
                }
            }
        }
    }
}

[ZacSweers]

Presenters aren't retained on configuration changes, for scoping you should just use the native CoroutineScope APIs that compose itself offers.

[chrisbanes]

More precisely, I cannot distinguish btw presenter`s screen is popped from backstack or presenter removed due to other screen pushed.

If you're using retained state, then the state will only ever be retained when it is on the backstack, so presenters screen is popped from backstack == retained state destroyed, presenter removed due to other screen pushed == retained state exists.

Stepping back, the problem is that you need to cancel the CoroutineScope when the retained state is destroyed. I haven't tried it, but you should be able to use a RememberObserver around the CoroutineScope

[chrisbanes]

The bigger problem is less about the CoroutineScope though, and more about the coroutines you're launching off it. You need to be very careful what things you capture/reference from the launch. Basically you can only ever reference other retained instances/state.

For this to be useful, we'd probably need some sort of LaunchedRetainedEffect

[vulpeszerda]

@chrisbanes Thank you for the response.

If you're using retained state, then the state will only ever be retained when it is on the backstack, so presenters screen is popped from backstack == retained state destroyed, presenter removed due to other screen pushed == retained state exists.

Stepping back, the problem is that you need to cancel the CoroutineScope when the retained state is destroyed. I haven't tried it, but you should be able to use a RememberObserver around the CoroutineScope

I think that exactly same. However, because of rememberRetained implmentation, wrapping CoroutineScope with RememberObserver within rememberRetained doesn't work. RememberObserver's callbacks (ex. onAbandoned, onForgotten, onRemembered) never called.

[vulpeszerda]

The bigger problem is less about the CoroutineScope though, and more about the coroutines you're launching off it. You need to be very careful what things you capture/reference from the launch. Basically you can only ever reference other retained instances/state.

yeah right. because of this, I'm worrying my approach is not fit with circuit's philosophy.

Firstly I tried to migrate my ViewModel based code to circuit, so wanted to make presenter's coroutine scope lifecycle to be same with ViewModel's. However the actual usecases that should keep coroutineScope alive are not so many and it could be designed presenter to do some coroutine jobs until presenter not being displayed.

So in conclusion - I could use just rememberCoroutineScope instead of rememberRetainedCoroutineScope. But if using RememberObserver within remeberRetained works, it would be awesome. 😉

[vulpeszerda]

@chrisbanes Awesome 👍 👍 👍 👍

• Enable RememberObserver to work with rememberRetained #1210
• Add retained caching for paging flows chrisbanes/tivi#1763