Kotlin

Kotlin Coroutines simplify asynchronous programming, but handling exceptions effectively is crucial to prevent crashes and unexpected behavior. Many developers rely on try-catch, but coroutines offer more powerful ways to manage exceptions. This post explores advanced techniques for Exception Handling in Kotlin Coroutines, ensuring robust and resilient applications.

Understanding Exception Handling in Kotlin Coroutines

Kotlin Coroutines introduce structured concurrency, which changes how exceptions propagate. Unlike traditional threading models, coroutine exceptions bubble up to their parent by default. However, handling them efficiently requires more than a simple try-catch.

Basic Try-Catch in Coroutines

Before diving into advanced techniques, let’s look at the basic approach:

suspend fun fetchData() {
    try {
        val result = withContext(Dispatchers.IO) { riskyOperation() }
        println("Data: $result")
    } catch (e: Exception) {
        println("Caught exception: ${e.message}")
    }
}

This works but doesn’t leverage coroutine-specific features. Let’s explore better alternatives.

Using CoroutineExceptionHandler

Kotlin provides CoroutineExceptionHandler to catch uncaught exceptions in coroutines. However, it works only for launch, not async.

val exceptionHandler = CoroutineExceptionHandler { _, exception ->
    println("Caught exception in handler: ${exception.localizedMessage}")
}

fun main() = runBlocking {
    val scope = CoroutineScope(Job() + Dispatchers.Default + exceptionHandler)
    
    scope.launch {
        throw RuntimeException("Something went wrong")
    }

    delay(100) // Give time for the exception to be handled
}

Why Use CoroutineExceptionHandler?

• It catches uncaught exceptions from launch coroutines.
• It prevents app crashes by handling errors at the scope level.
• Works well with structured concurrency if used at the root scope.

It doesn’t work for async, as deferred results require explicit handling.

Handling Exceptions in async

Unlike launch, async returns a Deferred result, meaning exceptions won’t be thrown until await() is called.

val deferred = async {
    throw RuntimeException("Deferred error")
}

try {
    deferred.await()
} catch (e: Exception) {
    println("Caught exception: ${e.message}")
}

To ensure safety, always wrap await() in a try-catch block or use structured exception handling mechanisms.

SupervisorJob for Independent Child Coroutines

By default, when a child coroutine fails, it cancels the entire parent scope. However, a SupervisorJob allows independent coroutine failures without affecting other coroutines in the same scope.

import kotlinx.coroutines.*

fun main() = runBlocking {
    val supervisor = SupervisorJob()
    val scope = CoroutineScope(supervisor + Dispatchers.Default) // Ensuring a dispatcher

    val job1 = scope.launch {
        delay(500)
        throw IllegalStateException("Job 1 failed")
    }

    val job2 = scope.launch {
        delay(1000)
        println("Job 2 completed successfully")
    }

    job1.join() // Wait for Job 1 (it will fail)
    job2.join() // Wait for Job 2 (should still succeed)
}

How It Works

• Without SupervisorJob: If one coroutine fails, the entire scope is canceled, stopping all child coroutines.
• With SupervisorJob: A coroutine failure does not affect others, allowing independent execution.

Why Use SupervisorJob?

Prevents cascading failures — a single failure doesn’t cancel the whole scope.
Allows independent coroutines — useful when tasks should run separately, even if one fails.

Using supervisorScope for Localized Error Handling

Instead of using SupervisorJob, we can use supervisorScope, which provides similar behavior but at the coroutine scope level rather than the job level:

import kotlinx.coroutines.*

fun main() = runBlocking {
    supervisorScope {  // Creates a temporary supervisor scope
        launch {
            throw Exception("Failed task") // This coroutine fails
        }
        launch {
            delay(1000)
            println("Other task completed successfully") // This will still execute
        }
    }
}

If one child fails, other children keep running (unlike a regular CoroutineScope). Exceptions are still propagated to the parent scope if unhandled.

When to Use Each?

• Use SupervisorJob when you need a long-lived CoroutineScope (e.g., ViewModel, Application scope).
• Use supervisorScope when you need temporary failure isolation inside an existing coroutine.

Best Practices for Exception Handling in Kotlin Coroutines

1. Use CoroutineExceptionHandler for launch-based coroutines.
2. Handle exceptions explicitly when using async.
3. Leverage SupervisorJob to prevent cascading failures.
4. Wrap critical code inside supervisorScope when needed.
5. Log errors properly instead of just printing them.
6. Always clean up resources (e.g., closing network connections) using finally.

Conclusion

Exception Handling in Kotlin Coroutines is more than just try-catch. With CoroutineExceptionHandler, SupervisorJob, and supervisorScope, you can write robust and resilient coroutine-based applications. Implement these best practices to ensure your coroutines handle failures gracefully, keeping your app stable and efficient.

Kotlin is packed with features that make it both powerful and expressive. One such hidden gem is the underscore (_) operator for type arguments in Kotlin. While it may not be as widely known as other features, it provides a concise and efficient way to work with generics.

In this post, we’ll explore what this operator does, why it’s useful, and how you can leverage it to simplify your Kotlin code.

What is the Underscore (_) Operator for Type Arguments in Kotlin?

In Kotlin, when working with generics, you often have to specify the exact type argument. However, sometimes you just want Kotlin to infer the type for you without explicitly providing it. The underscore (_) operator allows you to do just that—it acts as a placeholder for type arguments.

The syntax looks like this:

val list: List<_> = listOf(1, 2, 3)

Here, instead of specifying List<Int>, we use _, and Kotlin automatically infers that the list contains integers.

Understanding Underscore ( _ ) Operator for type arguments with Example

The underscore operator _ in Kotlin is a type inference placeholder that allows the Kotlin compiler to automatically infer the type of an argument based on the context and other explicitly specified types.

abstract class SomeClass<T> {
    abstract fun execute() : T
}

class SomeImplementation : SomeClass<String>() {
    override fun execute(): String = "Test"
}

class OtherImplementation : SomeClass<Int>() {
    override fun execute(): Int = 42
}

object Runner {
    inline fun <reified S: SomeClass<T>, T> run() : T {
        return S::class.java.getDeclaredConstructor().newInstance().execute()
    }
}

fun main() {
    // T is inferred as String because SomeImplementation derives from SomeClass<String>
    val s = Runner.run<SomeImplementation, _>()
    assert(s == "Test")
    // T is inferred as Int because OtherImplementation derives from SomeClass<Int>
    val n = Runner.run<OtherImplementation, _>()
    assert(n == 42)
}

Don’t worry! Let’s break down the code step by step:

1. In this code, we have an abstract class called SomeClass with a generic type T. It declares an abstract function execute() that returns an object of type T.
2. We have a class called SomeImplementation which extends SomeClass and specifies the generic type as String. It overrides the execute() function and returns the string value "Test".
3. Similarly, we have another class called OtherImplementation which extends SomeClass and specifies the generic type as Int. It overrides the execute() function and returns the integer value 42.
4. Below that, we have an object called Runner with a function run(). This function is generic and has two type parameters S and T. It uses the reified keyword to access the type information at runtime. Inside the function, it creates an instance of the specified class S using reflection (getDeclaredConstructor().newInstance()) and calls the execute() function on it, returning the result of type T.

In the above code, the underscore operator is used in the main() function when calling the Runner.run() function. Let’s take a closer look:

val s = Runner.run<SomeImplementation, _>()

In this line, the type parameter T is explicitly specified as _ for the Runner.run() function. Here, _ acts as a placeholder for the type to be inferred by the compiler. Since SomeImplementation derives from SomeClass<String>, the compiler infers T as String for this invocation. Therefore, the variable s is inferred to be of type String, and the Runner.run() function returns the result of executing SomeImplementation, which is the string "Test".

val n = Runner.run<OtherImplementation, _>()

Similarly, in this line, the type parameter T is specified as _ for the Runner.run() function. Since OtherImplementation derives from SomeClass<Int>, the compiler infers T as Int for this invocation. Consequently, the variable n is inferred to be of type Int, and the Runner.run() function returns the result of executing OtherImplementation, which is the integer 42.

By using the underscore operator _ as a type argument, the compiler can automatically infer the appropriate type based on the context and the explicitly specified types.

Why Use the Underscore (_) Operator for Type Arguments in Kotlin?

Using the underscore operator has several benefits:

1. Simplifies Type Declarations — You don’t have to explicitly specify type arguments when they can be inferred.
2. Improves Code Readability — It makes code cleaner and easier to read, especially when dealing with complex generics.
3. Reduces Boilerplate Code — Less repetitive type annotations mean more concise code.
4. Works with Generic Functions — It allows you to call generic functions without explicitly passing type arguments.

How to Use the Underscore (_) Operator in Kotlin

1. Using _ with Generic Functions

Kotlin lets you use _ when calling generic functions. Suppose you have a function that takes a generic type parameter:

fun <T> printType(value: T) {
    println("Type: ${value::class.simpleName}")
}

You can call this function without explicitly specifying the type argument:

printType<_>(42) // Kotlin infers the type as Int

2. Using _ with Collections

The underscore operator works well with collections, making them more flexible when type inference is possible.

val numbers: List<_> = listOf(10, 20, 30)
println(numbers) // Output: [10, 20, 30]

Here, Kotlin automatically infers that numbers is a List<Int>.

3. _ in Function Returns

If a function returns a generic type, _ allows Kotlin to infer it without explicit declaration.

fun getList(): List<_> = listOf("Kotlin", "Java", "Swift")

Kotlin infers that getList() returns a List<String> without us specifying it explicitly.

When to Avoid Using the Underscore (_) Operator in Kotlin

While the underscore operator is useful, there are situations where avoiding it can improve code clarity and maintainability:

• When Type Inference Fails — If Kotlin cannot determine the type of a variable or lambda parameter, using _ will result in a compilation error.
• In Public APIs — Overusing _ in public functions can make the API less clear, potentially confusing users who rely on explicit parameter names for readability.
• When Explicit Types Improve Readability — In complex expressions or function signatures, explicitly defining types can enhance code comprehension and maintainability.

Conclusion

The underscore (_) operator for type arguments in Kotlin is a simple yet powerful tool that helps reduce boilerplate code and improve readability. Whether you’re working with collections, or generic functions, it can make your code cleaner and more concise.

Next time you’re dealing with generics, give _ a try and let Kotlin do the heavy lifting for you..!

Kotlin’s coroutines simplify asynchronous programming, but managing them effectively requires a solid understanding of CoroutineScope. Without it, your app may spawn uncontrolled coroutines, leading to memory leaks or unpredictable behavior. In this blog, we’ll take a deep dive into CoroutineScope in Kotlin — exploring its importance, how to use it effectively, and how to avoid common pitfalls.

What is CoroutineScope in Kotlin?

CoroutineScope in Kotlin is an interface that defines a boundary for coroutines. It ensures that all coroutines launched within it follow structured concurrency principles, meaning they get canceled when the scope is canceled.

Key Features of CoroutineScope:

• Manages the lifecycle of coroutines.
• Ensures structured concurrency, preventing orphaned coroutines.
• Provides a CoroutineContext, allowing customization of dispatchers.

Let’s look at how CoroutineScope in Kotlin works in practice.

How to Use CoroutineScope in Kotlin

Creating a CoroutineScope

You can create a custom CoroutineScope using Job and a CoroutineDispatcher:

class MyCustomScope : CoroutineScope {
    private val job = Job()
    override val coroutineContext: CoroutineContext
        get() = Dispatchers.IO + job

    fun launchTask() {
        launch {
            delay(1000)
            println("Task completed")
        }
    }
    
    fun cancelScope() {
        job.cancel()
    }
}

Here,

• We define a class MyCustomScope implementing CoroutineScope.
• It uses Job to manage coroutine cancellation.
• The coroutineContext specifies Dispatchers.IO for background execution.
• launchTask() starts a coroutine within the scope.
• cancelScope() ensures proper cleanup when the task is no longer needed.

Built-in CoroutineScopes in Kotlin

Kotlin provides predefined CoroutineScope implementations:

1. GlobalScope (Use with Caution)

GlobalScope creates coroutines that run as long as the application is alive:

GlobalScope.launch {
    delay(2000)
    println("Running in GlobalScope")
}

Why Avoid GlobalScope?

• It is not tied to any lifecycle, risking memory leaks.
• It runs until the process ends, making it harder to manage.

2. CoroutineScope with ViewModel (Best for Android Apps)

In Android, ViewModelScope ensures coroutines cancel when the ViewModel is cleared:

class MyViewModel : ViewModel() {
    fun fetchData() {
        viewModelScope.launch {
            val result = fetchFromNetwork()
            println("Data: $result")
        }
    }
}

• viewModelScope.launch {} ensures coroutines cancel when the ViewModel is destroyed.
• Helps avoid memory leaks in UI components.

3. LifecycleScope (For UI Components)

When working with Activity or Fragment, lifecycleScope ties coroutines to the lifecycle:

class MyActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        lifecycleScope.launch {
            val data = fetchData()
            println("Data loaded: $data")
        }
    }
}

• lifecycleScope.launch {} ensures the coroutine cancels when the activity is destroyed.

Best Practices for Using CoroutineScope in Kotlin

1. Prefer Built-in Scopes: Use viewModelScope and lifecycleScope for UI-related tasks.
2. Avoid GlobalScope: Unless absolutely necessary, avoid it to prevent memory leaks.
3. Always Cancel Coroutines: If using a custom CoroutineScope, ensure you cancel jobs when they’re no longer needed.
4. Use SupervisorJob for Independent Coroutines: It ensures that if a child coroutine fails, it does not cancel its siblings or the parent scope.

Conclusion

CoroutineScope in Kotlin is crucial for structured concurrency, ensuring that coroutines are properly managed, canceled, and executed within a defined lifecycle. By using viewModelScope, lifecycleScope, and custom scopes wisely, you can build efficient, bug-free Kotlin applications.

Kotlin is a modern programming language that embraces functional programming principles, and lambdas are an essential part of it. When working with lambdas, you might have noticed that they can access variables from their surrounding scope. But how does capturing final variables in Kotlin lambda actually work behind the scenes?

In this blog post, we’ll take a deep dive into this concept and explore the internal workings of final variable capture in Kotlin lambdas.

Understanding Capturing Final Variable in Kotlin Lambdas

Before diving into the technical details, let’s first understand what variable capturing means. When you define a lambda inside a function or block of code, it can access variables that are declared outside of its own scope.

Kotlin follows Java’s concept of effectively final variables, meaning that variables captured in lambdas must be final (i.e., immutable) or treated as final.

fun main() {
    val message = "Hello, softAai..!"   // Final variable
    
    val printMessage = {
        println(message) // Capturing 'message' inside lambda
    }
    
    printMessage() // Output: Hello, softAai..!
}

Here, message is captured inside the lambda printMessage. But how does Kotlin manage this internally? Let’s find out.

What Happens Behind the Scenes?

When a lambda captures a variable, Kotlin internally converts the lambda into an anonymous class that holds a reference to the captured variable. Let’s see what’s happening at a deeper level.

Lambdas as Anonymous Classes

Under the hood, Kotlin compiles lambdas into anonymous classes that implement the Function interfaces (such as Function0, Function1, etc.).

When a lambda captures a variable from an enclosing scope, the Kotlin compiler transforms the lambda into a class where the captured variable becomes a field of that class.

Decompiling to Java Code

To see what happens behind the scenes, let’s decompile the Kotlin code above into Java:

Note: This is a simplified and understandable decompiled Java code. You might see a slightly different variant when you decompile it on your end.

public final class MainKt {
   public static void main() {
      final String message = "Hello, softAai..!";
      Function0 printMessage = new Function0() {
         public void invoke() {
            System.out.println(message);
         }
      };
      printMessage.invoke();
   }
}

As you can see, the message variable is stored as a final variable inside an anonymous class implementing Function0, which allows it to be used within the lambda.

Let’s go through one more example.

fun main() {
    val number = 10
    
    val multiply = { x: Int -> x * number }
    
    println(multiply(5)) // Output: 50
}

In simplified and understandable Java bytecode, Kotlin translates this lambda into something like this:

public final class MainKt {
    public static void main() {
        final int number = 10;
        
        Function1<Integer, Integer> multiply = new Function1<Integer, Integer>() {
            @Override
            public Integer invoke(Integer x) {
                Intrinsics.checkNotNullParameter(x, "x");
                return x * number;
            }
        };

        System.out.println(multiply.invoke(5)); // Output: 50
    }
}

Here,

• Since number is used inside the lambda, it is captured as a final local variable.
• The lambda is converted into an anonymous inner class implementing Function1<Integer, Integer>. invoke() method is overridden to perform the multiplication.
• This is a Kotlin runtime null-safety check ensuring x is not null.

Why Kotlin Uses This Approach

As seen in the Java equivalent, number is stored as a final field inside the generated class. This ensures that even though the original variable exists in a different scope, it remains accessible within the lambda.

Effectively Final Restriction

One crucial aspect of capturing final variables in Kotlin lambda is that the variable must be effectively final, meaning it cannot change after being assigned.

The choice to enforce capturing only final (or effectively final) variables comes with several benefits:

• Reduced Risk of Race Conditions: Since captured variables cannot be reassigned, the risk of race conditions is lower. However, thread safety is not guaranteed if the variable refers to a mutable object.
• Performance Optimizations: Immutable variables lead to more predictable execution and allow the compiler to optimize bytecode efficiently.
• Cleaner and Safer Code: Prevents accidental mutations and side effects, making the code easier to reason about.

Explore the complete details here: [Main Article URL]

Conclusion

Capturing final variables in Kotlin lambdas works by converting the lambda into an anonymous class where the captured variables are stored as immutable fields. This mechanism ensures safety, performance, and predictability in your code. Understanding how capturing final variables in Kotlin lambda works behind the scenes can help you write more efficient and bug-free Kotlin code.

When working with Kotlin, you’ll often come across two keywords for defining immutable variables: const and val. While both ensure that the value cannot be reassigned, they serve different purposes and operate under distinct rules. In this guide, we’ll take an in-depth look at const vs val, their key differences, use cases, and best practices.

What is const in Kotlin?

The const keyword in Kotlin is used to declare compile-time constants. This means that the value is known and assigned at compile time, rather than at runtime.

Characteristics of const:

• Declared using const val (not const var since it must be immutable).
• Can only be assigned primitives (Int, Double, Boolean, String, etc.).
• Cannot be assigned a function call or any computed value.
• Must be declared at the top level, inside an object, or within a companion object.

Example of const Usage:

const val APP_NAME = "MyKotlinApp"
const val MAX_RETRY_COUNT = 3

Here, APP_NAME and MAX_RETRY_COUNT are known at compile time and will never change throughout the application lifecycle.

Where You Can Use const

• Inside top-level declarations (outside any function or class).
• Inside an object or companion object.

Example in an object:

object Config {
    const val API_ENDPOINT = "https://api.softaai.com"
}

This approach ensures that constants are easily accessible and prevent unnecessary object instantiation.

What is val in Kotlin?

The val keyword is used for declaring runtime immutable variables. This means that once a val variable is assigned, it cannot be changed, but its value is determined at runtime.

Characteristics of val:

• Assigned a value at runtime, not compile-time.
• Can hold any type of object, including lists, function calls, and class instances.
• Can be declared anywhere, including inside functions.
• Cannot be reassigned, but the referenced object may be mutable, like MutableList (the content of that object can change).

Example of val Usage:

val timestamp = System.currentTimeMillis() // Assigned at runtime
val user = User("Amol Pawar") // Holding an object instance

Here, timestamp gets a value at runtime when the function executes.

Where You Can Use val

• Inside functions
• Inside classes and objects
• As local variables
• As properties of a class

Example Inside a Function:

fun fetchData() {
    val currentTime = System.currentTimeMillis()
    println("Data fetched at: $currentTime")
}

currentTime gets assigned a value dynamically when the function runs.

Key Differences Between const and val

When to Use const vs val?

Use const when:

• The value never changes and is known at compile time.
• You need a global constant (e.g., API keys, app configurations).
• The value is a primitive or string.

Use val when:

• The value is immutable but assigned at runtime.
• You need to store computed values like timestamps or function results.
• You are working with objects, lists, or complex types.

Practical Examples and Use Cases

Using const for App Configuration

object Config {
    const val BASE_URL = "https://api.softaai.com"
    const val DEFAULT_TIMEOUT = 5000
}

Here, BASE_URL and DEFAULT_TIMEOUT are known constants that never change.

Using val for Mutable Objects

fun getUsers(): List<String> {
    val users = listOf("Amol", "Baban", "Chetan")
    return users
}

users is immutable, but it holds a list that’s assigned at runtime.

Using val in Jetpack Compose

@Composable
fun Greeting(name: String) {
    val greetingMessage = "Hello, $name!" // Evaluated at runtime
    Text(text = greetingMessage)
}

greetingMessage is assigned dynamically based on the name parameter.

Conclusion

Understanding the difference between const and val is crucial for writing efficient and well-structured Kotlin code. While both ensure immutability, const is for compile-time constants, whereas val is for runtime immutable variables.

By applying the right choice in different scenarios, you can optimize your Kotlin applications for better readability, performance, and maintainability.

Kotlin’s coroutines make asynchronous programming easier and more efficient. However, managing coroutines properly requires an understanding of CoroutineScope. Without it, your application might create uncontrolled coroutines, leading to memory leaks, unexpected behavior, or inefficient resource usage.

In this blog, we’ll take a deep dive CoroutineScope in Kotlin, explore how to create a custom CoroutineScope, and discuss best practices for managing coroutines effectively.

Understanding CoroutineScope in Kotlin

A CoroutineScope defines the lifecycle and context for coroutines. Every coroutine launched inside a CoroutineScope inherits its CoroutineContext, which includes elements like a Job for tracking execution and a CoroutineDispatcher for thread management.

Why Is CoroutineScope Important?

• Prevents memory leaks: Ensures that coroutines are properly canceled when no longer needed.
• Manages structured concurrency: Helps group coroutines so they can be controlled together.
• Defines execution context: Assigns dispatcher (e.g., Dispatchers.IO, Dispatchers.Main) for coroutines.

Using predefined scopes like viewModelScope (Android ViewModel) or lifecycleScope (Android components) is often recommended. However, in some cases, you may need to create a custom CoroutineScope.

Creating a Custom CoroutineScope in Kotlin

You can define a custom CoroutineScope by implementing the CoroutineScope interface and specifying a coroutineContext. 

import kotlin.coroutines.CoroutineContext
import kotlinx.coroutines.*

class MyCustomScope : CoroutineScope {
    private val job = Job()
    override val coroutineContext: CoroutineContext
        get() = Dispatchers.IO + job // Assigning a background dispatcher

    fun launchTask() {
        launch(coroutineContext) { // Explicitly using coroutineContext
            println("Coroutine started on: $coroutineContext")
            delay(1000)
            println("Task completed")
        }
    }

    fun cancelScope() {
        println("Cancelling scope with context: $coroutineContext")
        job.cancel() // Cancels all coroutines in this scope
    }
}

fun main() {
    val myScope = MyCustomScope()
    myScope.launchTask()

    runBlocking { delay(1500) } // Ensures coroutine runs before program exits
    myScope.cancelScope() // Cleanup
}



/////////////////////// OUTPUT ///////////////////////////////

Coroutine started on: [StandaloneCoroutine{Active}@7822150c, Dispatchers.IO]
Task completed
Cancelling scope with context: [JobImpl{Active}@711f39f9, Dispatchers.IO]

Here,

MyCustomScope implements CoroutineScope, requiring it to define coroutineContext.

Manages Coroutine Lifecycle:

• private val job = Job() creates a root job that manages all launched coroutines.
• override val coroutineContext provides a combination of Dispatchers.IO (background execution) and Job (coroutine tracking).

Explicitly Uses coroutineContext:

• launch(coroutineContext) { ... } ensures that the correct context is used when launching coroutines. 
• Logging println("Coroutine started on: $coroutineContext") helps verify execution.

Handles Cleanup:

• cancelScope() calls job.cancel(), terminating all active coroutines.
• This prevents memory leaks and ensures proper resource cleanup.

BTW, When Would We Explicitly Use coroutineContext?

We might explicitly reference coroutineContext in cases like:

Accessing a Specific Dispatcher

println("Running on dispatcher: ${coroutineContext[CoroutineDispatcher]}")

Passing It to Another CoroutineScope

val newScope = CoroutineScope(coroutineContext + SupervisorJob())

Logging or Debugging Coroutine Context

println("Current coroutine context: $coroutineContext")

Basically, we don’t need to explicitly reference coroutineContext because it’s automatically used by coroutine builders (launch, async) inside the scope. However, if we need fine-grained control, debugging, or passing it to another scope, we can reference it explicitly.

Best Practices for Managing Custom CoroutineScopes

While defining a custom CoroutineScope can be useful, it should be done with caution. Here are some best practices:

Prefer Built-in Scopes When Possible

• Use viewModelScope in Android ViewModels.
• Use lifecycleScope for UI-related tasks.

Always Cancel the Scope

• Call job.cancel() when the scope is no longer needed.
• In Android, tie the scope’s lifecycle to an appropriate component.

Use Structured Concurrency

• Instead of manually managing jobs, prefer SupervisorJob() where appropriate.

val scope = CoroutineScope(SupervisorJob() + Dispatchers.IO)

Avoid Launching Coroutines in GlobalScope

• GlobalScope.launch is dangerous because it creates coroutines that run for the lifetime of the application.

Conclusion

CoroutineScope is essential for managing coroutines effectively. Creating a custom CoroutineScope can be useful when working outside lifecycle-aware components, but it requires careful handling to prevent memory leaks. By following best practices—such as canceling coroutines properly and preferring structured concurrency—you can ensure your coroutines are managed efficiently.