How to handle long lived operations triggered from presenters?

[MiSikora]

I've been exploring Circuit for the past two days, so I apologize if I'm missing something obvious. However, I find the lack of guidance on handling long-running operations in presenters to be the roughest part of my experience so far.

The best advice I've encountered is to use proper dependency injection and maintain a well-structured data layer, but none of the samples or documentation explicitly illustrate this approach. Below is an example that highlights my struggle:

interface AuthService {
    suspend fun signIn(user: String, password: String): Result<Unit>
}

@Parcelize
data object LoginScreen : Screen {
    data class State(
        val inProgress: Boolean,
        val errorMessage: String?,
        val eventSink: (Event) -> Unit,
    ) : CircuitUiState

    sealed interface Event : CircuitUiEvent {
        data object SignIn : Event
    }
}

@Composable
fun LoginPresenter(
    authService: AuthService,
    navigator: Navigator,
    scope: CoroutineScope,
) : LoginScreen.State {
    var isSigningIn by rememberRetained { mutableStateOf(false) }
    var signInError by rememberRetained { mutableStateOf<String?>(null) }

    return LoginScreen.State(
        inProgress = isSigningIn,
        errorMessage = signInError,
    ) { event ->
        when (event) {
            SignIn -> {
                isSigningIn = true
                scope.launch {
                    authService.signIn("AzureDiamond", "hunter2")
                        .onSuccess { navigator.resetRoot(ProfileScreen) }
                        .onFailure { signInError = it.message }
                    isSigningIn = false
                }
            }
        }
    }
}

In the above example, LoginPresenter receives a CoroutineScope from the DI graph. However, I'm unsure how to leverage Circuit to detect when the LoginScreen is no longer in use, so I can cancel the scope.

The goal is to keep the sign-in request in-flight as long as the LoginScreen remains on the back stack. Once the screen is removed, active jobs should be cancelled.

Currently, the best solution I've found is Chris Banes' rememberRetainedCoroutineScope(). But this solution isn't provided by the Circuit library, which makes me question whether I'm approaching this correctly.

@Composable
fun rememberRetainedCoroutineScope(): CoroutineScope {
    return rememberRetained("coroutine_scope") {
        RememberObserverHolder(
            value = CoroutineScope(context = Dispatchers.Main + Job()),
            onDestroy = CoroutineScope::cancel,
        )
    }.value
}

internal class RememberObserverHolder<T>(
    val value: T,
    private val onDestroy: (T) -> Unit,
) : RememberObserver {
    override fun onAbandoned() {
        onDestroy(value)
    }

    override fun onForgotten() {
        onDestroy(value)
    }

    override fun onRemembered() = Unit
}

The only similar scenario I've found in the samples is in the star sample, where PetListPresenter refreshes data. However, in this case, the job isn't retained across configuration changes:

circuit/samples/star/src/commonMain/kotlin/com/slack/circuit/star/petlist/PetListScreen.kt

Line 223 in 7067f20

Refresh -> isRefreshing = true

circuit/samples/star/src/commonMain/kotlin/com/slack/circuit/star/petlist/PetListScreen.kt

Lines 174 to 180 in 7067f20

	var isRefreshing by remember { mutableStateOf(false) }
	if (isRefreshing) {
	LaunchedEffect(Unit) {
	petRepo.refreshData()
	isRefreshing = false
	}
	}

Am I overlooking some crucial APIs or best practices in Circuit for handling long-running operations tied to a screen's lifecycle? If not, it would be helpful to include clearer documentation or examples for this use case.

[ZacSweers]

But this solution isn't provided by the Circuit library, which makes me question whether I'm approaching this correctly.

Not everything needs to be first party! That solutions works well. We could look at adding a CircuitX artifact for it, open to feature requests.

The best advice I've encountered is to use proper dependency injection and maintain a well-structured data layer, but none of the samples or documentation explicitly illustrate this approach.

You are right that we don't really try to detail this in docs, we intentionally aren't trying to teach larger data architecture concepts at the same time as Circuit and every app uses different patterns. We do actually implement a full data layer in the the STAR sample — it has a full repository implementation where the data layer's actions are largely independent of the UI reading from it. That said, it wouldn't hurt for us to maybe add a login sample at some point. You could look at how Tivi does it - look for usages of this class: https://github.com/chrisbanes/tivi/blob/a0c62c2c763c83e3a0ecf79b283224374bb06c4a/data/traktauth/src/commonMain/kotlin/app/tivi/data/traktauth/TraktAuthRepository.kt

[MiSikora]

Not everything needs to be first party!

I was mainly confused because I think it’s a common scenario to trigger something from the UI that needs to be retained across configuration changes, returns a result, and then requires processing and display in the UI. Since there are APIs like rememberRetained() and collectAsRetainedState() for local updates and reads, I thought it would follow naturally to have something similar for writes as well.

Also, as I’ve just started using the library, I didn’t want to dive too deeply into the internals to determine whether the solution with rememberRetainedCoroutineScope() is a valid approach and thought it would be better to ask.

We do actually implement a full data layer in the the STAR sample — it has a full repository implementation where the data layer's actions are largely independent of the UI reading from it

That was my main point about the STAR sample — unless I’m missing something, it seems to focus mainly on reads. The closest thing to a write operation is the refresh method, but I couldn’t find anything that handles writing, such as leaving likes, comments, signing in, etc.

In any case, thank you for the response and the library. I really enjoy the experience with it!

[vulpeszerda]

@MiSikora
I’d like to share some thoughts about adding rememberRetainedCoroutineScope as a default feature in Circuit. While I’ve considered it necessary in the past, I currently have a slightly different perspective.

Chris Banes’ rememberRetainedCoroutineScope works well and has no issues in itself. However, retained coroutine scopes run and cancel independently of Compose’s lifecycle, which comes with some caveats.

One notable issue is that accessing and updating values declared in the presenter function might not always be valid at the time the coroutine is executed.

For instance, imagine a scenario where a NavigableCircuitContent-based screen transitions from screen A to screen B while an async task is running in a coroutine initiated by screen A. In this case, the retained coroutine for screen A would continue running, but the presenter’s composable function would already be removed from the node. Therefore, if the coroutine updates any internal values of the presenter that need to be retained when returning to the screen, all such fields accessed within the coroutine must be set with rememberRetained. This adds additional considerations for using Compose-related features of the presenter while a coroutine is running.

Initially, I thought it was necessary for tasks started by the presenter to persist even after transitioning to a different screen, akin to how Android ViewModel works. I also believed this should be supported as a default feature in Circuit. However, after more reflection, I’ve come to the conclusion that something like rememberRetainedCoroutineScope may not always be essential. In my case, I found it more challenging to inform all contributors to my project about these issues and ensure they avoid mistakes when using Circuit.

That said, I’m not opposed to Circuit supporting this in the future. However, I do not agree that it must be a default feature in Circuit.