This is the story of how I came to draw a chessboard pattern in VectorDrawable format using Kotlin code, and how I ended up with a file 5x smaller than I initially had. I had a lot of fun (and a bit of fun) doing it, so I want to share it with you.

Why

For my Wear OS app that I'll publish on the Play Store soon, I need 3 variants of the same app:

1. The debug variant
2. A minified variant that I can sign an update locally, for performance tests
3. The Play Store variant, that Google will sign with a key I don't have

To easily distinguish these 3 apps on my test devices, I know 2 solutions:

1. Adding a prefix letter/sign in the app name for the non-published variants
2. Have a visual mark on the icon of the non-published variants

I used the first approach successfully in my previous job, but this time, I felt like trying the distinctive icon approach. I decided I would use a colored chessboard pattern for my debug and minified variants that I won't publish. Since the devices I'll regularly test on are all running Android 8 or later (API 26+), I can simply leverage adaptive icons where you can point to a buildType dependent resource for the background of the icon.

VectorDrawables in a nutshell

Great! Now, I wanted to get the chessboard pattern. VectorDrawables which can be defined in XML and referenced in an adaptive icon sounded like the most straightforward option to get a nice result. Since a chessboard pattern is only made out of squares, I thought I would not need to use a vector graphics tool like Affinity Design, Sketch, Adobe Illustrator or Inkscape. Instead, I could write the drawing commands directly and ensure I'd get the most optimized result, decreasing the GPU/CPU load.

In my previous job, I have been learning a bit about how to write SVG path data myself so I could make the flag of Catalonia. It's actually very easy if you only do straight lines. It's only a few abbreviations/substitutes to learn for "move", "horizontal (line)", "vertical (line)", and "line". They are respectively "M", "H", "V", and "L" for absolute positions, and if you switch to lowercase, you have it for relative positions. And there's the z character that means "close the path with a straight line if needed".

For example, here's how to draw a rectangle of 2x1: M0,0 H2 V1 H0 V0 z. In plain English, here's what it means: Move to 0,0 (which is the top left corner) and start drawing, horizontal line to 2 (x axis), vertical line to 1 (y axis), horizontal line to 0 (x axis again), vertical line to 0 (y axis again), and finally close the path. If you take a pen and follow these instructions on a piece of paper, you'll see you have just been drawing a 2x1 rectangle as advertised. Note that the spaces are all optional, so we can write M0,0H2V1H0V0z, and save 5 bytes, which is 27.77% since we had 18 bytes with the spaces. Conversely, adding these 5 bytes to the 13 means growing the size of 38.46%. Anyway, you'll see later on why the size matters.

From boring, to warning

I started to draw my chessboard pattern by hand happily, and within a few seconds, an intense feeling of boredom started to gain me as I was making plenty of errors and progressing very slowly. I didn't let it kill the idea. Instead, I did "File > New > Scratch File" in Android Studio (also works in IntelliJ IDEA), selected Kotlin, and started leveraging software to do this cumbersome task. Within 2 minutes, I wrote 2 for loops in a buildString { … }, and it seemed to generate what I was looking for. I copied it in the pathData of the VectorDrawable I had started writing by hand, and after 1 or 2 fixes, plus a size change, it was showing exactly what I wanted… and an extra thing, a warning from the IDE.

Very long vector path (1504 characters), which is bad for performance. Considering reducing precision, removing minor details or rasterizing vector.

(yes, it should be "Consider", without "ing)

I understood this could affect the device performance when it would draw the icon, something I definitely don't want to cause.

Here's the initial code that I had written for boxes of size 2:

fun generateChessboardPattern1(size: Int): String = buildString {
    for (x in 0 until size step 2) {
        for (y in 0 until size step 2) {
            if ((x - y) % 4 != 0) continue
            append("M$x,${y}H${x + 2}V${y + 2}H${x}z")
        }
    }
}

As you can see, for every box that needs to be drawn, it adds something like that: Mx,yHaVbHcz. That is at least 11 characters per box, and on a 14x14 grid (28x28 with boxes of 2x2 technically), it quickly grew beyond the kilobyte worth of vector drawing instructions.

I didn't want to go raster, and I wanted to keep the same grid size, so I looked for ways I could end up with the same result while having less instructions.

Iterating on optimizations

Minimizing the move commands

In the previous approach, the move command (Mx,y) accounted for 4 characters, or about a third of the entire command, so my first thought was to reduce these calls. With the code just below, I now get only one every 2 lines instead of for every box to fill:

fun generateChessboardPattern2(size: Int): String = buildString {
    check(size % 4 == 0) { "Size must be a multiple of 4" }
    for (y in 0 until size step 4) {
        append("M0,$y")
        for (x in 0 until size step 4) {
            append('H'); append(x + 2)
            append('V'); append(y + 4)
            append('H'); append(x + 4)
            append('V'); append(y)
        }
        append('V'); append(y + 2)
        append('H'); append(0)
        append('V'); append(y)
        append("z ")
    }
}

Of course, it introduced a new restriction: the size now had to be a multiple of 4. That was fine for me as it would not be customer facing. However, I was thinking I could do better.

Removing the move commands altogether

First, I asked myself: "Can I draw that chessboard with just a single path?"

During my experiments, I had found out that lowercase h and v commands were relative position variants, which made it much easier to experiment manually right in the XML.

I tried the simplest version that would answer my question.

This is the path data I got: M0,0h2v4h2V2H0z, and this is what I was seeing in the IDE:

Then, I wanted to see what would happen if I removed the leading M0,0. The preview didn't change a bit. I tried breaking the thing (successfully) and when I reverted the bad things I had just done: it was showing the right thing again. I just realized that any path would start at 0,0 by default, which is exactly where I need to start for my use case!

Here is the complete VectorDrawable if you want to try for yourself in an actual Android Studio project.

<?xml version="1.0" encoding="utf-8"?>
<vector xmlns:android="http://schemas.android.com/apk/res/android"
    android:width="108dp"
    android:height="108dp"
    android:viewportWidth="4"
    android:viewportHeight="4">
    <path
        android:fillColor="#C0C0"
        android:pathData="h2v4h2V2H0z"
        android:strokeWidth="0.3"
        android:strokeColor="#0F0" />
</vector>

The 2x2 grid (or 4x4 here, technically) seemed like a special case, and I was wondering what would happen for the filling for the boxes that I wanted empty that would be surrounded by boxes I wanted filled. Would they be filled as well, or would they be empty as I wanted?

I continued manually, and step by step, I got the following path data: h2v8h2V0h2v8h2 v-2H0v-2h8v-2H0z, which was fortunately exactly the result I was looking for:

Then I went to write the code, and also designed the function so it was supporting a variable box size, and so it could evolve to support rectangle boards as well as rectangle boxes. It's missing a few preconditions, for example to reject a boxSize that is greater than the size, but it's only run locally on my dev machine here, I don't see why I would try such a thing.

Instead of drawing the boxes one by one, or 2 lines by 2 lines with nested for loops, it draws the vertical lines, and then, draws the horizontal lines before closing the path.

The previous implementation had a quadratic complexity, and the result had a size that would grow a lot with the grid size, while the one below has a linear complexity, with a result that grows only linearly with the size as well.

Here is the code:

fun Int.isOdd() = this % 2 != 0 // It's odd that this isn't built into Kotlin, isn't it?

fun generateChessboardPattern3(
    size: Int,
    boxSize: Int
): String = buildString {
    val boxWidth = boxSize
    val boxHeight = boxSize
    val width = size
    val height = size
    for (x in 0 until width step boxWidth) {
        append("h${boxWidth}")
        if (x + boxWidth == width) break // Don't draw the last line.
        val verticalOffset = if ((x / boxWidth).isOdd()) 0 else height
        append('V')
        append(verticalOffset)
    }
    for (y in height downTo  0 step boxHeight) {
        append("v-${boxHeight}")
        if (y - boxHeight == 0) break // Don't draw the last line.
        val horizontalOffset = if ((y / boxHeight).isOdd()) height else 0
        append('H')
        append(horizontalOffset)
    }
    append('z')
}

The last tiny optimization

Before I had even started writing the 3rd version above, I was thinking that the potentially equivalent v-2 was longer than V8, but at the same time, v-2 is shorter than V10. I didn't let this stop me from writing a simple working version first, but then, I changed 3 lines in the second for loop for the 4th iteration, allowing me to shave a few extra bytes in the result where possible:

fun generateChessboardPattern4(
    size: Int,
    boxSize: Int
): String = buildString {
    val boxWidth = boxSize
    val boxHeight = boxSize
    val width = size
    val height = size
    for (x in 0 until width step boxWidth) {
        append("h${boxWidth}")
        if (x + boxWidth == width) break // Don't draw the last line.
        val verticalOffset = if ((x / boxWidth).isOdd()) 0 else height
        append('V')
        append(verticalOffset)
    }
    for (y in height downTo  0 step boxHeight) {
        val targetY = y - boxHeight // <- changed
        append(if (targetY >= 10) "v-${boxHeight}" else "V${targetY}") // <- changed
        if (targetY == 0) break // Don't draw the last line. // <- changed
        val horizontalOffset = if ((y / boxHeight).isOdd()) height else 0
        append('H')
        append(horizontalOffset)
    }
    append('z')
}

With the following code:

println("approach number 3:")
println(generateChessboardPattern3(size = 28, boxSize = 2))
println("approach number 4:")
println(generateChessboardPattern4(size = 28, boxSize = 2))

I checked how they compared:

approach number 3:
h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0v-2z
approach number 4:
h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2V0h2V28h2v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0v-2H28v-2H0V8H28V6H0V4H28V2H0V0z

With just 5 characters saved, clearly, we're seeing the effects of the law of diminishing returns, but I still took it. Time has already been spent on it, no significant downside… ¯_(ツ)_/¯

The last two possible optimizations (that I didn't check if aapt2 was doing) are renaming the android xml namespace to a, and removing all the non mandatory spaces and line breaks. Anyway, I saved 81 bytes there (more than 20% less compared to the previous iteration).

Counting the savings

That was quite a journey! To be honest, it was very quick on my end, but writing the article made it much longer… 😅 Sharing is caring!

If you take the entire file size, we started at 1812 bytes, and the most optimized version is now 318 bytes, which 5.7x smaller!

If you take just the path data, we started from 1504 bytes/chars down to 131 bytes/chars, or 11.4x smaller!

Bonus 1: How to draw lines that are neither horizontal, neither vertical?

It's very easy, just like we've been doing Mx,y to move to a position in the beginning, use Lx,y, and it'll draw a line to the given absolute position, or use the lowercase variant for a relative position (lx,y). Now I want to learn how to draw curves… maybe later.

Bonus 2: How to convert a VectorDrawable to a pixel-perfect PNG?

For this article, I've been looking for a way to get a png out of my VectorDrawables.

I first failed to find a proper way to do it, so I was using screenshots and cropped roughly. Then I failed at finding a working tool to convert them to SVG before I could extract a PNG. I then successfully did the conversion by hand, where I happily learned a bit more about SVG. Then some folks in the community pointed me to VdPreview.getPreviewFromVectorXml(), located in com.android.tools:sdk-common, a dependency of AGP (the Android Gradle Plugin). So, I added the dependency, and with the following code, I can now get a nice PNG file from any Android VectorDrawable:

import com.android.ide.common.vectordrawable.VdPreview
import java.io.File
import javax.imageio.ImageIO

fun saveImageFromVectorDrawableAndReturnErrors(
    xml: String,
    maxDimension: Int,
    outputFile: File
): String? {
    val errors = StringBuilder()
    val bufferedImage = VdPreview.getPreviewFromVectorXml(
        VdPreview.TargetSize.createFromMaxDimension(maxDimension),
        xml,
        errors
    )
    ImageIO.write(bufferedImage, "png", outputFile)
    return errors.takeIf { it.isNotEmpty() }?.toString()
}

It'd probably be worth wrapping that in a CLI tool, it's very easy to do with Kotlin scripts since they support dependencies.

To wrap it up, here's a chessboard sized grid drawn with the generated code I've been showing you. And about the cover picture, the Kotlin logos with chessboard/checkerboard patterns are self-made, I got to learn a bit about SVG as well, which uses the exact same format for pathData (but requires an initial move instruction [Mx,y]).

Of course, you can copy the code above 100% freely, no mention needed.

If you enjoyed this article or found it useful, which I hope so, please add a thumbs up or something, you can very easily connect with a GitHub, Google, Apple, or even a LinkedIn account! (email also works). 🙏 You can also click the subscribe button on this page to see my future dev blog posts, or/and you can follow me on Twitter.

Have a great day!

Run multiple related coroutines (i.e. asynchronous operations), and when one completes, cancel/stop the other ones.

As usual, and especially since we're in Kotlin, I have been looking for the easiest way to do it correctly, and efficiently.

Within the kotlinx.coroutines first party library, I didn't find the high-level API I was looking for, though the building blocks to make it were definitely there.

Before we look at the solution I've been using, let's see some use cases for coroutines racing.

Why race in the first place

The kind of use case that I found to be the most obvious is allowing triggering something via multiple means. For example, we could have a manual and an automatic way of enabling something. Or we could have a local and remote way of turning off something else. Or, more simply, we could have two buttons that do the same thing. Maybe you can think of one or two other plausible scenarios fitting this kind of use case.

Another kind of use case is having multiple terminal operations. For example, during an onboarding step in an app, or an app feature, we could expect the user to request watching a quick video introduction, while being able to skip it midway.

There are of course many other reasons we would want to race coroutines.

Before moving on to the how, I want to emphasize the desired behavior: when one of the racing coroutines completes, we want all other race contenders to be cancelled.

Our example use case

For the rest of this article, and for the sake of simplicity, we'll settle on the triggering use case.

A triggering operation can be abstracted away as a suspending function with such a signature:

suspend fun awaitTrigger()

As you can guess, we would expect that function to return/resume when it's time to trigger the thing.

Now, for the multiple trigger means, we could imagine that we actually have two other suspending functions: awaitAutomaticTrigger(), and awaitManualTrigger().

How can we race these two functions?

A basic approach

If you want to race two coroutines, here's one way you could come up with:

suspend fun awaitTrigger() {
    coroutineScope {
        val automaticTrigger = launch {
            awaitAutomaticTrigger()
            // Aaargh, can't access `manualTrigger` here!
        }
        val manualTrigger = launch {
            awaitManualTrigger()
            automaticTrigger.cancel()
        }
        // `coroutineScope { … }` suspends until all children are complete or cancelled,
        // so no need to call `join()`, nor go with an extra indirection.
    }
}

As you can see, the most straightforward approach, that works for just two racers, already has a shortcoming (as you can see in the "Aaargh" comment). One workaround is declaring manualTrigger as a lateinit var. Works, but not so neat, and it's now underlined by our IDE 😔.

What would be an ideal API?

Well, we can never really know what the absolute best API could be, but let's at least imagine something easier to use than the previous snippet that would serve the same purpose.

That API would need to surface the intent of racing multiple suspend calls, with the cancelling behavior for the non-winners.

So, it'd need the verb "race" in its name, and it'd need to take multiple suspending functions as a parameter? How could it look for our triggering use case?

suspend awaitTrigger() = raceOf({
    awaitAutomaticTrigger()
}, {
    awaitManualTrigger()
})

So, we went from 11 lines of code, including 8 significant, to 5 lines of code, including 3 significant. Quite cool?

If you analyze the two snippets, you'll also see that for the first approach, unless we rework it, the number of lines of code, and the potential mistakes one can make along the way, grows exponentially as we add more racers, while for this raceOf API, it grows linearly at a rate of only 2 lines of code per racer, with a single one significant.

That API, while very simple, has one shortcoming: the number of racing coroutines is fixed at compile time, just like all vararg parameters, which is what raceOf takes. It's possible to use the spread operator after converting a list of suspend functions to a typed array, but it's not optimal, and it doesn't allow late racers.

To support a dynamic amount of coroutines, and late racers, we can imagine another API. A race { … } function would bring a RacingScope where you could call launchRacer { … } inside to, well, launch racers.

Here's how it'd look for the triggering use case:

suspend awaitTrigger() = race {
    launchRacer { awaitAutomaticTrigger() }
    launchRacer { awaitManualTrigger() }
}

Interestingly, it's even less code than our previous approach, and each additional racer can take as little as 1 line of code in total.

How could that coroutines racing API be implemented?

The first time I wanted to race coroutines with a neat API was about 3 years ago. I also wanted it to support returning the value of the winning racer/coroutine.

My first idea was to make a suspending extension function on List<Deferred> that I named race, and I implemented it with one CompletableDeferred instance and a loop:

suspend fun <T> List<Deferred<T>>.race(): T = coroutineScope {
    val winningValue = CompletableDeferred<T>()
    this@race.forEach { racer ->
        launch {
            val winningCandidate = racer.await()
            this@race.forEach { if (it != racer) it.cancel() }
            winningValue.complete(winningCandidate)
        }
    }
    winningValue.await()
}

I then found it inconvenient to have to create the Deferred instances via calls to async { … } that had to be done inside of another coroutineScope { … } block, so I put that boilerplate inside a function named raceOf:

suspend fun <T> race(vararg racers: suspend CoroutineScope.() -> T): T = coroutineScope {
    val list: List<Deferred<T>> = racers.map { racer -> async { racer() } }
    val winningValue = CompletableDeferred<T>()
    list.forEach { racer ->
        launch {
            val winningCandidate = racer.await()
            list.forEach { racer.cancel() } // Cancelling a complete Job is no-op.
            winningValue.complete(winningCandidate)
        }
    }
    winningValue.await()
}

Thanks to the help of folks on Kotlin's Slack and some searching, I then found that I could also use the select clause for that:

/**
 * Races all the [racers] concurrently. Once the winner completes, all other racers are cancelled,
 * then the value of the winner is returned.
 */
suspend fun <T> raceOf(vararg racers: suspend CoroutineScope.() -> T): T = coroutineScope {
    select<T> {
        val racersAsyncList = racers.map { async(start = CoroutineStart.UNDISPATCHED, block = it) }
        racersAsyncList.forEachByIndex { racer: Deferred<T> ->
            racer.onAwait { resultOfWinner: T ->
                racersAsyncList.forEachByIndex { deferred: Deferred<T> -> deferred.cancel() }
                return@onAwait resultOfWinner
            }
        }
    }
}

Both implementations work fine.

It's very possible one is more performant than the other. I didn't benchmark because I am not putting these implementations under a high stress (i.e. high number of racers, or calling them at a high frequency), and they have never been the cause of any performance or stability issue. If you have such a demanding use case, feel free to do the benchmark and your testing approach, and share/link it in the comments below, I'll be interested in seeing it! I'd bet the select based implementation is the most efficient, but I wouldn't put much on table for that mostly intuition-based guess.

Sharing that work widely

Since I thought I might not be the only one with this use case, I put the select based implementation of raceOf into one of the Splitties libraries, and that Kotlin multiplatform library also includes the race function for dynamic number of racers that I was referring to earlier in this article (permalink to its implementation here).

You can find the host library module here, with the entire source code, the documentation, and setup info to add the library to your project.

However, having this in a third-party library limits the accessibility of these coroutines racing facilities which I believe could be useful in many Kotlin projects. That's why I submitted an issue in the kotlinx.coroutines GitHub repository to ask for that use case to be addressed in the first-party library from the Kotlin team. Feel free to add a 👍 reaction to it so the priority gets high enough for it to be considered before we are all dead!

I hope you enjoyed reading and learned something helpful. Have a great Kotlin… well, have a great everything!

Most programming languages, including Kotlin, only allow returning one value, and there's a reason for that: We don't want to depend solely on the order of the parameters, because it can easily break through refactoring, or even before that.

When we want to return multiple things, we put it into a container: a class. However, that approach has 2 caveats:

1. Requires extra allocation
2. Requires naming the class

If the code is not called at high frequency (many times per second), and not in UI, the first caveat should not be a concern.

However, the second caveat means that in addition to naming the function and the multiple things you are returning, you need to name that extra class. This is extra burden, and in some cases, it might lead you to give quite uninspiring names like Thing1AndThing2WithDetail3, making the code slightly more complex.

What if I told you that in Kotlin, it's possible to get more than one value out of a function execution, without any allocation, and with no class to name?

The solution

Since Kotlin 1.3, the code below can compile.

val theBonus: Bonus
val theStuff = getStuff { theBonus = it }

doSomething(theStuff, theBonus)

Maybe you know the saying that Kotlin's best feature is how all of its features can work together so smoothly?

Well, here we are using the following Kotlin features together:

• inline functions/lambdas
• read-only properties (aka. val)
• contracts

The getStuff inline function has a contract that promises to the compiler that given it executes without throwing, the lambda it has been passed will always have been called exactly once upon returning.

Thanks to that contract, the compiler allows the read-only property theBonus to be initialized from this lambda, and considers it as initialized after the getStuff call.

The getStuff function is defined like that:

import kotlin.contracts.*

@OptIn(ExperimentalContracts::class)
inline fun getStuff(block: (Bonus) -> Unit): Stuff {
    contract { callsInPlace(block, InvocationKind.EXACTLY_ONCE) }
    val stuff = grabStuffFromCargoBikeBasket()
    val bonus = inspirationElixir()
    block(bonus)
    return stuff
}

Here, there's no extra allocation, and no need to name the class. However, you need to name the lambda in the getStuff signature, but block or action is often sufficient for these trailing lambda use cases, so it shouldn't "drain" or consume your creativity.

There's one potential caveat though, and it pertains to the inline nature of the function. As you might know, a function being inlined means that the compiler will basically copy the compiled code at each call-site. That's perfectly fine if the amount of inline code is very little, or quite limited, but if that's a giant function that possibly also calls other inline functions that are potentially substantial as well… it can make the compiled binary grow significantly, which in addition to taking up extra storage for your users, and bandwidth on download, can also make loading the program from a cold-start longer, and increase memory (RAM) consumption. All of this doesn't go in the direction go towards a better UX. That should not be a concern if you are not inlining long algorithms or so long as you stay under a dozen of function calls though. If you're in a such a case and are unsure about the impact, make your own tests to measure the relative impact in context.

By the way, you might have noticed that we had to opt-in to "ExperimentalContracts". This is because the syntax to define contracts in Kotlin might/will change in the future, which mean you'll likely need to migrate the code (hopefully with full IDE-assistance to do it in one click). However, publishing functions that use contracts is perfectly fine, even in a public library, because compiled contracts are already stable since Kotlin 1.3, so for example, users on Kotlin 1.7 will still be able to use contracts from a library compiled with Kotlin 1.3.

An actual use-case

For those that like small stories, I want to share the use-case I had where I came up with this trick.

As I was testing stuff around Wi-Fi connectivity on Android, I wanted to see the signal strength on the system scale (which is often 0 to 4 bars). For historical reasons, there are 2 APIs to do that on Android, one that works on recent versions, and a deprecated one that works on older versions. As usual, I added a when or an if/else expression. However, the APIs has a tricky difference:

• On older Android versions, you pass the scale: I'd pass 4 or 5.
• On newer Android versions, you get the scale from the system API, which is dynamic, not much assumptions can be made.

To display the correct signal strength, I'd need two values: the scale, and the max level, which would default to whatever desired on older Android versions.

Sure, I could have used a Double or a Float, but I like my numbers whole when possible, especially when the scale is small, which is the case here.

So the calculateSignalLevel extension function for WifiInfo would take the fallbackNumLevels parameter for older Android versions (defaulting to 5, per my arbitrary choice), the getNumLevels lambda to feed the actual scale, and would return the signal strength on that scale.

Here's how the function looks like:

import android.net.wifi.WifiInfo
import android.net.wifi.WifiManager
import android.os.Build
import splitties.systemservices.wifiManager
import kotlin.contracts.ExperimentalContracts
import kotlin.contracts.InvocationKind
import kotlin.contracts.contract

@OptIn(ExperimentalContracts::class)
inline fun WifiInfo.calculateSignalLevel(
    fallbackNumLevels: Int = 5,
    getNumLevels: (numLevels: Int) -> Unit
): Int {
    contract { callsInPlace(getNumLevels, InvocationKind.EXACTLY_ONCE) }
    val wifiManager = checkNotNull(wifiManager) { "Wi-Fi info is not supported in instant apps" }
    val actualNumLevels = when {
        Build.VERSION.SDK_INT >= 30 -> wifiManager.maxSignalLevel
        else -> fallbackNumLevels
    }
    getNumLevels(actualNumLevels)
    return when {
        Build.VERSION.SDK_INT >= 30 -> wifiManager.calculateSignalLevel(rssi)
        else -> @Suppress("deprecation") WifiManager.calculateSignalLevel(rssi, actualNumLevels)
    }
}

The wifiManager top-level property comes from the Splitties System Services library that saves the tiny boilerplate otherwise needed. After all, why accept unneeded boilerplate when it can even be inlined to be like hand-written?

That's it! I hope you learned something. Personally, I'm happy to finish my first blog post after almost 7 years developing Android apps full-time (overtime?), and 5 years of Kotlin 😅.

Have a great day, and see you in my next blog posts (you can click the subscribe button if you wish), on Twitter, and maybe even on Kotlin Slack!