1. Introduction

In Kotlin, functions are first-class citizens, meaning we can store them in variables, pass them as parameters, or even return them. This flexibility enhances code reuse and modularity. However, dealing with overloaded functions—functions sharing the same name but differing in parameters—can lead to ambiguity when referencing them.

When referencing an overloaded function, the Kotlin compiler may not be able to infer which specific function we intend to use, resulting in a compilation error. This ambiguity can be frustrating, but Kotlin provides several techniques to resolve it.

In this tutorial, we’ll explore techniques for explicitly specifying function types, using lambdas, leveraging extension functions, and employing higher-order functions.

2. Overloaded Functions Example

To illustrate the problem, let’s consider a Calculator class with overloaded compute() methods:

class Calculator(val base: Int) {
    fun compute(value: Int): Int = base + value  
    fun compute(value: String): String = "$base$value"  
}

The overloaded compute() methods either sum or concatenate our base value with another Int or String.

If we try to reference the compute() method directly without the input type, the compiler can’t determine which version to use:

fun main() {
    val calculator = Calculator(10)
    val compute = calculator::compute
}

This results in a compilation error because the compiler can’t infer which compute() method to reference. In the following sections, we’ll explore techniques to resolve this ambiguity.

3. Explicitly Specifying the Function Type

One way to resolve the ambiguity is by explicitly defining the function type when referencing the overloaded function. This makes it clear to the compiler which version of the function we intend to use:

private val calculator = Calculator(10)
@Test
fun `Should compute with int function`() {
    val computeInt: (Int) -> Int = calculator::compute
    assertEquals(15, computeInt(5))
}
@Test
fun `Should compute with int function`() {
    val computeString: (String) -> String = calculator::compute
    assertEquals("105", computeString("5"))
}

By explicitly specifying the function types (Int) -> Int and (String) -> String, we disambiguate the overloaded functions, allowing the compiler to identify the intended version. This approach is straightforward and leverages Kotlin’s type inference system effectively.

3.1. Using Type Aliases for Clarity

Type aliases can also resolve ambiguity by providing descriptive names for function types:

typealias IntComputer = (Int) -> Int
typealias StringComputer = (String) -> String
private val calculator = Calculator(10)
@Test
fun `should convert int with type alias`() {
    val computeInt: IntComputer = calculator::compute
    assertEquals(15, computeInt(5))
}
@Test
fun `should convert string with type alias`() {
    val computeString: StringComputer = calculator::compute
    assertEquals("105", computeString("5"))
}

By defining type aliases IntComputer and StringComputer, we provide descriptive names for the method types. This not only resolves function ambiguity but also improves code readability by making the intent clear.

The tests ensure the type aliases correctly reference the intended compute() method. In general, the type alias is the same concept as assigning a type to the ambiguous function reference but simplifies referencing a complex function type.

4. Using Lambdas

Instead of directly referencing the function, we can define typed lambdas to call the desired function explicitly. This provides clear context for the compiler:

private val calculator = Calculator(10)
@Test
fun `should compute int with lambda`() {
    val computeInt = { value: Int -> calculator.compute(value) }
    assertEquals(15, computeInt(5))
}
@Test
fun `should compute string with lambda`() {
    val computeString = { value: String -> calculator.compute(value) }
    assertEquals("105", computeString("5"))
}

These lambdas work by assigning types to their input type and providing the compiler with context to bypass the ambiguity. The tests ensure that the lambdas correctly invoke the intended compute method.

5. Leveraging Extension Functions

Another effective way to resolve ambiguity is using non-ambiguous extension functions to provide clear context for overloaded behavior. Instead of creating a new class, we can define extension functions on the existing Calculator class. These extension functions have unique names to eliminate ambiguity when referencing them:

fun Calculator.computeInt(value: Int): Int = compute(value)
fun Calculator.computeString(value: String): String = compute(value)
private val calculator= Calculator(10)
@Test
fun `should compute int with extension function`() {
    val computeInt = calculator::computeInt
    assertEquals(15, computeInt(5))
}
@Test
fun `should compute string with extension function`() {
    val computeString = calculator::computeString
    assertEquals("105", computeString("5"))
}

We define two non-ambiguous extension functions on the Calculator class: computeInt() and computeString(). These functions internally call the appropriate overloaded compute() method but provide unique names, eliminating ambiguity when referencing them. Using unique names ensures the compiler can always determine which function to use.

6. Conclusion

In this article, we’ve explored several techniques to resolve ambiguity in overloaded functions.

By explicitly specifying function types, using lambdas, leveraging extension functions, and employing type aliases, we can provide the compiler with the necessary context to determine the correct function. These techniques help avoid compiler errors and also enhance code clarity and maintainability.

     

Related Stories

• Pass a Function as Parameter to Another in Kotlin
• Resolving Type Mismatch Inferred Type is Unit But Void Was Expected in Kotlin
• A Guide to Kotlin Context Receivers

 

1. Overview

In this quick article, we’ll learn about the different approaches to format a number with a thousand separators and how to implement them.

2. Setup

First, let’s define our method signature, which we’ll use for our implementations:

fun formatted(number: Int): String

Our function will accept an Int as input and return a String. The output is a String representation of the input, formatted with a dot separator after each three-character sequence.

For example, putting 1000 into the function should result in a ‘1.000’ string; and inserting 0 should result in ‘0’.

Now, let’s look at a few approaches.

3. Using String Format

In our first implementation, we’ll use String.format:

String.format(Locale.GERMANY, "%,d", number)

We use here the following parameters:

• Locale.GERMANY makes formatting locale-sensitive. In the case of Germany, the dot character is used.
• “%,d” follows the format convention of java.util.Formatter, which, in this case, adds a thousand separator.
• number is the input parameter of our function.

Using this implementation, we take full advantage of a long-established functionality in Kotlin & Java and the adaptability to region-specific settings.

It is also a very concise, single-line expression, which brings benefits to simplicity and readability.

4. Using DecimalFormat

The second implementation will make use of DecimalFormat:

DecimalFormat("#,###")
    .format(number)
    .replace(",", ".")

The “#,###” pattern will format our number to a thousand-separated String, but with a comma separator. That’s why we need to replace them with a dot.

We could design it even simpler by using the locale-sensitive approach:

DecimalFormat("#,###", DecimalFormatSymbols(Locale.GERMANY)).format(number)

Just like the implementation with String.format, the parameter DecimalFormatSymbols(Locale.GERMANY) will produce the dot separator in the formatted String.

5. Using Chunking

In our last implementation, we’ll get creative with the use of String chunking:

number.toString()
    .reversed() // 15000 -> 00051
    .chunked(3) // [000] [51]
    .joinToString(".") // 000.51
    .reversed() // 15.000

The number as a String is reversed at first because the character sequences must be read from right to left. Then, we chunk it into three-character Strings and join the list with a dot separator. As the last step, the String is reversed again, back to the original order.

Notably, this method lacks localization and adds more complexity, which makes other approaches more desirable.

6. Validation

Now that we’ve seen all our different implementations, let’s test each one for correctness.

We’ll use the Kotlin native framework Kotest with the writing style ShouldSpec. Its features to write dynamic parameterized tests will help us greatly.

Here is what our parameterized test would look like:

should("return '$expectedString' for $givenNumber with $name implementation") {
    assertThat(function(givenNumber)).isEqualTo(expectedString)
}

As we can notice, there are four parameters:

• $givenNumber is the given integer to test
• $expectedString is the expected output to test against
• function is the implementation we test
• $name is the approach name

The assertion checks whether the output of our implementing function is equal to the expected output. The parameter data to iterate through would be:

private val givenToExpectedPairs = listOf(
    0 to "0",
    12 to "12",
    456 to "456",
    100_000 to "100.000",
    1_234_567 to "1.234.567"
).forEach { (givenNumber , expectedString) -> /* execute test here */ }

With these pairs, we cover multiple examples, which should be valid for all of the approaches.

7. Conclusion

In this article, we’ve learned how to produce a String representation of an Integer with a thousands separator, including the adaptation to locale-sensitive formatting. In the end, we wrote a dynamic parameterized test to get a good coverage.

     

Related Stories

• Convert Int to Float in Kotlin
• Parse String With Thousands Separator in Kotlin
• Extract Numbers From a String in Kotlin

 

1. Overview

In this article, we’ll explore how to integrate and use the Apache Log4j Kotlin library. Log4j is a robust logging framework widely used in the Java ecosystem composed of an API, its implementation, and components that assist the deployment of various use cases. The library provides a Kotlin-friendly interface to the Log4j API.

2. Why Log4j?

Although the discovery of the Log4Shell vulnerability (CVE-2021-44228) has shaken its reputation, it remains widely adopted, providing powerful features such as asynchronous logging, JSON support, and a highly configurable architecture.

Using the Log4j framework allows us to filter logs based on configurable levels such as DEBUG, INFO, or ERROR without needing to change our code.

It also provides the flexibility to direct logs to various outputs like files, databases, or remote systems rather than being limited to the console.

3. Dependencies

To set up Log4j in a Kotlin project, we need to include the dependencies for both the API and the Log4j backend:

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-api-kotlin</artifactId>
     <version>1.5.0</version>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.20.0</version>
</dependency>

4. Creating Loggers

With the library imported, let’s look at some common ways to create loggers.

4.1. Logger in Companion Objects

The traditional approach is to use a companion object that all instances of the class can share:

class Game {
    companion object {
        private val logger = logger()
    }
    fun startGame() {
        logger.info { "Game is starting..." }
    }
}

An alternative would be to extend the companion object from the Logging class:

class Game {
    companion object: Logging
    fun startGame() {
        logger.info { "Game is starting..." }
    }
}

While both methods are straightforward, the traditional approach is more efficient as the logger lookup is performed once. The alternative, which extends the class, adds extra overhead due to the logger lookup involved at runtime.

When we run the code, we’ll notice that there’s no output, and that’s because we need to specify the log level:

Configurator.setRootLevel(Level.DEBUG)

In the next chapter, we’ll expand on this topic and the common way to set up an external configuration file, allowing us to keep our code free from hardcoded log-level management.

4.2. Logger in Class

Alternatively, we can define the logger within the class:

class Player(val name: String) {
    private val logger = logger()
    fun joinGame() {
        logger.info { "Player '$name' has joined the game." }
    }
    fun takeDamage(amount: Int) {
        logger.warn { "Player '$name' took $amount damage!" }
    }
}

Although not recommended, this approach creates a logger instance for each class instance, which may be suitable in certain scenarios.

When creating the logger in the class, we can pass it a name parameter, ensuring that when the code is run, we’ll know exactly which logger was used:

val logger = logger("Player Action")

In this case, the output will contain our defined name instead of the class name.

4.3. Using the Logging Interface

We could also use the Logging interface, offering us a quick and convenient way to access the logger.

Let’s create a utility class that implements it:

class GameUtil : Logging {
    fun logEvent(event: String) {
        logger.info { "Game Event: $event" }
    }
}

When using this method, we effectively create a single Logger instance that is exclusively associated with the class instance and not shared among other instances.

Let’s look at a usage example:

val util = GameUtil()
util.logEvent("Level 1 Loaded")

4.4. Using the Logger Extension Property

As a substitute, we can use the logger extension property to dynamically inject a logger on the spot:

class Enemy {
    fun shoot() {
        logger.warn { "Enemy shoots the player" }
    }
}

In this case, the logger will look up the associated Logger instance for the encapsulating class, adding extra overhead at runtime.

5. Logger Configuration

Now that we’ve looked at the most common ways to use Log4j for Kotlin let’s check out how to configure it for our needs.

As mentioned in the previous chapter, the log level has been set to debug by hardcoding it. Now, we can create a configuration file named log4j2.xml in our resources folder, which the logger can use:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <Console name="ConsoleAppender" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="ConsoleAppender"/>
        </Root>
    </Loggers>
</Configuration>

This configuration defines a console appender with a specific pattern layout, ensuring that all log messages are output with a timestamp, thread information, log level, and message.

Additionally, we’re setting the log level to info. Therefore, the output will display only the messages of log level info, warn, error, and fatal, omitting the debug and trace levels.

The seven log levels provided help us separate the type of events that occur when our program is running, thus resulting in a hierarchy.

When set to all, for example, the log level will output all logger messages, while setting it to error will only display logged errors and fatals. Log level all is a special marker that’s rarely used in application code.

6. Best Practices

To maximize the effectiveness of logging in our Kotlin applications, we should follow these best practices consistently.

In most applications, we should create a single logger per class definition rather than per instance. This approach prevents redundant fields and clearly conveys the static binding to the class.

We should use the appropriate log level that corresponds to the severity of the events, such as:

• trace to capture detailed information about the application’s behavior
• debug for detailed information during debugging;
• info for general operational messages;
  
• warn for indication of potential issues;
• error for error events that might still allow the application to continue running;
• fatal for severe errors causing premature termination.

Additionally, we must ensure that sensitive data, such as passwords, personal information, or tokens, is never logged to prevent security vulnerabilities.

Our codebase should maintain a consistent log format across applications, which is essential for easier parsing and analysis. To achieve this, we define a standard pattern in the configuration and consistently follow it throughout.

7. Conclusion

In this article, we’ve explored multiple ways of creating loggers using the Kotlin Log4j library.

To begin, we tackled the differences between creating class-based loggers versus instance-based ones, as well as using the Logging interface and extension property.

Moving forward, we went through the configuration file, avoiding hardcoded log-level settings, and checked out some of the best practices when working with loggers.

     

Related Stories

• Excluding a Library from All Dependencies in Kotlin DSL in Gradle
• PubSub Messaging With Kotlin Redis
• Plotting Charts in Kotlin With Kandy

 

1. Introduction

Handling exceptions is critical to building resilient applications, and Kotlin Flow simplifies this with the catch() operator. This allows us to handle exceptions gracefully during a Flow‘s emission of values. Whether we want to log errors, emit fallback values, or implement retry logic, catch() helps maintain a flow’s lifecycle without abrupt termination. 

This tutorial explores various ways to use the catch() operator effectively, illustrated with clear examples and unit tests.

2. Basic Usage of the catch() Operator

The catch() operator lets us capture and handle exceptions upstream in a Flow. Instead of terminating the Flow abruptly on error, we can intercept it and decide how to proceed:

@Test
fun `catch operator logs exception`() = runTest {
    val emittedValues = mutableListOf<Int>()
    val flow = flow {
        emit(1)
        emit(2)
        throw IllegalStateException("Test exception")
    }
    flow.catch { e ->
        assertEquals("Test exception", e.message)
    }.collect {
        emittedValues.add(it)
    }
    assertEquals(listOf(1, 2), emittedValues)
}

In this test, the Flow emits two integers before throwing an exception. The catch() block captures the exception and verifies its message. Then we collect the emitted values to a List to confirm that the Flow still completes successfully. This ensures that the Flow handles errors gracefully without crashing.

3. Emitting a Fallback Value in catch()

Sometimes we might want to emit() a fallback value instead of terminating the Flow when an error occurs:

@Test
fun `catch operator emits fallback value`() = runTest {
    val emittedValues = mutableListOf<Int>()
    val flow = flow {
        emit(1)
        throw IllegalArgumentException("Simulated error")
    }
    flow.catch {
        emit(-1) 
    }.collect {
        emittedValues.add(it)
    }
    assertEquals(listOf(1, -1), emittedValues)
}

The Flow emits a single value before throwing an exception. The catch() block also emits a value. Then we ensure that the collector still receives both emissions. This approach is ideal for providing default data when the flow fails.

4. Combining catch() With Retry Logic

Transient errors such as network issues can sometimes be resolved with retries. Kotlin Flow allows us to combine the catch() operator with retry mechanisms to handle these situations elegantly:

@Test
fun `catch operator works with retries`() = runTest {
    var attempt = 0
    val emittedValues = mutableListOf<Int>()
    val flow = flow {
        if (attempt++ < 3){
            throw RuntimeException("Network error")
        }
        emit(1)
    }
    flow.retry(3) { it is RuntimeException }
        .catch { 
            emit(-1)
        }
        .collect {
            emittedValues.add(it)
        }
    assertEquals(listOf(1), emittedValues)
}

This test simulates a Flow that fails three times before successfully emitting a value. The retry() operator ensures that the Flow is re-executed up to three times whenever a RuntimeException occurs.

If the error persists beyond three attempts, it propagates to the catch() block, which emits a negative one. However, because our retry succeeds, the exception never reaches catch(), as the error is effectively “swallowed” during the retry process. This means that catch() will only execute if all retry attempts fail, ensuring that the Flow either recovers from transient failures or gracefully handles an unrecoverable error.

5. Handling Specific Exceptions With Conditional Logic

Sometimes, we may want to handle specific types of exceptions differently. We can also inspect the exception in the catch() and handle errors differently:

@Test
fun `catch operator handles specific exceptions`() = runTest {
    val emittedValues = mutableListOf<Int>()
    val flow = flow {
        emit(1)
        throw IllegalStateException("Recoverable error")
    }
    flow.catch { e ->
        if (e is IllegalArgumentException) {
            emit(-1)
        } else {
            throw e
        }
    }.collect {
        emittedValues.add(it)
    }
    assertEquals(listOf(1, -1), emittedValues)
}

The Flow emits a value before throwing an exception. Then this test demonstrates how the catch() operator can selectively handle specific exceptions, such as an IllegalArgumentException.

The IllegalArgumentException is treated as recoverable and we emit a value when handling it. All other exceptions are rethrown to avoid suppressing critical issues. This ensures a balance between error recovery and transparency, allowing the collector to continue when encountering recoverable errors.

6. Benefits of Using the catch() Operator

The catch() operator enhances error handling in Kotlin Flow by providing a structured and readable approach to managing exceptions:

• Smooth Error Management: It prevents crashes by handling exceptions gracefully, ensuring data flows continue without disruption.
• Targeted Exception Handling: catch() only intercepts upstream errors, allowing downstream exceptions to propagate naturally, maintaining precise control over error handling.
• Flexible Responses: Developers can log errors, provide alternative values, or rethrow exceptions, adapting to various application needs.
• Improved Readability: By reducing scattered try-catch blocks, catch() keeps the codebase clean and maintainable.
• Seamless Integration: It works well with other Flow operators, enabling robust, composable, and resilient data pipelines.

7. Conclusion

In this article, we explored the catch() operator of the Kotlin Flow, highlighting its role in managing exceptions gracefully without disrupting data processing. We also demonstrated how to log errors, emit fallback values, and handle specific exceptions while maintaining clean and readable code.

The catch() operator enhances error handling and integrates seamlessly with other Flow operators like retry(), making it indispensable for building resilient, fault-tolerant applications. It also provides uninterrupted data flows and maintains robust application performance.

     

Related Stories

• Testing Flow in Kotlin
• Get Current and Previous Value in Kotlin Flow’s collect
• Combine 2 Kotlin State Flows Into a Single State Flow

 

1. Introduction

StateFlows are an integral part of modern Kotlin applications. They are part of the Kotlin Coroutines library and provide a way to manage and observe state changes reactively. Testing these flows ensures that our applications behave as expected under various conditions.

In this article, we’ll explore multiple approaches and best practices to effectively unit test StateFlows.

2. Understanding StateFlow Fundamentals

When working with state management in Kotlin, we often encounter various approaches. This might include simple variables to reactive streams. StateFlow sits at a sweet spot between these approaches. It combines the reactive nature of Flows with state-holding abilities.

Let’s look at a basic implementation of StateFlow:

class StateFlowExample {
    private val _state = MutableStateFlow("Initial State")
    private val state: StateFlow<String> = _state.asStateFlow()
    fun getCurrentState() = state.value
    fun updateState(newValue: String) {
        _state.value = newValue
    }
}

In this example, we create a MutableStateFlow with an initial value. The state is exposed as an immutable StateFlow to prevent external modifications.

StateFlow maintains a current value that can be accessed synchronously while providing a way to observe changes over time. Also, unlike regular Flows, StateFlow is “hot”. This means it’s always active and maintains its current state regardless of collectors.

These characteristics make it suitable for managing the application state, where we need both the current value and updates to that value. When a new collector starts observing a StateFlow, it immediately receives the current state and subsequently receives any new state updates.

3. Setting Up for StateFlow Testing

Testing StateFlows requires careful setup of the testing environment. The key is creating a controlled environment where we can predictably emit states and verify our flow’s behavior.

The kotlinx-coroutines-test library provides essential tools for testing coroutines and flows. It offers utilities to control coroutine execution and manage test scopes.

Let’s build on our previous StateExample class and create a proper test environment. First, we’ll set up a basic test class:

class StateFlowUnitTest {
    private lateinit var stateFlowExample: StateFlowExample
    @Test
    fun `initial state is correct`() = runTest {
        stateFlowExample = StateFlowExample()
        // Initial state verification
        assertEquals("Initial State", stateFlowExample.getCurrentState())
    }
}

In our example, we create a new instance of the StateFlowExample class and verify that the initial state is as expected.

To test this state holder effectively, we need a controlled environment. The runTest builder from the kotlinx-coroutines-test library is crucial for that.

The runTest builder creates a coroutine scope specifically designed for testing. This scope uses a special test dispatcher that gives us control over virtual time, which helps make our tests both reliable and fast.

With this testing environment in place, let’s explore how to test different StateFlow scenarios, starting with the simplest case: single-state emissions.

4. Testing Single Emissions

Let’s start with the simplest case: testing what happens when we update our state once. We want to verify that when we update the state, the new value is correctly reflected in our StateFlow.

Let’s expand our previous test class to include state change verification:

@Test
fun `state updates properly`() = runTest {
    stateFlowExample = StateFlowExample()
    stateFlowExample.updateState("New State")
    assertEquals("New State", stateFlowExample.getCurrentState())
}

In this test, we’re verifying two important aspects of StateFlow behavior. First, we verify that the update correctly overrides the initial value. Second, we confirm that updating the state changes the current value.

While testing single updates is straightforward, real-world applications often need to handle a stream of updates. Let’s explore how to test these continuous state changes.

5. Testing Continuous State Updates

When working with StateFlow in real applications, we rarely deal with a single state update.

Let’s think about a typical user session: a user logs in, performs various actions, updates their profile, and logs out. Each of these actions might trigger state changes our application needs to handle. We need to verify not just that each state update works, but that our StateFlow correctly manages this entire sequence of changes. This becomes especially important when multiple parts of our application are observing these state changes and need to react to them reliably.

The following test demonstrates how to verify a sequence of state updates by collecting and asserting multiple state changes:

@Test
fun `collects all state updates`() = runTest {
    stateFlowExample = StateFlowExample()
    val collectedStates = mutableListOf<String>()
    val collectJob = launch {
        stateFlowExample.state.collect { state ->
          collectedStates.add(state)
        }
    }
    // Advance the time to make the initial state available for collection
    advanceUntilIdle()
    stateFlowExample.updateState("First Update")
    advanceUntilIdle() // Advance the time to make the first update available
    stateFlowExample.updateState("Second Update")
    advanceUntilIdle() // Advance the time to make the second update available
    stateFlowExample.updateState("Third Update")
    advanceUntilIdle() // Advance the time to make the third update available
    assertEquals(4, collectedStates.size) // Initial state + 3 updates
    assertEquals("Initial State", collectedStates[0])
    assertEquals("First Update", collectedStates[1])
    assertEquals("Second Update", collectedStates[2])
    assertEquals("Third Update", collectedStates[3])
    // Cancel the job to stop collecting states and let the test finish
    collectJob.cancel()
}

Let’s break down what’s happening in this test. We start by collecting states from our StateFlow into a list – this lets us verify both the sequence and content of state changes.

The launch coroutine builder creates a new coroutine that collects states throughout our test. The collect function observes all state changes and adds each new state to our list as it is collected.

Each time we update the state, we need to ensure the update has been processed before moving forward. The testing library gives us a few ways to handle this timing. In this example, we’re using advanceUntilIdle(), but we could also use yield() or advanceTimeBy(timeMillis). Each approach has its use cases, but advanceUntilIdle() is often the simplest choice as it ensures all pending work is completed before continuing.

Now that we understand how to test both single updates and continuous state changes, let’s explore how to test StateFlows created using the stateIn operator, which introduces its own set of testing considerations.

6. Testing stateIn Transformations

The stateIn operator converts a regular Flow into a StateFlow. We can use this transformation when we need to combine the reactive nature of Flows with the state-holding capabilities of StateFlows. However, testing these transformations requires some additional considerations.

Let’s look at a simple example that mirrors how we might transform data from a repository or database in a real application:

class DataTransformer(scope: CoroutineScope) {
    private val _dataFlow = MutableSharedFlow<String>()  // Simulates a repository stream
    val transformedData = _dataFlow
      .map { it.uppercase() }
      .stateIn(
        scope = scope,
        started = SharingStarted.Eagerly,
        initialValue = "INITIAL"
      )
    suspend fun emit(value: String) {
        _dataFlow.emit(value)
    }
}

Here’s how we can test these transformations:

@Test
fun `transforms to uppercase states`() = runTest {
    val testScope = TestScope(UnconfinedTestDispatcher())
    val transformer = DataTransformer(testScope)
    val collectedStates = mutableListOf<String>()
    val collectJob = launch {
        transformer.transformedData.collect { state ->
          collectedStates.add(state)
        }
    }
    advanceUntilIdle() // Wait for initial collection
    transformer.emit("first")
    advanceUntilIdle() // Wait for first emission
    transformer.emit("second")
    advanceUntilIdle() // Wait for second emission
    assertEquals(3, collectedStates.size)
    assertEquals("INITIAL", collectedStates[0])
    assertEquals("FIRST", collectedStates[1])
    assertEquals("SECOND", collectedStates[2])
    collectJob.cancel()
    testScope.cancel()
}

Each sharing strategy serves different use cases, and our tests need to reflect these differences. The key is understanding when transformations begin and how they respond to collectors.

The use of UnconfinedTestDispatcher here is notable. It executes coroutines eagerly and immediately in the same thread, rather than dispatching or queuing them. This means that when we emit a value, its transformation (uppercase) and collection happen immediately one after the other. This makes our tests more predictable.

7. Conclusion

In this tutorial, we’ve explored different testing scenarios in this article. These range from simple state updates to continuous emissions and StateFlow transformations.

We also explored some tools from the kotlinx-coroutines-test library. We can use them to write reliable tests for our StateFlow implementations.

     

Related Stories

• Kotlin Flow catch() Operator
• Testing Flow in Kotlin
• Introduction to Kluent Assertion Library

 

1. Introduction

The Mono is a reactive type provided by Project Reactor, representing either a single asynchronous value or no value. When working with Mono, determining whether it is empty helps with correct application behavior.

In this tutorial, we’ll explore how to check if a Mono is empty in Kotlin, leveraging JUnit test cases for demonstration.

2. Understanding Mono Emptiness and Mapping Behavior

A Mono represents either a single asynchronous value or no value (empty). When working with monos, it’s crucial to understand how they behave when empty:

• Mapping Behavior: When a Mono is empty, any mapping function (flatMap(), map(), or similar) applied to it will not execute. This means that if we chain operations on a Mono, those operations will only run if the Mono emits a value.
• Default or Fallback Handling: To handle cases where a Mono is empty, methods like defaultIfEmpty() or switchIfEmpty() allow us to define alternative behavior.

For example:

@Test
fun `mapping function is skipped for empty Mono`() {
    val callCount = AtomicInteger(0)
    val emptyMono = Mono.empty<String>()
    val resultMono = emptyMono.map { 
        callCount.incrementAndGet()
        it.uppercase() 
    }
    StepVerifier.create(resultMono)
        .verifyComplete() // No value emitted, Mono completes directly
    assertEquals(0, callCount.get())
}

This fundamental behavior ensures efficient handling of empty states and provides the foundation for more advanced techniques, such as defining default values or fallbacks.

When a Mono completes without emitting a value, it implicitly means that any mapping or transformation functions in the chain were skipped. While verifying completeness does not directly prove the mapper wasn’t called, combining it with additional tracking mechanisms like a counter or logging provides concrete evidence.

3. Checking Mono Emptiness with hasElement()

Using hasElement() allows us to determine whether a Mono emits a value. This method is useful when checking whether the Mono contains any value before proceeding with further operations.

First, let’s verify this function on an empty Mono:

@Test
fun `should detect empty Mono using hasElement`() {
    val emptyMono = Mono.empty<String>()
    StepVerifier.create(emptyMono.hasElement())
        .expectNext(false)
        .verifyComplete()
}

We created an empty Mono with Mono.empty() and verified that hasElement() emits false.

Now, let’s try with a Mono that has a value. We’ll use Mono.just() to start with a basic value:

@Test
fun `should detect non-empty Mono using hasElement`() {
    val nonEmptyMono = Mono.just("Hello, World!")
    StepVerifier.create(nonEmptyMono.hasElement())
        .expectNext(true)
        .verifyComplete()
}

Now, we see that hasElement() emits true when a value is present.

Calling the hasElement() method on a Mono creates a new Mono that emits a boolean indicating if the original Mono is empty. We can use StepVerifier to check the value emitted from our Mono and ensure it completes as expected.

4. Providing a Default Value with defaultIfEmpty()

The defaultIfEmpty() method provides a default value if the Mono is empty. This method is useful when we need a static fallback value rather than another Mono source. Again, we’ll test this with an empty Mono first:

@Test
fun `should provide default value for empty Mono`() {
    val emptyMono = Mono.empty<String>()
    val resultMono = emptyMono.defaultIfEmpty("Default Value")
    StepVerifier.create(resultMono)
        .expectNext("Default Value")
        .verifyComplete()
}

We created an empty Mono again with Mono.empty() and verified that resultMono emits our “Default Value”.

Let’s see what happens when we try with a Mono that has a value:

@Test
fun `should not override value for non-empty Mono`() {
    val nonEmptyMono = Mono.just("Actual Value")
    val resultMono = nonEmptyMono.defaultIfEmpty("Default Value")
    StepVerifier.create(resultMono)
        .expectNext("Actual Value")
        .verifyComplete()
}

Using defaultIfEmpty(), we can ensure that a predefined fallback value is only emitted when the Mono is empty.

5. Providing a Fallback with switchIfEmpty()

While defaultIfEmpty() is useful for providing static fallback values, switchIfEmpty() is more powerful and allows us to provide another Mono as a fallback source. This can be useful when the fallback value needs to be dynamically generated or involves asynchronous computation.

Let’s start by looking at handling an empty Mono with switchIfEmpty():

@Test
fun `should provide fallback value for empty Mono`() {
    val emptyMono = Mono.empty<String>()
    val fallbackMono = emptyMono.switchIfEmpty(Mono.just("Fallback Value"))
    StepVerifier.create(fallbackMono)
        .expectNext("Fallback Value")
        .verifyComplete()
}

First, we create an empty Mono with Mono.empty(). The switchIfEmpty() method provides a fallback Mono that emits the string “Fallback Value”. When the original Mono is empty, the fallback Mono is the source for the resulting stream.

Finally, let’s understand how switchIfEmpty() works with a Mono that has a value:

@Test
fun `should not invoke fallback for non-empty Mono`() {
    val nonEmptyMono = Mono.just("Hello, World!")
    val resultMono = nonEmptyMono.switchIfEmpty(Mono.just("Fallback Value"))
    StepVerifier.create(resultMono)
        .expectNext("Hello, World!")
        .verifyComplete()
}

This time, our fallback value isn’t used, which is as we expected.

The switchIfEmpty() approach ensures that a meaningful default value is always available when the source Mono doesn’t emit data.

6. Conclusion

Handling empty Monos is a key aspect of reactive programming. Since Monos skip all mapping operations when empty, developers need explicit strategies to manage such cases. Methods like defaultIfEmpty() provide simple fallback values, while switchIfEmpty() enables more dynamic and reactive alternatives.

By mastering these techniques, we can design robust and efficient reactive flows that gracefully handle missing data.

     

Related Stories

• Kotlin Coroutine Continuation
• Sequentially Concatenate 2 Kotlin Flows

 

1. Introduction

One of Kotlin’s most versatile abilities is that it allows us to express code syntax concisely yet powerfully to maximize developer productivity. It provides us with a powerful generics system for building reusable and type-safe code.

By understanding Any and *, we can harness the full potential of Kotlin generics and write more robust and flexible code.

Let’s now examine their differences and understand how to utilize them effectively.

2. Define Use Case

Let’s imagine we’re building a treat dispenser for a Halloween haunted house. This dispenser needs to handle various types of treats:

• Candy: Chocolate bars, lollipops, etc.
• Spooky trinkets: Fake spiders, vampire fangs, etc.

Using separate containers for each treat type would be cumbersome and inefficient. Instead, let’s leverage generics to create a versatile TreatDispenser<T>:

class TreatDispenser<T>(private val treats: MutableList<T> = mutableListOf()) {
    fun dispenseTreat(): T? {
        return if (treats.isNotEmpty()) treats.removeFirst() else null
    }
    fun peekNextTreat(): T? {
        return treats.firstOrNull()
    }
    fun addTreat(treat: T) {
        treats.add(treat)
    }
}

With the above implementation, we now have the flexibility of creating dispensers for each category:

val candyDispenser = TreatDispenser<Candy>()
val trinketDispenser = TreatDispenser<SpookyTrinket>()

The advantages of this approach are:

• Flexibility: A single TreatDispenser class manages all treat types
• Type safety: The compiler prevents mixing different treats (no gummy bears in the potion dispenser!)
• Extensibility: Adding new treat types is simple; we’ll create a new class and use it with the TreatDispenser

3. Understanding Star Projections (*)

While our TreatDispenser<T>  works wonders for managing specific treat types, let’s imagine a scenario where we need a function to inspect the next treat in any dispenser, regardless of its type. This is where star projections (*) come into play.

A star projection (*) essentially represents an unknown type. It allows us to work with generic types without knowing the concrete type argument – it’s a wildcard that matches any type.

Let’s introduce a function to peek at the next treat in any TreatDispenser:

fun peekAtNextTreat(dispenser: TreatDispenser<*>) {
    val nextTreat = dispenser.peekNextTreat()
    println("The next treat is: $nextTreat")
}

The above code has now given us the magical ability to peek into any type of TreatDispenser.

4. Understanding Any

Although star projections offer great flexibility, they aren’t always the perfect solution.

Enter Any, the root of Kotlin’s type hierarchy. Unlike *, which represents an unknown type, Any specifically represents any non-nullable type. This distinction leads to some crucial differences.

Let’s revisit our peekAtNextTreat() function, but this time, we’ll try to use Any instead of *:

fun peekAtNextTreatAny(dispenser: TreatDispenser<Any>) { 
    val nextTreat = dispenser.peekNextTreat()
    println("The next treat is: $nextTreat")
}

Invoking the above function for our candyDispenser instance results in a type mismatch error:

peekAtNextTreatAny(candyDispenser) // Error: Type mismatch

This is because candyDispenser is of type TreatDispenser<Candy>, and Candy isn’t Any. Even though Candy inherits from Any, the compiler enforces strict type matching when using Any in generics.

This highlights a key difference: Any is restrictive and only accepts non-nullable types. Hence, this function call would fail if our Candy class allowed null values (Candy?).

5. Comparison Summary

In the below table, let’s summarize the usage of Any vs. * as per various criteria:

6. Conclusion

In essence, Any represents any non-nullable type, allowing for flexibility but potentially sacrificing type safety. Star projections (*), on the other hand, represent an unknown type, offering greater type safety but limiting flexibility.

To summarise, we must always choose between Any and * projections in Kotlin depending on our specific needs. Let’s remember that selecting the right tool ensures our code’s effectiveness.

       

Comments

• I think nullability has nothing to do with ... by fantaman

Related Stories

• Create a List From Kotlin Flow
• Avoiding the ConcurrentModificationException in Kotlin
• Parallel Operations on Kotlin Collections

 

1. Overview

Publish-subscribe (PubSub) is a messaging pattern in which publishers send messages to a channel and subscribers listen to messages on that channel. Redis is a popular in-memory data store that also supports messaging.

In this tutorial, we’ll explore implementing a publish-subscribe messaging system using Kotlin and Redis. To do this, we’ll build a small application in which a publisher sends messages to a Redis channel and a subscriber listens to messages on that channel.

2. Code Setup

Let’s start by setting up our Kotlin project and adding the building blocks for our messaging system.

2.1. Dependencies

We’ll use the lettuce-core library to interact with Redis in our Kotlin application:

<dependencies>
    <dependency>
        <groupId>io.lettuce.core</groupId>
        <artifactId>lettuce-core</artifactId>
        <version>6.5.0.RELEASE</version>
    </dependency>
</dependencies>

Additionally, we’ll use an embedded Redis server for testing purposes to avoid using an external Redis server:

<dependency> 
    <groupId>com.github.kstyrc</groupId> 
    <artifactId>embedded-redis</artifactId> 
    <version>1.4.3</version> 
</dependency>

2.2. Connecting to Redis

Next, we’ll create a Redis connection using Lettuce:

object RedisConnectionManager: AutoCloseable {
    private val redisClient: RedisClient = RedisClient.create("redis://localhost:6379")
    private val connection: StatefulRedisConnection<String, String> = redisClient.connect()
    override fun close() {
        connection.close()
        redisClient.shutdown()
    }
}

We create a singleton object RedisConnectionManager that manages the Redis connection. In this class, we instantiate a RedisClient instance using the create() method and then connect() to the embedded Redis server.

Additionally, we define a close() method to close the connection. If not called explicitly, the connection closes when the object is garbage collected as we implement the AutoCloseable interface.

2.3. Sync and Async Commands

Additionally, let’s define methods to expose Redis’ sync() and async() commands. Specifically, we’ll use the sync methods to publish messages to Redis. Conversely, async commands are required to create a subscriber and listen to a channel.

First, we’ll manage the sync commands:

fun redisSyncCommands(): RedisCommands<String, String>? {
    return connection.sync()
}

Significantly, the redisSyncCommands() method gets the synchronous operations from the connection and returns an object encapsulating them.

Next, we’ll look at the async commands:

fun redisPubSubAsyncCommands(messageListener: MessageListener): RedisPubSubAsyncCommands<String, String> {
    val pubSubConnection = redisClient.connectPubSub()
    pubSubConnection.addListener(messageListener)
    return pubSubConnection.async()
}

The redisPubSubAsyncCommands() method creates a pub-sub connection to the server, adds a listener, and finally returns the async commands for the connection.

2.4. Message DTO

To represent our message, let’s define a simple data class. This class holds the message content:

data class Message(val content: String)

Here, we define a Message data class with a single content property. This class encapsulates the messages that we’ll send through Redis.

3. Consumer

Now we can create a consumer that listens to messages on a specific channel. This requires a subscription to the channel and a listener to handle incoming messages.

3.1. Listener

First, let’s create a class that handles incoming messages. One of the simplest ways to achieve this is by extending the RedisPubSubAdapter class provided by Lettuce. It’s an abstract class that implements the RedisMessageListener interface:

class MessageListener : RedisPubSubAdapter<String, String>() {
    var latch: CountDownLatch = CountDownLatch(1)
    var messagesReceived: List<String> = emptyList()
    override fun message(channel: String?, message: String?) {
        println("Received message: $message from channel: $channel")
        messagesReceived = messagesReceived.plus(message!!)
        latch.countDown()
    }
}

The message() method is called whenever a message is received on the subscribed channel. In this method, we log the received message and the channel name.

For testing purposes, we also use a CountDownLatch to wait for messages. We’ll store any messages received by the listener in messagesReceived so that we can verify them later.

3.2. Subscribing to a Channel

Furthermore, we need to connect our listener to a Redis channel. For this, we’ll also create a subscriber that subscribes to a specific channel and listens for messages.

Let’s create a method to subscribe to a channel:

class RedisSubscriber(private val messageListener: MessageListener) {
    fun subscribeToChannel(channel: String) {
        RedisConnectionManager.redisPubSubAsyncCommands(messageListener).subscribe(channel)
    }
}

Here are a few key points about the RedisSubscriber class:

• It takes a MessageListener instance as a parameter in the constructor.
• The subscribeToChannel() method calls the redisPubSubAsyncCommands() to create a pub-sub connection.
• The connection will also add the MessageListener to the specified channel.
• We then subscribe to the specified channel using the subscribe() method.

When a message is received on the channel, the message() method of the MessageListener class is called, and the message content is logged.

4. Publisher

Now that we have a consumer listening to messages, let’s create a publisher that sends messages to a Redis channel.

We’ll create a method that publishes a message to a specific channel:

class RedisPublisher {
    fun publishMessage(channel: String, message: Message) {
        RedisConnectionManager.redisCommands()?.publish(channel, message.content)
        println("Message published: $message")
    }
}

This method takes a channel name and a Message object as parameters. Using the commands from the RedisConnectionManager, it publishes the message content to the specified channel using the publish() method.

5. Testing

To test our messaging system, we’ll write a test case that publishes a message to a channel and verifies that the consumer receives the message.

5.1. Test Class

To start, let’s create a test class and set up our connection:

@TestInstance(TestInstance.Lifecycle.PER_CLASS)
class RedisSubscriberUnitTest {
    val messageListener = MessageListener()
    val redisSubscriber = RedisSubscriber(messageListener)
    val redisPublisher = RedisPublisher()
    val channel = "channel"
    val message = Message("Hello, Redis!")
    val redisServer = RedisServer(6379)
    @BeforeAll
    fun setUp() {
        redisServer.start()
    }
    @AfterAll
    fun tearDown() {
        RedisConnectionManager.close()
        redisServer.stop()
    }
}

In the setUp() method, we start an embedded Redis server using the RedisServer class of the embedded-redis library. Similarly, in the tearDown() method, we close the Redis connection and stop the embedded Redis server.

5.2. Test Case

Now, let’s write a test case that publishes a message to a channel and verifies that the consumer receives the message:

@Test
fun givenMessageListener_whenMessagePublished_thenMessageReceived() {
    redisSubscriber.subscribeToChannel(channel)
    redisPublisher.publishMessage(channel, message)
    messageListener.latch.await(500, TimeUnit.MILLISECONDS)
    assertEquals(message.content, messageListener.messagesReceived.get(0))
}

First, we subscribe to the channel using the RedisSubscriber instance, or we’ll miss the published message. Then, we publish a message to the channel using the RedisPublisher instance.

The latch in the MessageListener class waits for the message to be received.

Finally, we assert that the message the listener receives is the same as the message published.

6. Conclusion

In this article, we explored implementing a publish-subscribe messaging system using Kotlin and Redis. We set up a Redis connection, created a consumer to listen to messages on a channel, and finally a publisher to send messages to the channel. We also tested our system by publishing and consuming messages.

     

Related Stories

• Introduction to Apache Log4j Kotlin
• Excluding a Library from All Dependencies in Kotlin DSL in Gradle
• Plotting Charts in Kotlin With Kandy

 

1. Introduction

When working on a Kotlin project with Gradle, there are scenarios where we need to exclude certain libraries or transitive dependencies to avoid conflicts or reduce the size of our final build. Gradle provides mechanisms to exclude libraries globally across all dependencies.

In this tutorial, we’ll explore how to exclude a library or a transitive dependency using the Kotlin DSL syntax in a Gradle build script.

2. Understanding the Problem

Dependencies in a Gradle project often include other libraries as transitive dependencies. However, there are several reasons why we might need to exclude specific libraries:

• Version Conflicts: Different dependencies may include varying versions of the same library, causing compatibility issues or runtime errors. For example, if two libraries bring in different versions of commons-logging, we might face runtime inconsistencies.
• Optimizing Build Size: Unused libraries can add unnecessary weight to the final build. Excluding these unwanted transitive dependencies helps reduce the overall size of the project output.
• Replacing Default Libraries: Sometimes, we need to replace a default dependency with an alternative. For instance, certain Spring Boot starters include commons-logging by default, but we might prefer to use slf4j instead. By excluding the unwanted library, we can include the replacement explicitly.

By understanding these common scenarios, we can effectively manage the dependency graph and ensure only the required libraries are included in the build.

3. Excluding a Library in Kotlin DSL

Gradle provides flexible ways to exclude unwanted libraries or transitive dependencies in a Kotlin DSL build script. We can achieve this either globally, across all dependencies, or at a more granular level for specific dependencies. The exclusion mechanisms leverage the configurations and dependencies blocks, allowing us to control the dependency graph precisely.

In the following sections, we’ll explore how to exclude libraries globally or for individual dependencies using the Kotlin DSL syntax.

3.1. Exclude a Library Globally

To exclude a library or transitive dependency globally across all dependencies, we use the configurations block in our build.gradle.kts file:

configurations.all {
    exclude(group = "org.apache.commons", module = "commons-logging")
}

In this example, the exclude function specifies the group and module of the dependency we want to remove. The group refers to the group ID, and the module refers to the artifact ID of the library.

3.2. Excluding a Library from Specific Dependencies

If we only want to exclude a library from a particular dependency instead of applying it globally, we use the dependencies block with an inline exclude function:

dependencies {
    implementation("org.springframework.boot:spring-boot-starter-web") {
        exclude(group = "org.apache.commons", module = "commons-logging")
    }
}

In this example, the spring-boot-starter-web dependency includes commons-logging as a transitive dependency. By adding the exclude block, we remove commons-logging specifically for this dependency while leaving other dependencies unaffected.

3.3. Excluding Multiple Libraries

To exclude multiple libraries, we can add multiple exclude statements inside the configurations block:

configurations.all {
    exclude(group = "org.apache.commons", module = "commons-logging")
    exclude(group = "ch.qos.logback", module = "logback-classic")
}

Alternatively, for better readability and maintainability, we can define a list of exclusions and loop over them:

val exclusions = listOf(
    "org.apache.commons" to "commons-logging",
    "ch.qos.logback" to "logback-classic"
)
configurations.all {
    exclusions.forEach { (group, module) ->
        exclude(group = group, module = module)
    }
}

This approach is particularly useful when dealing with a large number of exclusions, as it keeps the code clean and easier to maintain.

4. Verifying Exclusions

To verify that exclusions are applied, we can use Gradle’s dependency insight task:

./gradlew dependencies --configuration implementation

This will display the resolved dependency graph, helping us confirm that the unwanted libraries are excluded.

5. Conclusion

In this article, we explored how to exclude a library or transitive dependency in Gradle using Kotlin DSL. Whether globally or for a specific dependency, Gradle provides flexible options to manage exclusions effectively.

By carefully applying exclusions, we can resolve dependency conflicts, optimize our build, and ensure compatibility with desired libraries.

     

Related Stories

• Building a Kotlin Library Using Gradle
• Introduction to Apache Log4j Kotlin
• PubSub Messaging With Kotlin Redis

 

1. Overview

When working with documents stored in the cloud, we sometimes need to download them to perform additional processing. The process of downloading can be automated with a program that can take the URL as a parameter to get these documents and store them later in the file system of our choice.

In this tutorial, we’ll see how to download PDF files with Kotlin using Coroutines and the Retrofit library.

2. Implementation

Using Retrofit and Kotlin Coroutines is an efficient approach when we want to perform HTTP requests to get resources stored in the cloud. In the next flowchart, we can see the process we’ll apply:

Let’s start defining the first component of the process.

3. Retrofit Service Interface

First, we need to define a service interface for Retrofit that will expose a function for downloading files:

interface FileDownloadService {
    @GET
    suspend fun downloadFile(@Url fileUrl: String): ResponseBody
}

The @GET annotation specifies the HTTP method we want to execute, and the @Url parameter allows us to dynamically pass the URL of the file we need to download.

4. Retrofit Instance

Now we need to create and setup the Retrofit instance to perform the HTTP requests:

val retrofit = Retrofit.Builder()
  .baseUrl("https://example.com/")
  .build()
val service = retrofit.create(FileDownloadService::class.java)

Since we’ll pass the @Url parameter dynamically, the baseUrl will not be used in the request. However, this is a required parameter in Retrofit configuration and for that reason, we need to define a valid URL as a placeholder.

5. Download the PDF

Now that our Retrofit service is ready, we can execute the download process in a suspend function. We need the Dispatchers.IO to ensure that the operation runs on a separate thread:

suspend fun downloadPdfWithRetrofit(url: String, outputFile: File) {
    // retrofit service setup
    withContext(Dispatchers.IO) {
        val responseBody = service.downloadFile(url)
        // Save the file to disk
        responseBody.byteStream().use { inputStream ->
            FileOutputStream(outputFile).use { outputStream ->
                inputStream.copyTo(outputStream)
            }
        }
        println("File downloaded successfully to ${outputFile.absolutePath}")
    }
}

6. Execute the Coroutine

Now we can execute our function in a runBlocking block. This block provides the support to run coroutines functions synchronously. In the next example, we can see how to pass the URL parameter to the function and download the PDF file:

fun main() {
    val url = "https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf"
    val outputFile = File("sample.pdf")
    runBlocking {
        try {
            downloadPdfWithRetrofit(url, outputFile)
        } catch (e: Exception) {
            println("Failed to download PDF: ${e.message}")
        }
    }
}

7. Conclusion

In this tutorial, we’ve explored an efficient approach to downloading PDF files using Retrofit and the support of Kotlin Coroutines.

     

Related Stories

• Kotlin Flow catch() Operator
• Removing Ambiguity in Kotlin Function by Reference
• Format Number With Thousand Separator in Kotlin