Creating a maintainable, flexible codebase is not easy but is an essential part of software engineering. In this series we’ll take a look at a simple, functional weather app and look at some of the issues in its design. We shall then refactor and re-design it to create a codebase which will be easier to maintain, less prone to bugs, and easier to add features to. This series is not going to be a deep dive in to the techniques and technologies that we’re going to use, but will be more an exploration of what benefits they give us. In this article we’ll look at how the changes we’ve made so far make adding new features much easier.

In the previous article we added a data layer to provide a five weather forecast. With that in place hooking up the UI is actually pretty straightforward. Part of the reason for this straightforwardness is because of the work that we have done within the data layer to provide the data in an easy to consume format. The FiveDayForecast object contains a of DailyItem objects, each of which contains a summarised daily forecast. We can consume this as-is without having to do any further transformation. Presenting the data to the UI is an easily digestible form is crucial to keeping our UI code simply about the UI and not the data itself.

To consume this data, we first need to make it available to the UI, and we can do this through our Dagger 2 dependency injection. First we need to create a provider for our WeatherForecastDao:

Dagger now has the additional provider it needs for the constructor injection of the ForecastRepository, so we can now add a binding for this:

Those with a good memory may notice that we have also changed the name of the ViewModel from CurrentWeatherViewModel to the more generic WeatherViewModel. This reflects that the ViewModel now provides more than just the current forecast, it also provides five-day forecast data:

There is one more small thing that we need to do because we separated the Repository and LiveData from being the same class. Previously we could just use the same instance wherever we needed either object type, but that will no longer work. Instead we need a provides method which will provide an instance of the relevant LiveData type from the property of the repository, and these will be used for the constructor injection of WeatherViewModel:

It may seem odd that we haven’t just added these two provider functions to the existing ViewModelModule, but Dagger 2 does not permit both @Binds and @Provides to be used in the same module, so we no option but to separate them.

If we add this to the WeatherStationComponent then the Dagger object graph now contains all of that is necessary to be able to inject new and improved WeatherViewModel:

In CurrentWeatherFragment, we can now obtain a FiveDayForecast LiveData instance and begin observing it:

We haven’t yet written that bindForecast() function which gets invoked when the live data changes, but we’ll get to that shortly.

We’re going to display the forecast data in a RecyclerView named forecasts which appears below the current weather data that we are already displaying.

The only thing remaining is to implement the bindForecast() method that we saw earlier:

I’ve kept this simple to demonstrate how little additional code is required in the Fragment (I make it around 15 lines) which is really quite impressive! However, for a production app I would be inclined to be a bit smarter in the bindForecast() function and actually use DiffUtil to calculate the delta, rather than use the blunderbuss of notifyDataSetChanged().

With our Fragment updated, let’s take a look at DailyForecastAdapter:

There’s nothing unusual happening here either – the individual item layouts are from R.layout.daily_forecast_item, and we use DailyForecastViewHolder to perform the binding of a DailyItem object to the individual Views:

Yet again, this is all pretty standard stuff and we’ve already looked at what the Converter does for us in a previous article.

The UI changes have all be really quite straightforward and that is because the only thing that we now have to do in the UI is actually display the data which is provided in a really easy to consume form. There is virtually no business logic in the UI. Furthermore, the only additional data item that we have visibility of is FiveDayForecast (and its inner DataItem class), so if we look back at the Fragment implementation that we had at the start of this series, try to imaging how much more bloated an complex our Fragment would have become if we had added this additional functionality on top of that directly!

Although the transformations that we did in the data layer may have appeared complex when we looked at them, the benefits that we get should be quite apparent now that we see how much simpler it makes our UI code. But we will not stop there, in the next article we’ll take a look at how we can add yet more functionality very easily because of how we have implemented our data layer.

The source code for this article is available here

© , Mark Allison. All rights reserved.

Maintainable Architecture – Five Day Forecast – UI Layer by Styling Android is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
Permissions beyond the scope of this license may be available at

Source link
thanks you RSS link


Please enter your comment!
Please enter your name here