Photo by Adrien Delforge on Unsplash

The code for the main activity is also given. It’s standard, and I won’t need much explanation for you to understand it, but I’ll still leave a couple of comments.

• this.runOnUiThread allows you to run code on the main thread.
• measureTimedValue is a helper function that will allow us to measure the execution time of the code.

In this example, we run a long-running synchronous task on the main thread and want to get the result, which we’ll display in a toast. At the same time, we’ll log some information about the execution of the code.

If we look at the log, we’ll see that it took 9685.0434 ms to receive the data, and all this time, the main thread was blocked.

This example was useful to us in order to once again reinforce the information that you never need to run long synchronous operations on the main thread.

But what if we execute the code in the background thread? Perhaps this will be a solution, and we won’t need Kotin Coroutines. We’ll see if this is true using another example.

In this example, all the code remains the same, but the thread on which we run it has changed; in this case, it is the background thread.

As we’ll see from the log, the main thread was not blocked, and the data was received. We can be happy, but no. When using this approach, we again encountered a problem since, as indicated above, interaction with user interface elements should occur exclusively on the main thread. Naturally, we received an exception, and the application crashed.

In the code below, we create a coroutine scope and run the code inside the coroutine builder. More information about launching coroutines can be found at the link.

In this example, we launched a coroutine in a background thread and tried, as in the example with threads, to receive data and use it when displaying toast. But coroutines are not a workaround compared to threads. We tried to do the same thing in terms of interacting with a UI element from a background thread, and naturally, we got the same result with an exception and the application crashing.

The full power of coroutines will be demonstrated when we execute code on the main thread in the following example. We’ll start receiving data in a separate background thread and, having received the data, display the toast in the main thread. In this case, our code will be written in a procedural style and will be executed sequentially, step by step, inside the coroutine.

We’ll change our function a little by adding the suspend keyword. This is a kind of marker for Kotlin, by which it understands that this function will suspend the coroutine.

As I wrote above, we’ll send the code to be executed in the background thread. The withContext(Dispatchers.IO) function will allow us to do this. You can read more about this function here. But we still want to display the Toast with the results of the work on the UI thread.

All our code remains the same, but in the coroutine scope constructor, we’ll place a dispatcher responsible for running code on the main thread: Dispatchers.Main.

FYI, if you use lifecycleScope or viewModelScope, they also internally use the main thread dispatcher. For the example below I will provide the code for lifecycleScope and you will see it.

Below is a log of the results of our code.

The code is quite simple, which is good because it will allow you to better understand the topic, especially if you are taking your first steps in this direction.

Now we’ll look on decompiled Kotlin Bytecode. I specifically removed all the code and left only the functions that are called in it.

The invoke function will be called first. It’ll be launched by the CoroutineStart class inside the launch function.

The invoke function takes the suspend function and an instance of the Continuation class as input parameters. We’ll talk about this class in more detail, but for now, here is what you need to know: there are two objects that will be used when running code inside the coroutine.

We need to go back and look at the decompiled Kotlin Bytecode for the invoke function. There, we will find these two objects. If we compare, we get:

• Object var1 is block: suspend() -> T
• Object var2 is completion: Continuation<T>

As we remember, a total of three functions were called in the coroutine, and we looked at one of them. In turn, the remaining two functions will be called inside the invoke function: create and invokeSuspend.

A closer look shows that the create function forms an object of the Continuation class.

Moreover, this function is contained in the base class Continuation. And not only this, but, as we’ll see, the invokeSuspend function, which we’ll look at a bit later.

And finally, the third function that will be called when the Continuation class object is created is invokeSuspend. It contains all the code that the coroutine should execute. As we already understood, this function will be called by an object of the Continuation class when the coroutine starts.

The main purpose of the Continuation class is to ensure that the user interface operation (in our case, showing toast) is performed only after receiving the result of the asynchronous operation of our receiveData function. To do this, the code inside the invokeSuspend function will be split into parts, and a label variable will be added to switch between pieces of code.

There are two objects inside: Object var3 and Object var10000. In Object var10000 will be put the result of the suspended function work, and Object var3 contains a special constant: COROUTINE_SUSPENDED.

The point where the code splits into two parts is the suspend function. It and all the code before it will go into the first part. And all the code after it is in the second. Now, when calling the invokeSuspend function, the label variable will determine which part of the code will be executed. If label is 0, then the first part of the code (our receiveData function) will be executed, and if label is 1, then the second part of the code will be executed, where the result of the work will be written to the variable var10000 and then used for display in toast.

As we figured out, the invokeSuspend function will be called for the first time at the start of the coroutine and will execute the first part of the code in case = 0, which will launch the suspend function, and the invokeSuspend function will complete (return).

Before calling the suspend function, a new value of 1 will be written to the label. This is necessary so that when the result is received, the second block of code from case 1 will start working.

But a logical question arises: how will the function be called if it has completed its work?

Note that the receiveData function accepts this as a parameter. That is, the object of the Continuation class itself is passed to the suspend function.

When the suspend function finishes its work, it will take the Continuation object that was passed to it and call its invokeSuspend function. Since the value of label was previously replaced by 1, when invokeSuspend starts running again, the second part of the code from case 1 will be executed.

Actually, only two results can come from the suspend function.

• The first one is the return of the COROUTINE_SUSPENDED constant that was mentioned before. It means that the suspend function has not completed its work. In this case, the invokeSuspend function will be completed again (return). This will continue until the second possible option comes from the suspend function.
• The second one is if some value other than the COROUTINE_SUSPENDED constant is returned. This will be the result of the suspend function. The code will continue.

In case 1, the result of the suspend function will be written to the var10000 variable, and then the code will continue its execution. This variable, as we see in the code below, is used to display the toast, after which the function will complete its work.

This article was previously published on proandroiddev.com