The Problem with Boolean Flags and Nullable States

I remember working on a large-scale Android application a few years back where our ViewModel was a mess of mutable variables. We had isLoading as a Boolean, errorMessage as a nullable String, and data as a nullable List. It was a recipe for disaster. You could technically have a state where isLoading was true AND data was not null, or worse, where both were null, leaving the UI in a state of limbo. This is what I call impossible states, and they are the silent killers of predictable codebases.

In a professional production environment, we want our code to be exhaustive. We want the compiler to tell us, "Hey, you forgot to handle the error case," rather than finding out via a NullPointerException in production. This is where Kotlin's Sealed Classes (and the newer Sealed Interfaces) become your best friend.

The Solution: Modeling Domain States as a Hierarchy

A sealed class allows you to define a restricted class hierarchy. Unlike a standard class, all subclasses of a sealed class must be known at compile time. This gives the compiler the ability to perform exhaustive checks in when expressions. If you add a new state to your sealed class, the compiler will immediately throw an error in every when block that handles that class, forcing you to account for the new state.

Let's look at a real-world scenario: fetching data from a remote API. Instead of managing multiple variables, we wrap the entire result in a single, immutable state object.

/**
 * Represents the UI state for a screen fetching user profiles.
 * Using a sealed class ensures that the UI can only be in ONE 
 * of these states at any given time.
 */
global sealed class UiState {
    // Represents the initial state before any action is taken
    object Idle : UiState()

    // Represents the loading state while waiting for data
    object Loading : UiState()

    // Represents a successful data retrieval
    data class Success(val data: T) : UiState()

    // Represents a failure with a specific error message
    data class Error(val message: String) : UiState()
}

Implementing the Pattern in a ViewModel

Now that we have our state model, using it in a ViewModel is incredibly clean. Notice how we don't need to check for nulls or manage multiple booleans. We simply emit a single state object that represents the current truth of the screen.

class UserViewModel(private val repository: UserRepository) : ViewModel() {

    // Using MutableStateFlow for reactive UI updates in Kotlin Coroutines
    private val _uiState = MutableStateFlow>>(UiState.Idle)
    val uiState: StateFlow>> = _uiState.asStateFlow()

    fun fetchUsers() {
        viewModelScope.launch {
            _uiState.value = UiState.Loading
            try {
                val users = repository.getUsers()
                _uiState.value = UiState.Success(users)
            } catch (e: Exception) {
                _uiState.value = UiState.Error(e.message?: "An unknown error occurred")
            }
        }
    }
}

The Magic of Exhaustive 'when" Expressions

The real power is realized when you consume this state in your UI layer (like an Activity, Fragment, or Compose function). Because the compiler knows all possible subclasses of UiState, you don't need an else clause in your when statement. This is the key to writing defensive, self-documenting code.

// Example in a UI component
fun render(state: UiState>) {
    when (state) {
        is UiState.Idle -> { 
            showPlaceholder() 
        }
        is UiState.Loading -> {
            showProgressBar() 
        }
        is UiState.Success -> {
            hideProgressBar()
            displayUsers(state.data) // No casting needed! Smart casting handles it.
        }
        is UiState.Error -> {
            hideProgressBar()
            showErrorMessage(state.message)
        }
        // No 'else' branch needed! If we add 'UiState.Empty', the compiler fails here.
    }
}

Why This Matters for Senior Developers

When you are mentoring junior developers or conducting code reviews, this pattern should be a standard recommendation. Here is why it's superior:

  • Elimination of Illegal States: You physically cannot be in a state where you have both isLoading = true and data!= null if they are represented as distinct branches of a sealed class.
  • Smart Casting: Kotlin's compiler is smart enough to know that if state is UiState.Success, then state.data must exist. This reduces boilerplate and casting.
  • Maintenance Safety: If your product requirements change and you need a PartialSuccess state, adding it to the sealed class will create a compiler-driven checklist of everywhere that state needs to be handled.
>

"Make the impossible states unrepresentable." — This is a core principle of functional programming that Kotlin's type system allows us to implement beautifully.

In short, stop using multiple variables to track what your screen is doing. Use a sealed class to define exactly what your UI can be. Your future self—and your debugging sessions—will thank you.