when I wrap an object that holds resources and req...

# coroutines

[leandro]

when I wrap an object that holds resources and requires a callback through a suspendCancellableCoroutine, do I need to cleanup the resources inside the error callback?

suspend fun isSessionValid(): Boolean = suspendCancellableCoroutine { continuation ->
    lateinit var auth: Auth

    val callback = object : AuthHandler {
        override fun onSuccess(session: AuthUserSession) {
            continuation.resume(session.isValid)
            auth.release()
        }

        override fun onFailure(e: Exception) {
            continuation.resumeWithException(e)
        }
    }

    auth = builder.setAuthHandler(callback).build()
    auth.getSession()
    continuation.invokeOnCancellation { auth.release() }
}

[Dominaezzz]

Short answer is yes. Long answer is I need to see more code.

[leandro]

I can share more, would the whole function be enough? not sure what else could be valuable

[Dominaezzz]

The whole function I'd say.

[leandro]

Cool! I edited the initial post

[Dominaezzz]

Wow, what an awkward api. Is this like Google Play services thing or...? (I'm looking for docs to confirm something)

[leandro]

Amazon cognito 🙈

[leandro]

https://github.com/aws-amplify/aws-sdk-android/blob/main/aws-android-sdk-cognitoauth/src/main/java/com/amazonaws/mobileconnectors/cognitoauth/Auth.java

[Dominaezzz]

suspend fun isSessionValid(): Boolean {
    val latch = CompletableDeferred<AuthUserSession>()
    val callback = object : AuthHandler {
        override fun onSuccess(session: AuthUserSession) {
            latch.complete(session)
        }

        override fun onFailure(e: Exception) {
            latch.completeExceptionally(e)
        }
    }

    val auth = builder.setAuthHandler(callback).build()
    try {
        auth.getSession()
        val session = latch.await()
        return session.isValid
    } finally {
        auth.release()
    }
}

[leandro]

interesting, TIL about CompletableDeferred!
It does seem to do the job, like before, but in a better ergonomics. Is there something that I need to be aware of?

[Dominaezzz]

Not that I can think of.

[leandro]

Thank you, that’s super helpful 🙏

[muliyul]

@Dominaezzz is your implementation better? why prefer it over suspendCancellableCoroutine?

[Dominaezzz]

Mostly to avoid calling auth.release() three times and the lateinit.
I also believe the contents of suspend*Coroutine should be brief/simple, this didn't seem to fit that.

[muliyul]

suspend fun isSessionValid(): Boolean = suspendCancellableCoroutine { continuation ->
    val callback = object : AuthHandler {
        override fun onSuccess(session: AuthUserSession) {
            continuation.resume(session.isValid)
        }
        override fun onFailure(e: Exception) {
            continuation.resumeWithException(e)
        }
    }
    val auth = builder.setAuthHandler(callback).build()
    auth.getSession()
    continuation.invokeOnCompletion { auth.release() }
}

Wouldn't that work?

[Dominaezzz]

https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-cancellable-continuation/index.html

Can't find that invoke on completion function.

[muliyul]

Maybe because it's experimental. Either way you can retrieve the Job instance and effectively achieve the same thing AFAIK.

coroutineContext.getValue(Job).invokeOnCompletion { auth.release() }