Building The WeatherViewModel

The WeatherViewModel is responsible for managing UI-related state and coordinating with the WeatherRepository to fetch weather data from the network. It exposes state using StateFlow for reactive UI updates and handles all business logic related to weather data.

class WeatherViewModel(private val repository: WeatherRepository) : ViewModel() {
    private val _zipcode = MutableStateFlow("")
    val zipcode: StateFlow = _zipcode.asStateFlow()

    private val _weatherResponse = MutableStateFlow(null)
    val weatherResponse: StateFlow = _weatherResponse.asStateFlow()

    private val _errorMessage = MutableStateFlow(null)
    val errorMessage: StateFlow = _errorMessage.asStateFlow()

    fun onZipcodeChange(newZipcode: String) {
        _zipcode.value = newZipcode
    }

    fun fetchWeather() {
        viewModelScope.launch {
            _errorMessage.value = null // Clear any previous error
            repository.getCurrentWeather(_zipcode.value)
                .onSuccess { response ->
                    _weatherResponse.value = response
                }
                .onFailure { e ->
                    _errorMessage.value = e.message
                    _weatherResponse.value = null
                }
        }
    }

    // Factory for ViewModel injection
    companion object {
        fun provideFactory(repository: WeatherRepository): ViewModelProvider.Factory {
            return object : ViewModelProvider.Factory {
                @Suppress("UNCHECKED_CAST")
                override fun <T : ViewModel> create(modelClass: Class<T>): T {
                    if (modelClass.isAssignableFrom(WeatherViewModel::class.java)) {
                        return WeatherViewModel(repository) as T
                    }
                    throw IllegalArgumentException("Unknown ViewModel class")
                }
            }
        }
    }
}

Code Explanation

The WeatherViewModel is a central component for managing and providing weather data to the UI. It extends ViewModel from Android Architecture Components, which means its lifecycle is independent of UI components (like Activities or Composables) and it survives configuration changes.

Dependency Injection

• class WeatherViewModel(private val repository: WeatherRepository): The ViewModel takes a WeatherRepository as a constructor parameter, following dependency injection principles. This makes the ViewModel testable and decoupled from the data source implementation. The repository handles all network operations and API key management.

State Variables

All UI state is managed using Kotlin's StateFlow, which provides a reactive, lifecycle-aware way to manage state that integrates seamlessly with Jetpack Compose's collectAsState():

• private val _zipcode = MutableStateFlow(""): A private, mutable StateFlow that holds the user-entered zip code. This state is managed by the ViewModel rather than the UI composable, ensuring centralized state management.
• val zipcode: StateFlow<String> = _zipcode.asStateFlow(): The public, immutable StateFlow that exposes the zipcode to the UI. The UI observes this using collectAsState().
• private val _weatherResponse = MutableStateFlow<WeatherResponse?>(null): A private, mutable StateFlow that holds the weather data. It's nullable, meaning it can hold weather data or be null if no data is available or an error occurs. The underscore prefix (`_`) indicates it's a mutable internal state.
• val weatherResponse: StateFlow<WeatherResponse?> = _weatherResponse.asStateFlow(): The public, immutable StateFlow that exposes the weather data to the UI. Any changes to _weatherResponse will automatically trigger UI recomposition when observed with collectAsState().
• private val _errorMessage = MutableStateFlow<String?>(null): A private, mutable StateFlow that holds any error messages. It's a nullable String, set to null when there's no error.
• val errorMessage: StateFlow<String?> = _errorMessage.asStateFlow(): The public, immutable StateFlow that exposes error messages to the UI.

State Update Functions

• fun onZipcodeChange(newZipcode: String): A function called by the UI when the user types in the zipcode input field. It updates the _zipcode state, ensuring all state changes go through the ViewModel.

fetchWeather Function

The fetchWeather function is responsible for initiating the weather data retrieval process. It reads the current zipcode from the ViewModel's internal state and delegates the actual network request to the repository.

• fun fetchWeather(): The public function called by the UI to request weather data. Notice it doesn't take a zipcode parameter because it reads the current value from _zipcode.value, demonstrating that all state is centralized in the ViewModel.
• viewModelScope.launch { ... }: This launches a coroutine within the ViewModel's scope. viewModelScope is a CoroutineScope tied to the ViewModel's lifecycle, meaning that any coroutines launched within it will be automatically cancelled when the ViewModel is cleared, preventing memory leaks.
• _errorMessage.value = null: Before making a new API call, any previous error message is cleared to provide a clean state for the new request.
• repository.getCurrentWeather(_zipcode.value): This calls the repository's getCurrentWeather method, passing the current zipcode value. The repository handles all the details of the network request, including API key management and error handling. The repository returns a Result<WeatherResponse>, which is a Kotlin sealed class that represents either success or failure without throwing exceptions.
• .onSuccess { response -> ... }: If the repository call is successful, this lambda receives the WeatherResponse and assigns it to _weatherResponse.value, which automatically updates the exposed weatherResponse StateFlow and triggers UI recomposition.
• .onFailure { e -> ... }: If the repository call fails, this lambda receives the exception. The error message is extracted and assigned to _errorMessage.value, and _weatherResponse.value is set to null to clear any previous weather data.

ViewModel Factory

The companion object contains a factory method for creating instances of WeatherViewModel with the required dependencies. This is necessary because Android's ViewModel system requires a special way to create ViewModels when they have constructor parameters.

Why a Factory is Needed: Since WeatherViewModel requires a WeatherRepository in its constructor (dependency injection), we can't use the default ViewModel creation mechanism. Android's ViewModelProvider needs a factory that knows how to create our ViewModel with its dependencies.

• companion object { ... }: In Kotlin, a companion object is like a static class in Java. It allows you to call methods directly on the class (e.g., WeatherViewModel.provideFactory(repository)) without needing an instance of the class. This is the perfect place for a factory method.
• fun provideFactory(repository: WeatherRepository): ViewModelProvider.Factory: This is a static method that creates and returns a factory object. It takes the WeatherRepository dependency as a parameter and "captures" it inside the factory object so it can be used later when creating the ViewModel.
• return object : ViewModelProvider.Factory { ... }: This creates an anonymous object that implements the ViewModelProvider.Factory interface. An anonymous object is an object created on-the-fly without a name. This object must implement the create method defined by the interface.
• @Suppress("UNCHECKED_CAST"): This annotation suppresses a compiler warning about type casting. The warning appears because we're casting from a specific type (WeatherViewModel) to a generic type (T), but our type checking ensures it's safe.
• override fun <T : ViewModel> create(modelClass: Class<T>): T: This is the method required by ViewModelProvider.Factory. When Android needs to create a ViewModel, it calls this method with the class type it wants to create. The generic type T must be a subclass of ViewModel.
• if (modelClass.isAssignableFrom(WeatherViewModel::class.java)): This checks if the requested ViewModel class is WeatherViewModel or a subclass of it. isAssignableFrom returns true if the modelClass is the same as or a subclass of WeatherViewModel. This ensures we only create ViewModels we know how to handle.
• return WeatherViewModel(repository) as T: If the check passes, we create a new WeatherViewModel instance, passing the repository that was captured when the factory was created. We then cast it to type T (the generic type requested by Android) and return it. This is where dependency injection happens—the repository is injected into the ViewModel constructor.
• throw IllegalArgumentException("Unknown ViewModel class"): If someone tries to use this factory to create a different type of ViewModel (not WeatherViewModel), we throw an exception because this factory doesn't know how to create other ViewModel types.

How It's Used: In the UI composable (like WeatherAppScreen), you call viewModel(factory = WeatherViewModel.provideFactory(weatherRepository)). This tells Jetpack Compose to use our custom factory when creating the ViewModel, ensuring the repository dependency is properly injected.

Benefits: This factory pattern enables proper dependency injection, making the ViewModel testable (you can inject a mock repository during testing), maintainable (dependencies are explicit), and following clean architecture principles.