```suspend fun requestStepsActivity(): List<Something> = suspendCancellableCoroutine { emitter...

# coroutines

[myanmarking]

suspend fun requestStepsActivity(): List<Something> = suspendCancellableCoroutine { emitter ->
    val listener = object : SimpleEventListener() {
        override fun onSent() {
            emitter.resume(Something)
        }
        override fun onFailedSending() {
            emitter.resumeWithException(RuntimeException())
        }
    }

    try {
        someApi.addListener(listener)
        someApi.requestData()
    } catch (e: Throwable) {
        emitter.resumeWithException(e)
    } finally {
        someApi.removeListener(listener)
    }
}

[Matej Drobnič]

I think you just have to call removeListener in both onSent and onFailedSending

[myanmarking]

and catch as well. and i must also include a cancelation callback and clean there also

[myanmarking]

that why my question:P

[Matej Drobnič]

can requestData throw exception though?

[myanmarking]

suspend fun requestStepsActivity(): List<Something> = suspendCancellableCoroutine { emitter ->
    val listener = object : SimpleEventListener() {
        override fun onSent() {
            cleanUp()
            emitter.resume(Something)
        }
        override fun onFailedSending() {
            cleanUp()
            emitter.resumeWithException(RuntimeException())
        }
    }

    emitter.invokeOnCancellation { cleanUp() }

    try {
        someApi.addListener(listener)
        someApi.requestData()
    } catch (e: Throwable) {
        cleanUp()
        emitter.resumeWithException(e)
    }
    
    fun cleanUp(){
        someApi.removeListener(listener)
    }
}

so the full code must be like this ?

[myanmarking]

its a bit tedius

[Matej Drobnič]

it seems redundant for an API to throw exception through both listener and through regular throw

[myanmarking]

ya, i guess that is not necessary

[myanmarking]

but then i would need cancelation as well right ?

[Matej Drobnič]

yes

[Matej Drobnič]

also depending on the API you might not need callbacks in sent/failed.

[Matej Drobnič]

If the API is one-shot then those callbacks would be dead anyway

[myanmarking]

what do you mean ?

[Matej Drobnič]

well it depends on what someApi does

[myanmarking]

it returns data or an error

[Matej Drobnič]

if someApi object is only used once, then you do not need to remove listener after success/error

[Matej Drobnič]

since that listener will never be used anyway

[myanmarking]

well, i do not know what the api does. but its safer to remove to avoid a leak i guess

[Matej Drobnič]

there shouldn't be any leaks since you only reference emitter from the listener

[myanmarking]

i mean, the SimpleEventListener can leak in the api if not removed, not the emitter

[Matej Drobnič]

I guess all of that depends if you trust the API author

[Matej Drobnič]

most APIs work by merging both into requestData(listener) though. Your example design looks a bit odd to me, unless listener can survive through multiple requestData calls, in case I think there are bigger issues.

[myanmarking]

ya, its kinda bad

[myanmarking]

there are two listener, one passed as argument that will forward success/error cases. but then there is an external global listener, than forwards the data

[myanmarking]

anyway, thanks for help 😛

[Matej Drobnič]

np