Android App Architecture: Data Layer [Part 3]

In the previous article, I described the Domain layer in detail and provided concrete code snippets of how to implement it to be a crucial part of our architecture. In this article, I will try to explain what is Data layer and how we can add this layer to our architecture. As I have mentioned in previous articles, we have separate directories for each Clean Architecture layer (data, domain, feature or presentation) and inside each of them we will have modules for each feature, so based on that, in data, we need to create a new module called data_weather for our weather feature.

What is the Data layer, and how we can implement it in our WeatherApp?

The Data layer is the place where the app needs to deal with APIs and 3rd party libraries. It contains Repositories – the single source of truth for the data, Models, and Data Sources (which can be local or remote). Before we start implementing the Data layer in our application, we need first to take a look at Uncle Bob Clean Architecture image:

Based on this image and my previous article, we can see that there is one base principle that outer layers depend on inner layers, thus, we always start working from the internal parts of the app (for example if we first implement UseCase, how can we return Entity if we didn’t implement it before?). After all, in the previous article, we started with an entirely independent Domain layer for our weather feature, more concretely, we began by implementing Entity, and we will continue to follow the same principle with the Data layer.
For now, in order not to make our app more complex, we will implement a parsing local JSON file called weather.json to get the required data. Later in the next articles, we will switch this for an actual API call to Apixu Weather using Retrofit. In that case, we will show how easy it is to change data sources without affecting the business logic and UI logic of our application if our architecture is correct.
In the directory, data create a data module for our feature called data_weather. Modify build.gradle file to implement core and domain_weather modules:

dependencies {
 implementation project(':core')
 implementation project(':domain_weather')

kapt deps.dagger.daggerCompiler
}

As we mentioned earlier that data_weather would depend on domain_weather module, and it will implement necessary dependencies from the core module. The next step is to create a dummy JSON file. Under leading create assets directory and inside it create dummy JSON called weather.json. Package structure should look like this:

Inside weather.json add dummy values:

{
 "city": "Novi Sad",
 "dateTime": "Sun, Septembar 8, 08:65",
 "weatherImage": "https://openweathermap.org/img/wn/10d@2x.png",
 "temperature": "17°",
 "feelsLike": "23/11 Feels like 17°C",
 "description": "Cloudy",
 "precipitation": "Moderate",
 "uvIndex": "40%"
}

Now we can create a repository. Inside main/java create a package called a repository, and inside it create an interface called WeatherRemoteDataSource. This interface will be a contractor to our fake data source. For now, it should have only one method getWeather(), which will return Single<Weather> because we are returning only one Weather object for now. When we switch data sources, we will change this returning type to Flowable<List<Weather>> to support back pressuring and to return a list of Weather objects.

WeatherRemoteDataSource:

package com.rostojic.weather.repository

import com.rostojic.weather.model.Weather
import io.reactivex.Single

interface WeatherRemoteDataSource {

fun getWeather(): Single<Weather>
}

The next step is to create a repository implementation class inside the same package called WeatherRepositoryImpl. This class will implement the WeatherRepository interface from our domain layer, in our case from domain_weather. Before we start coding our WeatherRepositoryImpl, we need to set a dependency injection for our data module. Inside main/java create package called di. First, we will scope class called WeatherDataScope:

package com.rostojic.weather.di

Import javax.inject.Scope

@Scope
@Retention(AnnotationRetention.RUNTIME)
annotation class WeatherDataScope

After we create a custom scope class for our data module, we need to create a module class, called WeatherDataModule. This module class will provide weather.json path for now:

package com.rostojic.weather.di

import com.rostojic.weather.repository.WeatherRepository
import com.rostojic.weather.repository.WeatherRepositoryImpl
import dagger.Binds
import dagger.Module
import dagger.Provides
import javax.inject.Named

@Module(includes = [WeatherDataModule.BindModule::class])
class WeatherDataModule {

@Provides
 @WeatherDataScope
 @Named("weather_json_path")
 fun provideJsonPath(): String = "weather.json"

@Module
 interface BindModule {

@Binds
 fun bindRepository(repository: WeatherRepositoryImpl): WeatherRepository
 }
}

Later, when we implement a fake data source, we will update this module to provide an instance of a data source. Next is a data component. This component should extend CoreComponent, which we created in the previous article, and is annotated with WeatherDataScope. This component will have only one method, which will provide WeatherRepository instance. Let’s call this component WeatherDataComponent:

package com.rostojic.weather.di

import com.rostojic.core.di.CoreComponent
import com.rostojic.weather.repository.WeatherRepository
import dagger.Component
import javax.inject.Provider

@WeatherDataScope
@Component(modules = [WeatherDataModule::class], dependencies = [CoreComponent::class])
interface WeatherDataComponent : CoreComponent {

fun getWeatherRepository(): Provider<WeatherRepository>
}

And final part for dependency injection in this module is to create object WeatherDataInjector:

package com.rostojic.weather.di

import com.rostojic.core.di.CoreInjector

object WeatherDataInjector {

lateinit var component: WeatherDataComponent

fun initialise() {
 component =
 DaggerWeatherDataComponent.builder().coreComponent(CoreInjector.coreComponent).build()

WeatherDomainInjector.initialise(
 component.getWeatherRepository(),
 component.getSchedulerProvider()
 )
 }
}

I described the purpose of this object in previous articles so we can call method initialize () inside AppInjector in weatherapp module:

private fun initialiseWeather() {
 WeatherDataInjector.initialise()
}

Once we set dependency injection we can go back to WeatherRepositoryImpl and provide an implementation for WeatherRepository interface, note that we will inject WeatherRemoteDataSource and SchedulerProvider through the constructor, on the same way that we did it in domain layer:

package com.rostojic.weather.repository

import com.rostojic.core.rx.SchedulerProvider
import com.rostojic.weather.model.Weather
import io.reactivex.Single
import javax.inject.Inject

class WeatherRepositoryImpl @Inject constructor(
 private val remoteDataSource: WeatherRemoteDataSource,
 private val schedulerProvider: SchedulerProvider
) : WeatherRepository {
 override fun getWeather(): Single<Weather> {
 return remoteDataSource.getWeather()
 .subscribeOn(schedulerProvider.io)
 }
}

Finally, we can implement our fake data source. Create package remote inside main/java and class FakeRemoteDataSource in it. This class will implement WeatherRemoteDataSource, and inside the overridden method getWeather(), we will return RxJava Single Weather instance parsed from local JSON by using library called Moshi. Moshi instance, context, and weather.json path will be injected through the constructor. Note here that we provided Moshi instance and context from the core module but weather.json path from WetherDataModule:

package com.rostojic.weather.remote

import android.content.Context
import com.rostojic.weather.model.Weather
import com.rostojic.weather.repository.WeatherRemoteDataSource
import com.squareup.moshi.JsonAdapter
import com.squareup.moshi.Moshi
import io.reactivex.Single
import java.io.InputStream
import javax.inject.Inject
import javax.inject.Named

class FakeRemoteDataSource @Inject constructor(
 private val context: Context,
 private val moshi: Moshi,
 @Named("weather_json_path") private val jsonPath: String
) : WeatherRemoteDataSource {
 override fun getWeather(): Single<Weather> {
 return Single.create<Weather> {
 val jsonAdapter: JsonAdapter<Weather> =
 moshi.adapter<Weather>(Weather::class.java)
 val inputStream: InputStream = context.assets.open(jsonPath)
 val inputString = inputStream.bufferedReader().use { reader -> reader.readText() }
 val weather = jsonAdapter.fromJson(inputString)

if (weather != null) {
 it.onSuccess(weather)
 } else {
 it.onError(RuntimeException("Could not fetch weather"))
 }
 }
 }
}

Now when we have FakeRemoteDataSource implementation, we can go back to our WeatherDataModule and update it to provide data source:

@Provides
fun provideWeatherRemoteDataSource(
 context: Context,
 moshi: Moshi, @Named("weather_json_path") jsonPath: String
): WeatherRemoteDataSource {
 return FakeRemoteDataSource(context, moshi, jsonPath)
}

With this change, we are done with our data module. In this article, I described what the data layer is and how we can implement it to fit our needs. Designing a data layer like this can help us to avoid problems in the future when we want to change the source of our data and do not affect the whole application. In my upcoming articles, I will write on how we can replace this FakeRemoteDataSource with an actual API call to Apixu weather using Retrofit. In the next section, I will describe and implement the presentation layer.

Android App Architecture: Domain Layer [Part 2]

In the previous article, we talked about the basics of Clean Architecture, MVVM and app modularization. Then we’ve created a sample WeatherApp with an initial package structure (core, WeatherApp, data, domain, feature, navigation module), gradle files…

In this article, I’ll take you through the process of creating the first feature for data parsing from local JSON that’ll display the results to the user. We can simply call this feature weather.
Following Uncle Bob’s principle of clean architecture, we’ll start with the domain layer.

The first step is to create a new module called domain_weather inside the domain directory. Each feature should have its layer, the weather feature will have three modules for each layer (data_weather, domain_weather, feature_weather – it represents the presentation layer).

What is the Domain layer and how to implement it in an Android application?

The Domain layer is the central layer of our feature. All of our business logic needs to be placed in this layer and it needs to be pure Kotlin (if you work on a Java project, it should be pure Java) with no Android dependency. The Domain layer interacts with the Data and Feature (presentation) layer using interfaces and interactors. It is also completely independent and can be tested regardless of external components. Each domain layer has a unique use case, repository, and business model.
UseCase is nothing more than a logic executing class, every logic we have in our domain layer should have UseCase. We need to interact with the data layer in our domain_weather, so we’ll create a package usecase under that module and file called GetWeatherUseCase inside the package.
Before we start coding our use case, we need to create a domain package inside our core module. Inside this package, we’ll create an abstract class called UseCase. This abstract class will be a base class for all of our usecases and when extended, it’ll force that particular usecase to provide the implementation for a method called executeUseCase where specific logic will be implemented.

Those usecase classes aren’t just responsible for performing some operations (in the first article I mention that I’ll use RxJava2) but they also manage which threads will be used for performing and observing the subscription. We’ll learn more about this when it comes to the actual implementation of these usecase classes. When using RxJava in the application we’re dealing with different threads and observing in the main thread of the app (AndroidSchedulers.mainThread()). The main issue of this approach is that it requires reference to RxAndroid, so we’ll have the reference to the Android framework, and because the domain layer needs to be pure Kotlin, this situation will break the concept of separation of concerns.
Therefore, we need to create an interface to abstract our observing thread because we don’t want our domain layer to know about it. The best place to create this interface is the core module.
Inside the core module, create a package called rx, inside of it create an interface called SchedulerProvider.

As you can see here, we’re using Scheduler from RxJava framework, this is fine because we don’t want the domain layer to be aware of RxAndroid. The next step is to create a class DefaultSchedulerProvider which will implement SchedulerProvider interface. The class will use AndroidMainScheduler – that way we can achieve the necessary abstraction.

The next step is to create a domain representation of the data model, and this model will represent the business rule for the feature. In the feature, we’ll parse dummy data from the local JSON, so that the response is represented with an instance of this data model. We don’t want to know how the data layer (in our case data_weather) gets this data (it can perform some API call or retrieve data in some other way not only parsing local JSON) in this layer, but we do want to know how the data that we receive looks like so that we can construct our model. We’ll start by creating a package called model inside domain_weather and a data class called Weather inside that package.

Once we’ve created the Weather model, we need to set and define rules of what needs to be implemented to obtain this model. That’s why we need to create a repository interface that will contain this business rule. We’ll start by creating a package repository inside the feature domain layer, once we do that, we can create an interface called WeatherRepository. This interface will be implemented by an outside data layer (data_weather) and it will implement the logic for usecase of our domain layer (domain_weather). In this interface we will provide one method for getting weather data called getWeather(), this will return RxJava Single instance (because we are getting single value, when we change local JSON with actual API call this method will return Observable or Flowable if we want to support backpressure and we will return a list of Weather instances).

Before implementing GetWeatherUseCase we need to set up dependency injection for this module. Under main/java, where the packages model, repository, and usecase are located, create one more package called di. Start by creating a module class called WeatherDomainModule, this module will provide a weather repository and scheduler provider.

Create two more files after WeatherDomainModule, a component called WeatherDomainComponent and an object called WeatherDomainInjector. We’re following the same principle for di as we did in the previous modules.

Once we set dependency injection, we can implement our use case GetWeatherUseCase. First of all, we need to inject WeatherRepository and SchedulerProvider through the constructor of the GetWeatherUseCase and extend base UseCase class from the core module:

In this case, our compiler will complain about two things, the first it will require us to override the method executeUseCase and the second one is related to the missing type in UseCase<>. Let’s fix the second error first. To have clear information about the result of usecase execution, we will create a sealed class called Status inside GetWeatherUseCase. This sealed class will contain one data class and two objects. The Data class will be returned if the execution of usecase is successful and as a parameter, it will receive our domain model Weather. Objects in Status will be used for error handling, they will describe which error happened during the execution of our usecase.

Now we can pass this sealed class as a type to UseCase:

Once we do this, we can override the required method and we should get this:

Before we provide an implementation for method executeUseCase we need to create CompositeDisposable to keep all our disposables in the same place, we will create it in our base UseCase class, let’s make it protected:

After we create compositeDisposable we also need to create a method to dispose of all the previously contained disposables:

Now we can go back to GetWeatherUseCase to method executeUseCase and call getWeather() from weatherRepository that we received through the constructor of usecase:

As we can see from the code snippet above, we are performing a subscription on onStatus in a new thread and observing it on the main thread. The next step is to add error handling:

We will create below executeUseCase method onError which will take one parameter of Throwable type, based on what type of error is thrown we can perform our logic:

The final step is to add this disposable to our compositeDisposable.
Create a package called rx, under the core module, and add a class called RxExtensions.kt inside of it.

When we call disposeWith() in executeUseCase, the final implementation for this usecase method should look like this:

With this, we’ve finished our feature domain layer and reached the end of our second article about Android app architecture! In the next article, I’ll write about the feature data layer (data_weather), how to parse data from local JSON, and connect it with the domain layer using more code and examples.

Android App architecture: Modularization, Clean Architecture, MVVM [Part 1]

Based on my experience on previous projects, I decided to write an article on how to properly set up the base architecture of an android app which can be easily extended and applied to different kinds of applications.

The key concept that I’ll analyze in this series of articles involves the combination of Clean Architecture, app modularization, and MVVM design pattern in creating a modular, scalable, and testable android application. For that purpose, I created a demo application called WeatherApp that will demonstrate this approach. The whole app is written purely in Kotlin, with Android Jetpack components such as LiveData, Navigation, ViewModel… Regarding dependency injection, I’ll use Dagger2. For performing complex threading operations, maintaining synchronization, error handling, getting results back to the UI thread and so on, I will use RxJava2.

In this first article, I’ll try to give an overview of modularization, Clean Architecture, and MVVM. Furthermore, I’ll explain how app modularization is useful and how we can combine those three software design techniques to create a high-quality and scalable Android application. Also, I’ll describe the demo application WeatherApp, create an initial package structure for it and show how to deal with multiple Gradle files.

What is Modularization and why you should use it?

Modularization in Android apps represents a software design pattern that separates functionalities into modules. Each Android application can be modularized by dividing the application module into library modules. The library module will have its resources, manifest file, and classes. In the end, the build tool will merge it into a single APK.

There are a few reasons why you should consider applying modularization to your application if you haven’t already:

• Faster build time (once you add your first module you should edit your gradle.properties file with this line: org.gradle.parallel=true – it uses all cores on your machine to build modules in parallel. Right-click into any folder in the project in Android Studio->Load/Unload Modules will open a screen where you can unload modules that you are not using and avoid their compilation).
• Code ownership
• Faster Continuous Integration
• App bundles – Dynamic features

Each modularized app should have:

• Core or base module (it should contain pure infrastructure without any domain knowledge).
• Feature modules (they are owned by a single team and they represent single features, the smaller they are, the better. The most important thing about feature modules is that they can NOT depend on other feature modules).
• Library module (can be shared between features).
• App module (in this module there’s no feature or infrastructure specific code, and in this module, we need to create app Dagger component).

The main point is to modularize by feature. When your features become bigger you must split them into smaller ones, and the code, which is shared or coupled between features, you can resolve with plugin pattern. It is important to mention that features can’t depend on each other but in most cases, they need to communicate. The concept that I prefer for feature to feature communication is known as string-based navigation, it consists of navigation directory which doesn’t depend on anything and it receives only primitives like IDs and return nullable intents. I will further explain this through a concrete example in our WeatherApp.

What is Clean Architecture?

The concept of Clean Architecture was originally proposed by Robert C. Martin, known also as Uncle Bob. The main goal of this approach is the separation of concerns, to separate your code into independent layers and design it to depend on abstractions instead of concrete implementations.

By observing the famous “onion” image above, we can see on the horizontal line how dependency flow looks like. Based on the arrow’s direction we can see that Use Cases depend only on Entities and Entities do not depend on anything and so on…

“We should think about our applications as a group of use cases that describe the intent of the application and group of plugins that give those use cases access to the outside world” – Uncle Bob

The main reason why we should use Clean Architecture in our Android applications is that if we set it properly we will end up with an application that is independent of frameworks and libraries, independent of UI, and maybe most important – independent of data sources. There are three layers:

• Data layer (Network data source, Disk data source)
• Domain layer (Entities, Use Cases, Business logic)
• Presentation layer (Activities, Fragments, UI logic)

What is MVVM?

Model-view-viewmodel is a software design pattern consisting of three layers:

• Model (in our architecture in combination with Clean Architecture refers to a domain model, which represents a real state content).
• View (activities, fragments, it displays data received through view-model).
• View Model (the View Model represents an abstraction of the view, it receives data from Model, perform necessary UI logic and then expose appropriate data to the View, alongside with that, View Model manipulate the Model based on actions on the View. The View has a reference to a View Model but View Model doesn’t know anything about the View).

WeatherAPP – concrete example

To demonstrate how to design an application based on those above software architecture techniques I created a simple app called WeatherApp. The app will parse local JSON with dummy data in the Data layer and through Domain layer display results in the Presentation layer. The app will have two simple features (getting weather and displaying it on the main screen and Settings feature for changing the theme and whether unit). I created a feature Settings just to show how string-based navigation works between two features. Based on that information about the app we can create a new project from Android Studio and an initial package structure.

Once the project is created rename the app module to WeatherApp. This module will be responsible for linking all feature modules together. The next step is to create a core module. Right-click the project then New/Module and select Android Library, change library and module name to “core” or “base” if you want, select minimum SDK 21, Kotlin should be selected by default and then click finish. This core module will be responsible for providing dependency to all other modules. Every module (WeatherApp, features, libraries) should implement the core module. (I’ll show how it looks in the WeatherApp later). The next step is to create a navigation module for navigation between features. Again click New/Module, select Android Library, change the name to navigation and click finish. After adding the core and navigation module, create three directories: data, domain, and feature. Finally, the project structure should look like this:

The next major and important step is to set gradle files. The first file that needs to be modified is the main build.gradle. Inside buildscript create ext.versions = [] and ext.deps = [].
Inside ext.versions = [] add versions for each dependency and in ext.deps = [] add dependency with appropriate versions. If you set up your gradle properly you don’t need to worry about versions of individual libraries because they all come from a central point. Here is an example for Moshi library:

After you add all dependency the same way in the main build.gradle, the next step is to modify build.gradle in the core module. The core module will be responsible for providing dependency for each module in WeatherApp so it needs to look like this:

When core build.gradle file is finished, the next step is to modify build.gradle files of our modules (WeatherApp and navigation) that will implement dependencies from the core module.

WeatherApp module build.gradle:

Navigation module build.gradle:

It is important to highlight that the WeatherApp module will implement all other modules in our app, so at this moment we have only navigation and core. Once we add feature modules we will need to update this gradle file.

Before we add the first feature, we need to set up WeatherApp and the core module, in the core module under main/java package create dependency injection package called di. As I mentioned above, for dependency injection I will use Dagger2 because it’s much better than Koin for multi-module projects, in my opinion. Based on that, we need to create CoreModule and CoreComponent at the beginning:

CoreModule will for now provide context and application:

Besides the CoreModule and CoreComponent, we need to create one more file, more precisely, an object called CoreInjector. In this object we need to create a public function initialise() which will build DaggerCoreComponent from WeatherApp module:

Now in the WeatherApp module create di package under main/java/ and inside this package create another object called AppInjector. This object is responsible for initializing Dagger component at the app level for each module:

And finally, we need to initialize this in our application class inside the WeatherApp module, in our case WeatherApplication.

Before we create our first feature we need to set up a navigation module. In the navigation module, we need to create two files, one for loading a class based on id (in our case loading activity, also there is possible to load fragment or service) and one for providing nullable intent.

Class ProvideIntent will be used for navigating between features, calling forActivity() feature will get the intent of the required activity or it will get null.

In the next article, I’ll create the first feature for fetching dummy data, as Uncle Bob described, I will start from the most inner circle – domain layer. I will create a domain module for that particular feature inside the domain directory and set dependency injection for it, use-case, repository, and entity.