Building The WeatherRepository

The WeatherRepository is responsible for fetching weather data from the network and caching it locally. It is also responsible for returning the cached data if the user is offline, that is not modeled in this example. In a real world application, you would likely have a more complex caching strategy, with different rules for when to fetch from the network and when to use the cached data.

class WeatherRepository(private val weatherApiService: WeatherApiService) {

    // You would typically get the API key from a more secure location
    // or through dependency injection in a real app.
    private val API_KEY = "80d537a4b4cd7a3b10a3c65a70316965"

    suspend fun getCurrentWeather(zipcode: String): Result {
        return try {
            val response = weatherApiService.getCurrentWeather(
                zip = "$zipcode,us",
                appId = API_KEY
            )
            Result.success(response)
        } catch (e: Exception) {
            Result.failure(e)
        }
    }
}

Code Explanation

The WeatherRepository is a crucial component in the clean architecture pattern. It acts as an abstraction layer between the data source (in this case, the network API) and the ViewModel. The Repository pattern ensures that the ViewModel doesn't need to know the details of how data is fetched—whether it comes from a network API, a local database, or a cache.

Dependency Injection

• class WeatherRepository(private val weatherApiService: WeatherApiService): The Repository takes a WeatherApiService (a Retrofit interface) as a constructor parameter. This follows dependency injection principles, making the Repository testable and allowing you to swap out the actual implementation with a mock service during testing. The WeatherApiService is provided by the Retrofit instance created in RetrofitClient.

API Key Management

• private val API_KEY = "80d537a4b4cd7a3b10a3c65a70316965": The API key is stored as a private constant within the Repository. While this works for educational purposes, in a production application, you would typically:
• Store the API key in a secure location (like local.properties for local builds or environment variables for CI/CD)
• Use Android's BuildConfig to inject API keys during the build process
• Implement API key rotation and management strategies
• Never commit API keys to version control systems
• The API key is encapsulated within the Repository, meaning the ViewModel doesn't need to know or manage the API key—it's purely a data source concern.

getCurrentWeather Function

The getCurrentWeather function is the main entry point for fetching weather data. It encapsulates all the network request logic and error handling:

• suspend fun getCurrentWeather(zipcode: String): Result<WeatherResponse>: This is a suspend function (meaning it can be called from a coroutine) that takes a zipcode as a parameter and returns a Result<WeatherResponse>. The Result type is a Kotlin sealed class that represents either success (with the data) or failure (with an exception), allowing for functional error handling without throwing exceptions.
• return try { ... } catch (e: Exception) { ... }: The function uses a try-catch block to handle any exceptions that might occur during the network request. This ensures that exceptions are converted into Result.failure() rather than propagating up and potentially crashing the app.
• val response = weatherApiService.getCurrentWeather(zip = "$zipcode,us", appId = API_KEY): This line makes the actual network request using the injected WeatherApiService. The zipcode is appended with ",us" to specify the country code (United States), and the API key is provided for authentication. Since this is a suspend function call, it will suspend the coroutine until the network request completes.
• Result.success(response): If the network request succeeds without throwing an exception, the response is wrapped in a Result.success() and returned. This allows the ViewModel to handle success cases using .onSuccess { ... }.
• Result.failure(e): If an exception occurs (network error, timeout, etc.), it's caught and wrapped in a Result.failure(). This allows the ViewModel to handle errors using .onFailure { ... } without needing try-catch blocks.

Benefits of the Repository Pattern

• Abstraction: The Repository abstracts the data source implementation. If you later need to add caching or switch to a different API, only the Repository needs to change—the ViewModel remains unchanged.
• Testability: You can easily create a mock or fake repository for testing the ViewModel without making actual network calls.
• Single Responsibility: The Repository has one clear responsibility: fetching weather data. This makes the code easier to understand and maintain.
• Error Handling: The Repository centralizes error handling logic, ensuring consistent error handling throughout the application.
• Future Extensibility: The Repository is designed to be easily extended. For example, you could add caching logic that checks a local database before making a network request, all without changing the ViewModel code.