Observer & State: UI que Nunca Miente

Parte 2 de 8 Patrones GoF que Deciden si tu App Android Escala

Observer — UI que Nunca Queda Desactualizada

El patrón Observer define una dependencia uno-a-muchos: cuando un objeto (el sujeto) cambia de estado, todos sus observadores son notificados automáticamente.

En Android esto antes significaba llamar manualmente notifyDataSetChanged(), alternar visibilidad en callbacks, y debuggear por qué la UI mostraba datos viejos después de una rotación. StateFlow resolvió todo eso.

El Problema Sin Observer

1
// Enfoque viejo — sincronización manual, garantizada a desviarse
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
                // ¿Ocultamos el loading? ¿Reactivamos el botón?
13
                // ¿Y la rotación? ¿Los cambios de configuración? 🤯
14
            }
15
        }
16
    }
17
}

Cada callback agrega una nueva rama. La rotación destruye la Activity a mitad del vuelo. Los estados de error se olvidan.

Observer con StateFlow

1
// ViewModel es el sujeto — emite cambios de estado
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 es el observador — reacciona a cada emisión
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
}

El Fragment nunca llama a la API. El ViewModel nunca toca las Views. Rotación, back stack, muerte del proceso — todo manejado por el collector lifecycle-aware.

Con 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
}

Una expresión when. Cero alternancia manual de Views.

State — El Compilador como Tu Red de Seguridad

El patrón State permite que un objeto altere su comportamiento cuando su estado interno cambia. En términos Android: cada pantalla tiene un conjunto finito de estados, y debes hacer que los estados imposibles sean imposibles a nivel de tipos.

El Problema: Sopa de Booleanos

1
// ¿Cuáles combinaciones son válidas? Nadie lo sabe.
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
    // ¿Pueden isLoading e isError ser true al mismo tiempo? ¿Puede isSuccess ser true con un user null?
10
    // El compilador no tiene idea. Los crashes en runtime te lo harán saber.
11
}

Con 4 booleanos tienes 16 combinaciones teóricas. Quizás 3 son válidas. El compilador no te dirá cuáles.

Sealed Class UiState

1
// Cada estado válido es un tipo. Cada estado inválido es imposible.
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
}

Por qué importa:

1
// El compilador fuerza el manejo exhaustivo
2
when (state) {
3
    LoginUiState.Idle    -> ...
4
    LoginUiState.Loading -> ...
5
    is LoginUiState.Success -> ...  // El compilador sabe que state.user no es null
6
    is LoginUiState.Error   -> ...  // El compilador sabe que state.message existe
7
    // Olvidar una rama → error de compilación, no un crash en runtime
8
}

No puedes acceder a state.user cuando el estado es Loading. No puedes tener un Success con un user null. El sistema de tipos previene el bug antes de que el test siquiera se ejecute.

Ejemplo Real de UiState

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
    // Agrega estados a medida que la pantalla crece — los bloques when() existentes
17
    // producirán errores de compilación si olvidas manejar el nuevo estado
18
    object OutOfRegion : ProductDetailUiState()
19
}

Un sealed class por pantalla. Un collect en el Fragment o un when en el composable.

Observer + State Juntos

El poder real viene de combinarlos:

1
// ViewModel combina ambos patrones
2
val uiState: StateFlow<LoginUiState> = _uiState.asStateFlow()  // Observer
3
//                     ^^^^^^^^^^^^^
4
//                     Sealed class fuerza estados válidos        // State

Observer asegura que la UI siempre refleje el último estado. State asegura que ese último estado siempre sea válido.

Resultado: UI que nunca miente.

Parte 3: Proxy & Facade → — cómo construir un cache gate invisible para quien llama, y cómo mantener tus ViewModels delgados.