Observer & State: UI That Never Lies

Part 2 of 8 GoF Patterns That Decide If Your Android App Scales

Observer — UI That Never Goes Stale

The Observer pattern defines a one-to-many dependency: when one object (the subject) changes state, all its observers are notified automatically.

In Android this used to mean manually calling notifyDataSetChanged(), toggling visibility in callbacks, and debugging why the UI showed old data after a rotation. StateFlow fixed all of that.

The Problem Without Observer

1
// Old approach — manual sync, guaranteed to drift
2
class LoginActivity : AppCompatActivity() {
3

4
    private fun doLogin() {
5
        showLoading()
6
        api.login(email, password) { result ->
7
            hideLoading()
8
            if (result.isSuccess) {
9
                navigateToHome()
10
            } else {
11
                showError(result.error)
12
                // Did we hide loading? Did we re-enable the button?
13
                // What about rotation? Config changes? 🤯
14
            }
15
        }
16
    }
17
}

Each callback adds a new branch. Rotation destroys the Activity mid-flight. Error states get forgotten.

Observer with StateFlow

1
// ViewModel is the subject — emits state changes
2
class LoginViewModel(
3
    private val authRepo: AuthRepository
4
) : ViewModel() {
5

6
    private val _uiState = MutableStateFlow<LoginUiState>(LoginUiState.Idle)
7
    val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()
8

9
    fun login(email: String, password: String) {
10
        viewModelScope.launch {
11
            _uiState.value = LoginUiState.Loading
12
            authRepo.login(email, password)
13
                .onSuccess { _uiState.value = LoginUiState.Success(it) }
14
                .onFailure { _uiState.value = LoginUiState.Error(it.message) }
15
        }
16
    }
17
}

1
// Fragment is the observer — reacts to every emission
2
lifecycleScope.launch {
3
    repeatOnLifecycle(Lifecycle.State.STARTED) {
4
        viewModel.uiState.collect { state ->
5
            when (state) {
6
                is LoginUiState.Idle    -> showForm()
7
                is LoginUiState.Loading -> showLoader()
8
                is LoginUiState.Success -> navigateToHome(state.user)
9
                is LoginUiState.Error   -> showError(state.message)
10
            }
11
        }
12
    }
13
}

The Fragment never calls the API. The ViewModel never touches Views. Rotation, back stack, process death — all handled by the lifecycle-aware collector.

With Jetpack Compose

1
@Composable
2
fun LoginScreen(viewModel: LoginViewModel = viewModel()) {
3
    val state by viewModel.uiState.collectAsStateWithLifecycle()
4

5
    when (state) {
6
        is LoginUiState.Idle    -> LoginForm(onLogin = viewModel::login)
7
        is LoginUiState.Loading -> CircularProgressIndicator()
8
        is LoginUiState.Success -> LaunchedEffect(Unit) { onNavigateHome() }
9
        is LoginUiState.Error   -> ErrorSnackbar(state.message)
10
    }
11
}

One when expression. Zero manual View toggling.

State — The Compiler as Your Safety Net

The State pattern allows an object to alter its behaviour when its internal state changes. In Android terms: every screen has a finite set of states, and you should make impossible states impossible at the type level.

The Problem: Boolean Soup

1
// Which combinations are valid? Nobody knows.
2
class LoginViewModel : ViewModel() {
3
    val isLoading = MutableLiveData<Boolean>()
4
    val isError = MutableLiveData<Boolean>()
5
    val errorMessage = MutableLiveData<String?>()
6
    val isSuccess = MutableLiveData<Boolean>()
7
    val user = MutableLiveData<User?>()
8

9
    // Can isLoading and isError both be true? Can isSuccess be true with a null user?
10
    // The compiler has no idea. Runtime crashes will find out for you.
11
}

With 4 booleans you have 16 theoretical combinations. Maybe 3 are valid. The compiler won’t tell you.

Sealed Class UiState

1
// Every valid state is a type. Every invalid state is impossible.
2
sealed class LoginUiState {
3
    object Idle    : LoginUiState()
4
    object Loading : LoginUiState()
5
    data class Success(val user: User)      : LoginUiState()
6
    data class Error(val message: String?)  : LoginUiState()
7
}

Why this matters:

1
// The compiler enforces exhaustive handling
2
when (state) {
3
    LoginUiState.Idle    -> ...
4
    LoginUiState.Loading -> ...
5
    is LoginUiState.Success -> ...  // Compiler knows state.user is non-null
6
    is LoginUiState.Error   -> ...  // Compiler knows state.message exists
7
    // Forget a branch → compile error, not a runtime crash
8
}

You cannot access state.user when the state is Loading. You cannot have a Success with a null user. The type system prevents the bug before the test ever runs.

Real-World UiState Example

1
sealed class ProductDetailUiState {
2
    object Loading : ProductDetailUiState()
3

4
    data class Content(
5
        val product: Product,
6
        val relatedProducts: List<Product>,
7
        val isFavorite: Boolean,
8
        val stockStatus: StockStatus
9
    ) : ProductDetailUiState()
10

11
    data class Error(
12
        val message: String,
13
        val canRetry: Boolean
14
    ) : ProductDetailUiState()
15

16
    // Add states as the screen grows — existing when() blocks will
17
    // produce compile errors if you forget to handle the new state
18
    object OutOfRegion : ProductDetailUiState()
19
}

One sealed class per screen. One collect in the Fragment or one when in the composable.

Observer + State Together

The real power comes from combining them:

1
// ViewModel combines both patterns
2
val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()  // Observer
3
//                     ^^^^^^^^^^^^^
4
//                     Sealed class enforces valid states        // State

Observer ensures the UI always reflects the latest state. State ensures that latest state is always valid.

Result: UI that never lies.

Next Up

Part 3: Proxy & Facade → — how to build a cache gate that’s invisible to callers, and how to keep your ViewModels thin.