DEV Community: Jin Lee

Combining Mutex with suspendCancellableCoroutine in Kotlin

Jin Lee — Thu, 28 Aug 2025 01:49:16 +0000

Recently I saw an interesting combination usage of Mutex and suspendCancellableCoroutine. This combination produces queue-like behaviour where it processes one-at-a-time in FIFO order even though there is no pop() / peek() or explicit queue data structure.

If you have used Snackbar in Jetpack Compose, you have experienced this combination already (link). SnackbarHostState.showSnackbar() is suspending and ensures only one snackbar is shown at a time.

suspend fun showSnackbar(
    message: String,
    actionLabel: String? = null,
    duration: SnackbarDuration = SnackbarDuration.Short,
): SnackbarResult =
    mutex.withLock {
        try {
            return suspendCancellableCoroutine { continuation ->
                currentSnackbarData =
                    SnackbarDataImpl(message, actionLabel, duration, continuation)
            }
        } finally {
            currentSnackbarData = null
        }
    }

Mutex.withLock { ... } ensures only one caller enters the block at a time; other callers suspend and will continue in FIFO order.
suspendCancellableCoroutine { continuation -> ... }: suspends the caller and hands you a Continuation. Later, when the snackbar is dismissed or its action is pressed, the implementation calls continuation.resume(result) to wake the suspended caller with a SnackbarResult. If the job is cancelled meanwhile, the continuation is cancelled promptly.

Combining these, we have a queue behaviour allowing single operation (in this case snackbar) to be shown on the screen. This pairing feels like a queue because the first call must complete before the next call proceeds. However, it’s important this is not same as java.util.Queue we have seen on Java. (link)

Exploring the when guards feature in Kotlin 2.1

Jin Lee — Sun, 05 Jan 2025 03:26:26 +0000

When I heard about guard in Kotlin 2.1 announcement, I was confused. Why do we even need this? Isn't a simple if/return enough?

fun foo(data: Data) {
    if (!data.valid) {
        return
    }
    // foo main logic
}

Or is it similar to Swift guard?

func foo(data: Data) {
    guard let isValid = data.valid, isValid else {
        return
    }
    // foo main logic
}

I had to re-read the new feature name and it's actually called when guards. I told myself stop just reading the keyword and look deeper into what it offers

What is `when guards` Feature?

According to Kotlin doc:

Starting from 2.1.0, you can use guard conditions in when expressions or statements with subjects.
Guard conditions allow you to include more than one condition for the branches of a when expression, making complex control flows more explicit and concise as well as flattening the code structure.

This means you can replace nested conditions in a when branch with a flatter, more readable structure. It's a great way to improve code clarity and reduce unnecessary indentation(s). Let's take a look at an example to demonstrate this.

Prerequisite

But first you need to upgrade your Kotlin to the 2.1.0 (or later) and enable the experimental feature by adding the following compiler flag to your build.gradle.kts file:

kotlin {
    compilerOptions {
        freeCompilerArgs.add("-Xwhen-guards")
   }
}

Otherwise you will run into a compiler error asking you to add the compiler flag

The feature "when guards" is experimental and should be enabled explicitly

Silly Example

Imagine you have when statement with a sealed class as a subject and you want to generate different string value depending on the subject's class type:

sealed class Dessert {
    data class CheeseCake(val type: Type): Dessert() {
        enum class Type {
            NEW_YORK,
            JAPANESE,
            NORMAL,
        }
    }
    object Kitkat: Dessert()
    class Oreo(): Dessert()
}

fun foo(dessert: Dessert) {
    when(dessert) {
        is Dessert.CheeseCake -> "This is cheesecake"
        Dessert.Kitkat -> "This is Kitkat"
        is Dessert.Oreo -> "This is Oreo"
    }
}

Straightforward, right? But what if you want more granular logic for CheeseCake, such as displaying a special message for the NEW_YORK type? Before Kotlin 2.1, this would look like:

fun foo(dessert: Dessert) {
    when(dessert) {
        is Dessert.CheeseCake -> {
            if (dessert.type == Type.NEW_YORK) {
                "This is my favorite cheesecake"
            } else {
                "This is cheesecake"
            }
        }
        Dessert.Kitkat -> "This is Kitkat"
        is Dessert.Oreo -> "This is Oreo"
    }
}

With more complex conditions, this structure quickly becomes cluttered.

Simplifying with `when guards`

This is where the new feature comes in (Btw it's not actual guard keyword but concept). Instead of having this nested block of code, we can rewrite this into:

when (dessert) {
        is Dessert.CheeseCake if dessert.type == Type.NEW_YORK -> "This is my favorite cheesecake"
        Dessert.Kitkat -> "This is Kitkat"
        is Dessert.Oreo -> "This is Oreo"
        is Dessert.CheeseCake -> "This is cheesecake"
    }

This is cool and looks a lot nicer than before but you might want to ask yourself what if we don't use subject for when statement and achieve the same thing? It would look something like this:

    when {
        dessert is Dessert.CheeseCake && dessert.type == Type.NEW_YORK -> "This is my favorite cheesecake"
        dessert is Dessert.CheeseCake -> "This is cheesecake"
        dessert is Dessert.Kitkat -> "This is Kitkat"
        dessert is Dessert.Oreo -> "This is Oreo"
    }

This works well but does have downsides. Not only Repeating dessert is checks makes the code verbose, but using when as an expression requires an else branch:

fun foo(dessert: Dessert): String {
    return when {
        dessert is Dessert.CheeseCake && dessert.type == Type.NEW_YORK -> "This is my favorite cheesecake"
        dessert is Dessert.CheeseCake -> "This is cheesecake"
        dessert is Dessert.Kitkat -> "This is Kitkat"
        dessert is Dessert.Oreo -> "This is Oreo"
        else -> "This is dessert" // Required by the compiler
    }
}

Adding an else branch for unreachable cases feels redundant and clutters the code.

With this new guard feature, the final code would look like this:

fun foo(dessert: Dessert): String {
    return when (dessert) {
        is Dessert.CheeseCake if dessert.type == Type.NEW_YORK -> "This is my favorite cheesecake"
        Dessert.Kitkat -> "This is Kitkat"
        is Dessert.Oreo -> "This is Oreo"
        is Dessert.CheeseCake -> "This is cheesecake"
    }
}

This approach is concise, readable, and avoids unnecessary branching. If you’ve struggled with tools like Detekt complaining about nested blocks, try this feature out!

Further resources

A random annotation I found on androidx.annotation

Jin Lee — Sat, 14 Dec 2024 05:18:00 +0000

While working on an Android app, I found an interesting annotation called @ChecksSdkIntAtLeast. I had no idea this annotation existed under the androidx.annotation package. I got curious and started looking into how it works.

Simple way

It looks like the most simplest way of using this annotation is to use api parameters like so (source):

@ChecksSdkIntAtLeast(api = Build. VERSION_CODES. O) 
public static boolean isAtLeastO() {     
    return Build. VERSION. SDK_INT >= 26; 
}

But I thought maybe we can reuse this into class and able to inject places where we need to.

Classy way

To make this logic somewhat reusable, I created an interface and its concrete implementation:

interface DeviceVersion {
    @ChecksSdkIntAtLeast(parameter = 0)
    fun isAtLeast(osLevel: Int): Boolean
}

class RealDeviceVersion : DeviceVersion {
    override fun isAtLeast(osLevel: Int): Boolean {
        return Build.VERSION.SDK_INT >= osLevel
    }
}

Here, the DeviceVersion interface provides a method isAtLeast(osLevel: Int) has the @ChecksSdkIntAtLeast while RealDeviceVersion has the OS level checking logic. When injected linter will understand that DeviceVersion#isAtLeast has done the appropriate OS level checking logic. (Probably a good idea to add some unit tests around here! 👀)

Practical (sort of...) Example

Imagine you have a class that includes methods restricted to certain API levels, like this (Apology for the class/method names):

class SomeAPIRestrictedMethodClass {
    @RequiresApi(34)
    fun fooFor34() {
        // Some operation requires SDK 30
    }

    fun fooForAll() {
        // Some operation for all SDK
    }
}

When calling fooFor34 method which can only be used for API 34 or above, you would typically do a check like this:

if (Build.VERSION.SDK_INT > 34) {
    someAPIRestrictedMethodClass.fooFor34()
}

With the DeviceVersion interface, you can achieve the same result more cleanly:

if (deviceVersion.isAtLeast(34)) {
    someAPIRestrictClass.fooFor34()
}

This approach could help with the unit testing if you somehow can't run AndroidTestRunner or RobolectricTestRunner for some classes/methods. Plus, the linter doesn't seem to complain about this usage!

I just found this super interesting annotation since I have not seen it before. I hope you enjoyed learning about this as much as I did. If you have encountered unique annotations feel free to share them on the comment section and have a great day!

🧀

Diving into Kotlin .apply{} function

Jin Lee — Fri, 08 Dec 2023 06:27:22 +0000

Background

Since I started using Kotlin for Android development in 2017, I've been using functions like apply, let, also, and run. These functions are super handy and make my code much easier to read. But here's the thing: How exactly do they work? What makes them so special?

High-order functions

According to the Kotlin doc:

A higher-order function is a function that takes functions as parameters, or returns a function.

Higher-order functions aren't something new in the programming world; yes, even in Java, they've been around since version 8, iirc. They promote reusability and conciseness. They've also unlocked easier implementations like .apply{} (the function we're delving into today) as well as famous asynchronous libraries such as Coroutines.

So enough about the background, let's look at some code.

Inside apply.{} function

As I'm writing this, I was using kotlin-stdlib-common-1.9.0

@kotlin.internal.InlineOnly
public inline fun <T> T.apply(block: T.() -> Unit): T {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    block()
    return this
}

There are three components I want to talk about which are:

inline keyword
contract
Function literals with receiver

inline keyword

So, when we use the inline keyword, we are telling the compiler to swap out the call-site with the actual code of the inline function. This little trick is to cut down on the extra work that high-order functions bring during the runtime phase. High-order functions aren't as lightweight as regular functions.

To illustrate how inline keyword work, let's take a look at javabyte code when the keyword is used:

inline fun foo1(block:() -> Unit) {
    print("Starting foo1 now!")
    block()
    print("Finished foo1!")
}

fun foo2(block:() -> Unit) {
    print("Starting foo2 now!")
    block()
    print("Finished foo2!")
}

And the main function that calls this method:

fun main(args: Array<String>) {
    print("Cheesy Coder")
    foo1 {
        print("I am running foo1 now!")
    }
    foo2 {
        print("I am running foo2 now!")
    }
}

Now, let's look at what the Java bytecode says (I will only display what matters the most since I want to make comparison between these two methods)

public final static main([Ljava/lang/String;)V
// Skipping until interesting part
   L1
    LINENUMBER 2 L1
    LDC "Cheesy Coder"
    ASTORE 1
   L2
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 1
    INVOKEVIRTUAL java/io/PrintStream.print (Ljava/lang/Object;)V
   L3
   L4
    LINENUMBER 3 L4
   L5
    ICONST_0
    ISTORE 1
   L6
    LINENUMBER 22 L6
    LDC "Starting foo1 now!"
    ASTORE 2
   L7
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 2
    INVOKEVIRTUAL java/io/PrintStream.print (Ljava/lang/Object;)V
// Skipping until interesting part

   L17
    LINENUMBER 24 L17
    LDC "Finished foo1!"
    ASTORE 2
   L18
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 2
    INVOKEVIRTUAL java/io/PrintStream.print (Ljava/lang/Object;)V
   L19
   L20
    LINENUMBER 25 L20
    NOP
   L21
    LINENUMBER 6 L21
    GETSTATIC MainKt$main$2.INSTANCE : LMainKt$main$2;
    CHECKCAST kotlin/jvm/functions/Function0
    INVOKESTATIC MainKt.foo2 (Lkotlin/jvm/functions/Function0;)V
   L22
    LINENUMBER 9 L22
    RETURN

The Java bytecode appears distinct when the inline keyword is used. Instead of invoking foo1 within the main function, the implementation contents of foo1 have been copied into the main function. Labels L1 and L2 illustrate the loading of the 'Cheesy Coder' string and the use of java/io/PrintStream to print the loaded string. Labels L6 and L7 represent the loading of the 'Starting foo1 now!' string and its subsequent printing. There is no mention of the reference to foo1 method anywhere in this code. However, upon encountering L21, the instruction is to invoke foo2 method.

Not only that but there are more Java bytecode created around foo2:

public final static foo2(Lkotlin/jvm/functions/Function0;)V
// Skipping implementation

final class MainKt$main$2 extends kotlin/jvm/internal/Lambda implements kotlin/jvm/functions/Function0 {


  // access flags 0x1041
  public synthetic bridge invoke()Ljava/lang/Object;
    ALOAD 0
    INVOKEVIRTUAL MainKt$main$2.invoke ()V
    GETSTATIC kotlin/Unit.INSTANCE : Lkotlin/Unit;
    ARETURN
    MAXSTACK = 1
    MAXLOCALS = 1

  // access flags 0x11
  public final invoke()V
   L0
    LINENUMBER 7 L0
    LDC "I am running foo2 now!"
    ASTORE 1

// Skipping implementation

This represents the overhead cost. Not only foo2 method was created but an additional class is also generated for its parameters. It's very interesting to see how the Java bytecode demonstrates the impact of the inline keyword!

Contract

This API reminds me of require or requireNonNull. I have seen these kind of checks in many different codebase and it can sometimes assure developers certain conditions are met.

Unlike above, contract tells information or hints to the compiler so that it can make informed decision how smartcast works or give warning to developers. In this function .apply{}, the contract is called callsInPlace.

According to Kotlin docs:

Specifies that the function parameter lambda is invoked in place.
This contract specifies that:

the function lambda can only be invoked during the call of the owner function, and it won't be invoked after that owner function call is completed;

(optionally) the function lambda is invoked the amount of times specified by the kind parameter, see the InvocationKind enum for possible values. A function declaring the callsInPlace effect must be inline.

It's a bit difficult to understand so let's use real example and see the behavior. We are going to create very simple methods called foo1 & foo2:

@ExperimentalContracts
inline fun foo1(condition: Boolean, block: () -> Unit) {
    contract { callsInPlace(block, InvocationKind.UNKNOWN) }
    if (condition) {
        block()
    }
}

@ExperimentalContracts
inline fun foo2(condition: Boolean, block: () -> Unit) {
    contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) }
    if (condition) {
        block()
    }
}

I added condition boolean parameter so that it does not take in account of how many times block is called on runtime. Let's test out foo1 first:

@OptIn(ExperimentalContracts::class)
fun main(args: Array<String>) {
    val someInput: Int
    foo1(false) {
        someInput = 10
    }
    print(someInput)
}

The code itself may not be interesting so let me include the screenshot of IDE:

Because we told the compiler that block() parameter is called unknown amount (could not be called), the compiler thinks that someInput may not be initialized or it's called many times that val cannot be re-assigned to a new value.

What about foo2?

@OptIn(ExperimentalContracts::class)
fun main(args: Array<String>) {
    val someInput: Int
    foo2(false) {
        someInput = 10
    }
    print(someInput)
}

It looks like foo2 has no problem even though we know val someInput would not be initialized. What happens if we run this method?

0
Process finished with exit code 0

It appears that the Kotlin compiler might utilize default values to prevent the application from encountering errors or crashing. Typically, this operation might not be feasible, but by using contracts, we can notify the compiler about the state of the called block.

In essence, when the .apply{} function is invoked, the compiler explicitly acknowledges that the block has been called and respects whatever operations occur within the caller.

There are many different contracts so check out if you have some free time.

Function literals with receiver

This is the main part of the .apply{} function. Initially, looking at this function made me scratch my head. However, once we understand extension functions, it becomes really easy to grasp.

Extension functions seamlessly add functionality without requiring modifications to the class.

fun String.printWithCheese() {
    println("$this Cheese. Prefix length ${this.length}")
}

fun main(args: Array<String>) {
    "my".printWithCheese()
}

We can add the class with new methods that we want to implement without altering the source code (as shown in this example with the String class).

By using this knowledge of extension functions, we can observe that the block parameter data type in the apply{} function is T.() -> Unit. This data type translates as "Here is the lambda function that has a receiver type, T." It utilizes the same concept as extension functions, allowing access to and modification of member instances.

If we were to look at .run{} implementation, we can also observe something similar:

@kotlin.internal.InlineOnly
public inline fun <T, R> T.run(block: T.() -> R): R {
    contract {
        callsInPlace(block, InvocationKind.EXACTLY_ONCE)
    }
    return block()
}

The only difference is the return type for this lambda functions, R. .run{} uses result from the block and return it as its return type.

Conclusion

I hope you enjoyed diving into .apply{} method and seeing many different components played out in just one simple call. I am amazed by the growth of Kotlin over the years and hope to cover more Kotlin-related topics in the future.