Mark Murphy

The ideal type of function in functional programming is a “pure” function. A pure function has no side effects, such as changing the contents of a database. If you call a pure function one million times with the same input, you should get the same output each of those million times.

Functional programming also emphasizes function composition, using “higher-order” functions. For example, you might have a sort() function that can sort some collection of data. However, sort() itself needs be supplied not only with the data but with some other function that knows how to compare two data elements to determine their order. sort(), therefore, might take two parameters:

The data to be sorted
Some identifier or reference to the function to use for order comparison
In this case, sort() is considered to be a “higher-order” function, as it takes another function as a parameter to help define the overall work to be performed.

In Android, JavaFx, and other GUI environments, updates to the UI are single-threaded, with a specific thread being responsible for those updates. Typically, we have to do any substantial work on background threads, so we do not tie up the UI thread and prevent it from updating the UI.

Callbacks are simply objects representing chunks of code to be invoked when a certain condition occurs. In the case of asynchronous operations, the “certain condition” often is “when the operation completes, successfully or with an error”.

“Callback hell” occurs when you have lots of nested callbacks, such as this Java snippet:

The ugliness comes from the challenges in following the execution flow through layers upon layers of callbacks. Ideally, the syntax for our code would not be inextricably tied to the threading model of our code.

If doSomething(), doTheNextThing(), and doSomethingElse() all employ coroutines, our code invoking those functions could look something like this:

someCoroutineScope.launch {
doSomething()
try {
val result = doSomethingElse(doTheNextThing())
// TODO
} catch (t: Throwable) {
// TODO
}
}
There is a lot of “plumbing” in Kotlin — both in the language and in libraries — that makes this simple syntax possible. We, as users of Kotlin, get to enjoy the simple syntax.

While one element of coroutines (the suspend keyword) is part of the language, the rest comes from libraries. You will need to add these libraries to your project in order to be able to use coroutines. Exactly how you add these libraries will depend a lot on your project type and the build system that you are using.

Note that these versions are somewhat independent of the overall Kotlin version (1.4).

For an Android project, you would want to add a dependency on org.jetbrains.kotlinx:kotlinx-coroutines-android. This has transitive dependencies to pull in the core coroutines code, plus it has Android-specific elements.

Primarily, a CoroutineScope is responsible for canceling and cleaning up coroutines when the CoroutineScope is no longer needed. GlobalScope will be set up to support the longest practical lifetime: the lifetime of the process that is running the Kotlin code.