Programming Android with Kotlin

Chapter 6. Handling Concurrency Using Callbacks

The idiomatic way of handling concurrency in Kotlin is by using coroutines. However, for some time this has been done in Java using threads and callbacks. So why do we need coroutines?

To answer this question, we will revisit a typical Kotlin implementation on Android and discuss the pitfalls of using threads. Knowing the weak points of the traditional approach is the key to understanding the motivation behind the design of coroutines.

In Android applications, long-running tasks shouldn’t be done on the UI thread, as you’ve seen in the previous chapter. If you block the main thread—the UI thread—your app might not have the resources it needs to draw the screen or update it appropriately. In fact, lint will complain if you attempt to do an obvious IO call (e.g., make an HTTP connection) while on the UI thread.

An Android application runs smoothly when the main thread completes all its tasks in less than frame time, which is 16 ms on most devices. This is a rather short amount of time, and all blocking calls, like network requests (blocking IO), should be performed on a background thread.¹

When you delegate a task to another thread, you typically call a function which starts the asynchronous job. In some cases this is “fire-and-forget,” but you’re usually waiting for a result—and you need to act on it. This is done by providing a function which will be called once the job finishes. This function is called a callback. A callback often ...