Also what happened to “asCompletableFuture” for Java interop ? is this still around?

Is runBlocking{} overhead important and is it a problem to use too many in an Android app? I have quite a few place in my app that require to return an answer synchronously because I'm extending API that call me on background thread and expect answers. The underlying question, is about the fact that I should keep some non suspend / synchronous functions for those case, or the overhead is so low that it's OK to have quite a few runBlocking and allow me to keep my internals simple and only support suspend functions?

Hi there! I'm just starting with Coroutines in Android and I don't even get Coroutines 101. Could someone please translate this simple Android snippet to Coroutines removing the callbacks? That would help me massively.

StuffRepo.kt
 
stuffDS.loadStuff (object: LoadStuffCallbacks {
    override fun onSuccess(stuff : Stuff) {
        // stuff ready
    }

    override fun onError() {
        // error handling
    }
})

StuffDS.kt

fun loadStuff(callbacks : LoadStuffCallbacks) {
    val stuff = dao.loadStuff()
    if (stuff != null) callbacks.onSuccess(stuff)
    else callbacks.onError()
}

interface LoadStuffCallbacks {
    fun onSuccess(stuff : Stuff)
    fun onError()
}

I'm trying to replicate exactly same behaviour eliminating completely the callbacks. Is it possible to do it? What's the cleanest way of doing this? Thanks a lot!

Hi there. What’s the difference between coroutine context and coroutine scope ?

Decided to write about several things which in my opinion you should and shouldn’t do (or at least try to avoid) when using Kotlin coroutines. Would appreciate if someone can check it and give a feedback. 😉 https://medium.com/@dmytrodanylyk/kotlin-coroutines-patterns-anti-patterns-f9d12984c68e

should I define empty error handler to avoid this? https://pl.kotl.in/Bk5wBif1N

anyone here that has a lot of experience with netty? We migrated a vertx+coroutine (kotlin 1.2.61-app) to ktor 1.0 and we are seeing some memory leakage. This is the visualvm images which I can’t really tell a lot from but the reason why I am asking about netty is the call-thread

Hi all! I'm writing some code using coroutines and wanted to make sure I wasn't using an antipattern:

class TSCompiler {
    private val dispatcher = Executors.newFixedThreadPool(24).asCoroutineDispatcher()

    public suspend fun compile(program: Any) = coroutineScope {
        launch(dispatcher) {
            // do something that takes awhile!
        }
    }
}

Would it be better in this case to just use the Executor directly, rather than using it as a coroutine Dispatcher?

I'm new to coroutines and need some help please. On coroutineContext I'm running one while loop (start function, with blocking api call) and also actor which serves to send packets (api call also). Are those api calls wait for each other or can they run in parallel? Sample code: https://goo.gl/a87Vs9

No url shorter ?

I am having a weird issue with testing Coroutines, converted to RxJava2 with

asSingle(CommonPool)

In a unit-test class, I have 2 different tests. Each one of them uses

test()

method from RxJava2 to assert the value Problem is, every time I run my tests, on of them fails, but only one of them. If I comment away one of the tests – the other one always passes. It feels like some threading issue, anybody had similar problems?

fun main() {
    runBlocking {
       val foo1 = withContext(IO) {
           delay(100)
           "foo1"
       }

       val fooDeferred = async(IO) {
            delay(100)
            "foo2"
       }

       val foo2 = fooDeferred.await()
       print("$foo1 and $foo2")
    }
}

^ can someone tell me, what the different here between

async(IO)

and

withContext(IO)

? only that async is deferred?

Hey folks, I'm seeing a weird crash while using coroutines, it's happening on Samsung devices running Android 5.0 only 🤔

Caused by java.lang.NoSuchFieldException: _decision
       at java.lang.Class.getDeclaredField(Class.java:929)
       at java.util.concurrent.atomic.AtomicIntegerFieldUpdater$AtomicIntegerFieldUpdaterImpl.(AtomicIntegerFieldUpdater.java:251)
       at java.util.concurrent.atomic.AtomicIntegerFieldUpdater.newUpdater(AtomicIntegerFieldUpdater.java:49)
       at kotlinx.coroutines.AbstractContinuation.(SourceFile)
       at kotlinx.coroutines.JobSupport.awaitSuspend(SourceFile:1095)
       at kotlinx.coroutines.JobSupport.awaitInternal$kotlinx_coroutines_core(SourceFile:1086)
       at kotlinx.coroutines.DeferredCoroutine.await$suspendImpl(SourceFile:99)
       at kotlinx.coroutines.DeferredCoroutine.await(SourceFile)
       at com.busuu.android.business.AppboyUtils$forceRegistration$1.invokeSuspend(SourceFile:23)
       at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(SourceFile:32)
       at kotlinx.coroutines.DispatchedTask.run(SourceFile:236)
       at android.os.Handler.handleCallback(Handler.java:739)
       at android.os.Handler.dispatchMessage(Handler.java:95)
       at android.os.Looper.loop(Looper.java:145)
       at android.app.ActivityThread.main(ActivityThread.java:5938)
       at java.lang.reflect.Method.invoke(Method.java)
       at java.lang.reflect.Method.invoke(Method.java:372)
       at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1400)
       at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1195)

Hi, we are currently rolling out an updated version of our android app, which contains an update for kotlin 1.2.71 -> 1.3.0 and coroutines 0.26.0 -> 1.0.1 . We observe unexpected crashes, that seem to somehow escape the try{}catch{} block. I described the problem and what I figured out so far here a bit more in detail: https://github.com/Kotlin/kotlinx.coroutines/issues/873 . I'm quite puzzled that some of the exceptions seem to be forwarded to the uncaught exception handler. And I'm unsure if our general approach is wrong or if this is a bug.

is there an easy way to synchronize a suspend function ?

Is there a way to check if a certain dispatcher is in

CoroutineContext

?

Are there kotlin with coroutine alternatives to https://github.com/graphql-java/java-dataloader? Would it add value?

does anyone know of any good talks that follows the lifecycle of a coroutine down to a kernal blocking call?

Is there anything that replaces it?

I've been trying to write a network storage access library and I have to admit the lack of suspending properties is making the syntax overly complex. I'd love to be able to do something like:

suspend val size: Long
    get() = remoteServer.getFileSize(this)

Instead, I'm stuck with this:

suspend fun getSize() = remoteServer.getFileSize(this)

So users have to do

file.getSize()

instead of just

file.size

😞 There's a discussion in the forums about this but there has been no interaction from the JetBrains team. Are there any plans to support this?

Hello, Maybe I missed it somewhere in the documentation, but I think I can’t find a proper way to suspend a

Job

forever - the only way to complete the

Job

would be through cancellation of its scope. I used the

delay(Long.MAX_VALUE)

to accomplish this, but this seems wrong. Basically, the function below returns a channel that keeps sending location-updates until its enclosing scope gets cancelled.

override fun CoroutineScope.publishLocations(): ReceiveChannel<Pair<Double, Double>> =
        Channel<Pair<Double, Double>>(capacity = Channel.CONFLATED).apply {
            val locationListener = locationListener {
                launch { send(it.latitude to it.longitude) }
            }

            launch {
                // locationListener keeps being called each time the phone's
                // location changes, and the locations are sent to `this` Channel over and over again.
                locationManager.requestLocationUpdates(5_000L, 0f, CRITERIA, locationListener, null)

                delay(Long.MAX_VALUE) // suspend forever ...
            }.invokeOnCompletion {
                // .. until the Job (its outer CoroutineScope) is cancelled.

                // Close this Channel
                close(it)
                // And stop the locationManager from sending additional updates.
                locationManager.removeUpdates(locationListener)
            }
        }

Is there a better alternative to creating a

Job

that suspends forever until it’s cancelled?

Why this code updates UI inside IO context and don't crash android app as expected?

GlobalScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) {
 textView.text = "New Text"
}

<http://Dispatchers.IO|Dispatchers.IO>

is a single threaded dispatcher, I believe, and the single thread in there is the IO thread. So the error is in the expectation.

So, here is a contrived example of my problem. I am testing suspending function that returns a channel. This function sends some number of items to the channel. If I launch the coroutine for sending items on the channel using the

coroutineScope{}

style of

method2

, sending is always suspended waiting on a receiver, but

method1

does not get suspended(blocked). As far as I can tell, both method 1 and method2 would launch using the same dispatcher (Dispatchers.IO), and that I'm not doing anything "wrong" per se, but clearly I am given I would expect

method1

to not get stuck.

What's the best way to adapt lambdas that are not inline and are not suspendable? e.g.

public inline fun CharSequence.replace(regex: Regex, noinline transform: (MatchResult) -> CharSequence): String

from the stdlib

Is there a way to print a coroutine job tree?

Hi guys, i’m writing a

startWith

extension on

ReceiveChannel

and i was wondering which is the best way to do that. I have currently 2 implementations:

suspend fun <A> ReceiveChannel<A>.startWith(element: A): ReceiveChannel<A> {
    val channel = Channel<A>()
    channel.offer(element)
    consumeEach { channel.send(it) }
    return channel
}

suspend fun <A> ReceiveChannel<A>.startWith(element: A, coroutineScope: CoroutineScope): ReceiveChannel<A> {
    return coroutineScope.produce {
        offer(element)
        this@startWith.consumeEach { this@produce.send(it) }
    }
}

I’m not sure what’s the difference is between the 2 and which is the best approach

If I make modifications (

add

,

remove

) on

MutableList

only in

actor

which runs in

Dispatcher.MAIN

, is it safe to call

contains

in other context (

<http://Dispatcher.IO|Dispatcher.IO>

) or should rather check that in

withContext(Main)

before sending to

actor

?