@rafal Yes, you can use coroutines 0.16 with any higher version of kotlin. Even though coroutines is an experimental feature, there is still a backwards compatibility guarantee.

@elizarov I get this error when executing 'apptransformClassesAndResourcesWithProguardForRelease' (proguard on release version of Android project)

when using kt

1.2-M1

(with

1.1.2-5

everything is ok)

@rafal You should use 1.2-M1 with 1.2-M1 kotlin-runtime. Your dependency on 0.16 kotlinx.coroutines is probably pulling dependency on kotlin-runtime 1.1.2. You should exclude that and replace it with 1.2-M1 kotlin-runtime.

@rafal You can add that warning to the ignore list for now, we'll fix it in the next releases: https://youtrack.jetbrains.com/issue/KT-18702

oh, thanks @ilya.gorbunov 🙂 I'll ignore it then

Would you recommend using coroutines for I/O operations?

@dekans You’d get best result if you use some non-blocking IO library for your I/O operations. In the end it all depends on what exactly you are trying to achieve

That's for my culture. I get that coroutines are perfect for network operations. I wondered about I/O

@dekans It depends on the type of the application you are working on. Most apps are not heavy disk I/O users and thus it is not important on how they work with disk (doing blocking I/O will be fine for most). However, if you are in a position that significant portion of your application’s time is spent on waiting (blocking) for disk I/O, then you might consider moving to non-blocking I/O.

@dekans To put it another way, the reason that many people look at coroutines for their network operations, is that modern apps spend significant amount of time waiting for network result. Doing this with blocking threads is expensive, so they move to async network operations, which are just cumbersome unless your language supports coroutines.

for now that's how I understand it

To put it in short: coroutines are great for anything if your application needs to wait for that quite often or for long periods of time.

actually, I'm an Android Dev and there is not really nio available

@dekans It is usually not a problem on Android. You can use IO libs that your blocking on inside but provide async API outside (like okhttp and others). This way you don’t have to manage threads, resources, and callbacks, but concentrate on writing nice and easy-to-read code with coroutines.

NIO is a must-have to handle thousands of connections. Unless you have that many, you don’t need NIO

Sure, but I have to do some IO ops myself. I'm the main dev of VLC on Android, we are always working with files

@dekans I see. I really not an expert on Adroid and I don’t know if it provides any non-blocking APIs for files.

So I get it off the main thread as much as I can. And coroutines seem great for that.

You can always write your own async file IO library using a bit of native code and JNI. All you need is to expose the corresponding posix apis.

@elizarov not really, it's basic threading 😕

JNI calls are not really cheap, that would ruin it, I think it's more efficient to use a threadpool for now.

So, coroutines seem promising for me 🙂

JNI is cheap when you do it in bulk. It is a Ok to use JNI to read the next available block of data from a file or other external device.

Again, I’m not an expert in the underlying architectural details on Android, so I don’t know if that even worth the effort there

You can alway “isolate” blocking code from non-blocking one using

run(context) { ... }

function

For any

blockingOperation

you can write the corresponding “non-blocking” wrapper that will be safe to use from UI thread:

looking for

run

doc