DEV Community: Valerii Popov

Sealed Interfaces vs. Sealed Classes in Kotlin: When and Why to Use Each

Valerii Popov — Thu, 31 Oct 2024 10:07:19 +0000

Kotlin’s sealed classes are widely used to create closed hierarchies, especially when representing UI states or other fixed types. But with the introduction of sealed interfaces in Kotlin 1.5, developers now have another powerful tool for structuring type-safe hierarchies. Both allow for exhaustive when expressions and ensure type safety, but they serve slightly different purposes and shine in different contexts. Let’s explore when and why to use sealed classes versus sealed interfaces in Kotlin, with practical examples, including Android UI components.

Sealed Classes in Kotlin

Sealed classes are ideal when you need a limited set of subclasses that represent specific states, often within a single context. A sealed class hierarchy allows you to create a closed set of subclasses—meaning no other classes outside this file can extend the sealed class. This is especially useful for representing states in a when expression, ensuring every possible subclass is accounted for at compile time.

Example: UI State Representation with Sealed Classes
In Android development, sealed classes are a common choice for handling UI state. Let’s imagine a simple loading screen that can display three possible states: Loading, Success, or Error. Here’s how you might implement this with a sealed class:

sealed class UiState {
    object Loading : UiState()
    data class Success(val data: String) : UiState()
    data class Error(val message: String) : UiState()
}

fun handleUiState(uiState: UiState) {
    when (uiState) {
        is UiState.Loading -> showLoadingSpinner()
        is UiState.Success -> showData(uiState.data)
        is UiState.Error -> showError(uiState.message)
    }
}

fun showLoadingSpinner() { /* Show loading spinner */ }
fun showData(data: String) { /* Display data */ }
fun showError(message: String) { /* Show error message */ }

In this example:

The UiState sealed class represents a closed hierarchy where only specific states (Loading, Success, and Error) are valid.
The when expression in handleUiState ensures that all states are handled exhaustively, giving us compile-time safety.
Sealed classes are well-suited to representing UI states because they provide clear and structured representations of finite states, making it easier to reason about the different UI scenarios.

Sealed Interfaces in Kotlin

Sealed interfaces, introduced in Kotlin 1.5, add flexibility to sealed hierarchies. Unlike sealed classes, which enforce a single superclass, sealed interfaces allow you to combine multiple types, as Kotlin supports multiple interfaces but only single inheritance for classes. This makes sealed interfaces a great choice for flexible hierarchies where shared behavior is needed across unrelated types.

Example: Shared ViewHolder Types with Sealed Interfaces
Let’s say we’re building an app that displays different items in a RecyclerView list, and each item type has a unique ViewHolder. We could use sealed interfaces to define shared behavior among ViewHolders, allowing flexibility while ensuring that only specific types implement the interface.

sealed interface ListItem

data class TextItem(val text: String) : ListItem
data class ImageItem(val imageUrl: String) : ListItem
data class VideoItem(val videoUrl: String) : ListItem

abstract class ListItemViewHolder(view: View) : RecyclerView.ViewHolder(view) {
    abstract fun bind(item: ListItem)
}

class TextItemViewHolder(view: View) : ListItemViewHolder(view) {
    override fun bind(item: ListItem) {
        if (item is TextItem) {
            // Bind text item data
        }
    }
}

class ImageItemViewHolder(view: View) : ListItemViewHolder(view) {
    override fun bind(item: ListItem) {
        if (item is ImageItem) {
            // Bind image item data
        }
    }
}

class VideoItemViewHolder(view: View) : ListItemViewHolder(view) {
    override fun bind(item: ListItem) {
        if (item is VideoItem) {
            // Bind video item data
        }
    }
}

In this example:

The ListItem sealed interface defines a set of allowed item types (TextItem, ImageItem, VideoItem).
Each item type is flexible and can be combined with other interfaces if needed, making the sealed interface versatile.
ListItemViewHolder subclasses each handle a specific type of item, enabling shared behavior without enforcing a strict hierarchy.
This structure is especially useful for RecyclerView, where flexibility and type-safety are often needed to handle diverse item types.

Choosing Between Sealed Classes and Sealed Interfaces

Understanding when to use sealed classes versus sealed interfaces largely depends on the use case:

Use Sealed Classes for fixed, finite states where each subclass represents a distinct, unchangeable state. They work well in cases like UI state handling, where each possible state (e.g., loading, success, error) is predefined and must be accounted for.

Use Sealed Interfaces when you need flexibility and want to share behavior across different types that aren’t necessarily in a strict inheritance hierarchy. Sealed interfaces are ideal for cases where multiple types share behavior but also may combine with other interfaces or classes.

Performance and Compatibility Considerations

Since sealed classes and sealed interfaces are both evaluated at compile-time for exhaustiveness, they don’t introduce additional runtime overhead, making them performant. However, it’s worth noting that:

Sealed Classes: Each subclass must be nested or within the same file as the sealed class, limiting their flexibility.
Sealed Interfaces: Since they support multiple inheritance, sealed interfaces are more versatile but should be used cautiously to avoid creating overly complex hierarchies.

Conclusion

Sealed classes and sealed interfaces both bring powerful type safety and code clarity to Kotlin. By understanding when to use each, you can build more robust, flexible, and readable code structures. Whether you’re representing fixed UI states with sealed classes or creating flexible hierarchies for items in a list with sealed interfaces, Kotlin’s sealed types offer a range of options to support your architecture.

Choosing the right approach can significantly improve the maintainability and readability of your code, making your Kotlin projects more robust and reliable in the long run.

Mastering runCatching in Kotlin: How to Avoid Coroutine Cancellation Issues

Valerii Popov — Tue, 29 Oct 2024 12:18:52 +0000

The runCatching function in Kotlin is a powerful tool that lets you handle exceptions within a block of code while preserving the result. However, when working with coroutines, runCatching can introduce unexpected issues. Because it catches all exceptions, including CancellationException, it can interfere with proper coroutine cancellation. In this article, we’ll explore how runCatching works, its potential pitfalls in coroutines, and how to build custom Result extensions to handle exceptions safely without impacting cancellation.

What is `runCatching`?

runCatching is a utility function in Kotlin that executes a block of code and wraps the result in a Result object. If the block completes successfully, it returns a Result with the value. If an exception occurs, it wraps the exception instead, so you can handle errors more concisely without try-catch blocks.

Here’s an example of how runCatching is typically used:

val result = runCatching {
    // Some operation that might throw an exception
    performNetworkRequest()
}.onSuccess {
    println("Success: $it")
}.onFailure {
    println("Error: ${it.message}")
}

Pitfall: Catching `CancellationException`

In Kotlin, coroutine cancellations are controlled by throwing CancellationException. When a coroutine is cancelled, it throws this exception up the call stack, which propagates the cancellation signal. However, because runCatching catches all exceptions, including CancellationException, it can intercept and handle cancellation attempts unintentionally, preventing the coroutine from being properly cancelled.

Example of runCatching Interfering with Cancellation:

// Hypothetical Retrofit service with a function that returns a Response<String>
interface ApiService {
    suspend fun fetchDataFromServer(): Response<String>
}

// Function that performs a network call and handles errors using runCatching
suspend fun fetchData(apiService: ApiService): Result<String> {
    return runCatching {
        val response = apiService.fetchDataFromServer()

        // Check if the response is successful
        if (response.isSuccessful) {
            response.body() ?: throw Exception("Empty response body")
        } else {
            throw HttpException(response)
        }
    }
}

In this code, runCatching is used to wrap the Retrofit network call. This might look like a concise way to handle errors, but it has an important flaw when dealing with coroutines: runCatching catches all exceptions, including CancellationException.
When fetchDataFromServer() is called in a coroutine and that coroutine is cancelled, CancellationException is thrown to signal that the coroutine should stop running. However, because runCatching catches all exceptions indiscriminately, it will catch the CancellationException along with any other exceptions. This can prevent the coroutine from cancelling correctly, which may lead to unexpected issues such as unresponsive UI or memory leaks.

Solution: Custom Extension Functions for `Result`

To safely handle exceptions without interfering with coroutine cancellation, we can create custom extensions on Result:

onFailureOrRethrow: An extension function that lets you specify an exception type to rethrow, allowing other exceptions to be handled normally.
onFailureIgnoreCancellation: An extension that specifically ignores CancellationException, allowing you to handle other exceptions without blocking coroutine cancellation.

Here’s how to implement these extensions:

inline fun <reified E : Throwable, T> Result<T>.onFailureOrRethrow(action: (Throwable) -> Unit): Result<T> {
    return onFailure { if (it is E) throw it else action(it) }
}

inline fun <T> Result<T>.onFailureIgnoreCancellation(action: (Throwable) -> Unit): Result<T> {
    return onFailureOrRethrow<CancellationException, T>(action)
}

With these extensions, you can handle failures more selectively:

val result = runCatching {
    val response = apiService.fetchDataFromServer()
    if (response.isSuccessful) {
        response.body() ?: throw Exception("Empty response body")
    } else {
        throw HttpException(response)
    }
}.onFailureIgnoreCancellation {
    // Handle errors other than CancellationException
    println("Handled non-cancellation error: ${it.message}")
}

Here, if a CancellationException is thrown, it bypasses the failure handler, allowing the coroutine to cancel as intended.

Conclusion

Using runCatching in Kotlin simplifies exception handling but requires extra caution in coroutines due to its tendency to catch all exceptions, including CancellationException. By creating custom extensions like onFailureOrRethrow and onFailureIgnoreCancellation, you can ensure that your code handles errors flexibly while respecting coroutine cancellation.

These extensions provide a safer, more reliable approach to managing errors in coroutines and can be incorporated into your codebase to streamline exception handling in a variety of coroutine contexts.

Inline Classes in Kotlin: Why, Where, and How to Use Them

Valerii Popov — Mon, 28 Oct 2024 08:36:10 +0000

Inline classes in Kotlin allow you to wrap a single value with a custom type to improve code safety and readability. Unlike regular classes, inline classes do not add runtime overhead since they get "inlined" by the compiler—meaning no actual object is created at runtime. This article explores why and where to use inline classes, how they differ from typealias, and includes examples.

Why Use Inline Classes?

Type Safety: Inline classes help prevent accidental usage of similar data types. For example, a UserId and a ProductId may both be represented as Strings, but they are not interchangeable concepts. Inline classes ensure that they remain distinct types at compile time.
Runtime Performance: With inline classes, Kotlin removes the need to create wrapper objects by inlining the wrapped value wherever possible. This makes them more efficient for performance that often pass around small values like IDs, codes, or identifiers.
Readable Code: Inline classes give meaningful names to otherwise generic values, making code more self-explanatory and easier to understand.

Defining an Inline Class

To define an inline class in Kotlin, use the @JvmInline annotation along with value class, and ensure it contains only one val property:

@JvmInline
value class UserId(val id: String)
@JvmInline
value class ProductId(val id: String)

fun fetchUser(userId: UserId) {
    println("Fetching user with ID: ${userId.id}")
}

fun main() {
    fetchUser(UserId("1")) // OK
    fetchUser(ProductId("1")) // NOT OK. Even though inlined type is String
}

In the above example, UserId and ProductId are inline classes that wrap String. Even though they have the same underlying type (String), Kotlin treats them as distinct types, preventing accidental mix-ups.

When and Where to Use Inline Classes

Inline classes are especially useful when you need to:

Wrap Identifiers or Codes: When you have unique IDs or codes (e.g., UserId, ProductId) and want to avoid the risk of accidentally swapping them.
Reduce Overhead in High-Frequency Calls: For functions or APIs where performance matters, inline classes avoid the cost of additional object creation.
Encapsulate Domain-Specific Types: They’re great for representing domain-specific types, such as currency, weight, or distance, without the need for full-fledged classes.

Comparison with `typealias`

typealias in Kotlin is another way to add meaning to a type without creating a new one. However, unlike inline classes, typealias only creates an alias without actual type safety at compile time:

typealias UserId = String
typealias ProductId = String

fun printProductId(id: ProductId) {
    println("Product ID: $id")
}

// The following would compile, even though it's an incorrect usage.
val userId: UserId = "user_id"
printProductId(userId) // Will print Product ID: user_id

With typealias, UserId and ProductId are just aliases of String, so Kotlin treats them as interchangeable, which risks accidental misuse. Inline classes avoid this issue by creating distinct types for UserId and ProductId at compile time.

Conclusion

Inline classes in Kotlin provide a robust way to add type safety, improve code readability, and optimize performance for lightweight wrappers around values. They are particularly useful for identifiers or small values that would otherwise create unnecessary object allocation. By using inline classes, you get the best of both worlds: compile-time safety without runtime overhead.

Do We Really Need Use Cases in Mobile Apps?

Valerii Popov — Sat, 26 Oct 2024 02:20:23 +0000

In mobile development, use cases are often used to encapsulate business logic, providing a clear structure for handling interactions between the app’s presentation layer and data layer. However, in many mobile apps, especially those with straightforward data access needs, use cases end up being simple wrappers around repository calls. Let’s explore what use cases are, why they’re commonly used as repository wrappers, and when you might want to consider omitting them altogether.

1. What is a Use Case?

A use case in software development represents a specific action or task within the application’s business logic. In mobile development, use cases are classes that contain single responsibilities, often designed to perform a single action, like FetchUserProfile or GetUserPosts. They serve as intermediaries between the ViewModel (presentation layer) and the repository (data layer), aiming to encapsulate business logic for a single action.

Here’s an example of a simple use case class in Kotlin:

// Example Use Case in Kotlin
class FetchUserProfileUseCase(
    private val userRepository: UserRepository
) {
    suspend operator fun invoke(userId: String): User {
        // The use case orchestrates the fetching of user profile data.
        return userRepository.getUserProfile(userId)
    }
}

This structure can be beneficial if there’s complex logic involved in obtaining the User data, like validating the userId or applying filters, caching, or error handling. However, if the use case merely calls the repository function, it might add unnecessary layers to the code.

2. Use Cases as Wrappers: Adding an Extra Layer

In many mobile apps, especially those with straightforward data requirements, use cases often end up acting as thin wrappers around repository calls, simply forwarding requests to the repository without additional business logic.

Here’s an example of a "wrapper" use case:

class GetPostsUseCase(private val postRepository: PostRepository) {
    suspend operator fun invoke(): List<Post> {
        // Just calls the repository, without any additional processing.
        return postRepository.getPosts()
    }
}

In this example, GetPostsUseCase doesn’t provide any real value on top of what the repository already does. The repository itself could be directly accessed by the ViewModel, following the Repository Pattern, without sacrificing readability or maintainability. This pattern calls data from a centralized source and could be an ideal way to streamline code.

3. When to Consider Omitting Use Cases

In cases where a use case doesn’t add value beyond calling the repository, omitting it can simplify your codebase. Calling the data layer directly via a repository in these situations makes your code easier to read and maintain without sacrificing structure.

class ProfileViewModel(
    private val userRepository: UserRepository
) : ViewModel() {
    fun getUserProfile(userId: String) = liveData {
        emit(userRepository.getUserProfile(userId)) // Directly calling the repository.
    }
}

By directly using the UserRepository, we reduce the need for an extra class and method that serves no additional purpose. For straightforward data access patterns, the repository pattern alone can keep the code well-organized while avoiding the verbosity and potential maintenance of unnecessary use cases.

Conclusion: Streamline Where Possible

While use cases can provide clarity and structure in complex applications with business logic-heavy features, they are often overused as simple data wrappers in mobile apps. In situations where they don’t contribute additional functionality or encapsulate business logic, omitting empty use cases can simplify your code. As always, choose what best fits your app’s needs and keep your code as lean as possible.

Hello World! 👋

Valerii Popov — Fri, 25 Oct 2024 02:32:11 +0000

Hello World! 👋

Hi, I’m Inoshishi, an Android engineer with 7 years of experience building native apps. I take on programming challenges at my own pace, always learning and improving.

This is actually my first time writing posts, so it’s a new journey for me. I’ll be sharing what I learn, the challenges I face, and how I tackle them. Whether it’s architecting apps or debugging, I hope to offer something useful along the way.

Let’s enjoy this journey together, one step at a time 🚀

DEV Community: Valerii Popov

Sealed Interfaces vs. Sealed Classes in Kotlin: When and Why to Use Each

Sealed Classes in Kotlin

Sealed Interfaces in Kotlin

Choosing Between Sealed Classes and Sealed Interfaces

Performance and Compatibility Considerations

Conclusion

Mastering runCatching in Kotlin: How to Avoid Coroutine Cancellation Issues

What is runCatching?

Pitfall: Catching CancellationException

Solution: Custom Extension Functions for Result

Conclusion

Inline Classes in Kotlin: Why, Where, and How to Use Them

Why Use Inline Classes?

Defining an Inline Class

When and Where to Use Inline Classes

Comparison with typealias

Conclusion

Do We Really Need Use Cases in Mobile Apps?

1. What is a Use Case?

2. Use Cases as Wrappers: Adding an Extra Layer

3. When to Consider Omitting Use Cases

Conclusion: Streamline Where Possible

Hello World! 👋

What is `runCatching`?

Pitfall: Catching `CancellationException`

Solution: Custom Extension Functions for `Result`

Comparison with `typealias`