Index:

1. London Tube Status App — setting up
2. London Tube Status App — gradle cleanup and dagger
3. London Tube Status App — Retrofit and API setup
4. London Tube Status App — wrapping up the data layer
5. London Tube Status App — domain layer
6. London Tube Status App — layouts and view model
7. London Tube Status App — MVP implementation
8. London Tube Status App — UI tests and going live
9. London Tube Status App — from dagger to koin
10. London Tube Status App — from MVP to MVVM
11. London Tube Status App — from Rx to Coroutines

Hey everyone, welcome to my new Series on Medium. After writing 12 articles for my Kotlin Playground Series, I decided it was time for a new project. In this series, we’ll build an app to give us the London Underground lines statuses from scratch.

I’ll also have a new repository just to follow this project, you can find it here or there’ll be a fancy link on the bottom of each article. As with the other series, I’ll tag the repo with each article as it’s easier to follow. Tags will be following the article_# format.

Plan

The plan is to follow clean architecture, but I won’t get in too much detail as there are plenty of nice articles out there already. I’ll use MVP for the presentation layer and Rx throughout all the layers. The goal is for the project to be written 💯 in Kotlin code wise, gradle scripts we might move to Kotlin later on, for now we’ll just manage dependencies with it as you’ll see below.

I’ll also try to write unit tests along the way, haven’t decided yet if I’ll just use JUnit or maybe Spek (you can vote in the comments if you want). For UI tests which I confess never implemented myself (shame on me 😬), I will use espresso.

Feel free to also suggest other stuff for me to do/use in the project, I’ll promise to give it a try even if it’s something completely new.

Action

But let’s jump straight into action, today’s article is about setting up the initial project. We’ll create the separate clean architecture gradle modules and add some dependencies we’ll need along the way.

So, first things first, create a new Android Studio project and don’t forget to include Kotlin support.

Clean architecture gradle modules

Now to the gradle modules. Which ones do we need to conform to clean architecture?

app: this one we have already is the default one. All view related things will live here, like activities, fragments and custom views. It has a dependency on the data and domain modules.

domain: a Java/Kotlin module, don’t make it an Android module, this module should not have any dependencies on the Android framework or on any of the other project modules. All business logic goes here, like interactors and entities.

data: an Android module that contains any network and database (if any) related things go here, for example, our retrofit service and our repositories. It has a dependency on the domain module.

So, let’s go ahead and create those, we can handle dependencies after. This is how our project view looks like now:

Dependencies

Now, we need to manage the dependencies between those modules and also add a few more dependencies we’ll need later so let’s make it in a nice way using Kotlin DSL. This will give us autocomplete and navigation capabilities when managing dependencies which is great. You can refer to this nice article from my friend Mario to learn more about it, I’ll quickly go through the steps:

1 — Create a buildSrc folder in the root of your project. We need this folder to hold all the code needed when we build our project scripts.

2 — Create a build.gradle.kts file in the root of that folder with the content as below. This enables support for Kotlin DSL.

3 — Inside the buildSrc folder, create a src > main > java folder structure

4 — Inside the java folder create one Kotlin file named Dependencies.kt for example.

5 — Inside that file, create Kotlin objects to hold your dependencies and versions like this:

You can organise those in as many objects and different ways you think, that’s up to you, I find this is a nice setup. So, now we have a nice system to manage our dependencies and as you can see I added a few external dependencies we’ll need for sure like retrofit/gson and Rx for example. There are more there if you check the repo but we’ll probably revisit this as we go along the project anyway.

And this is how we use the dependencies now in our project level build.gradle script:

And if we want to use it in one of our modules, app for example, this is a partial snippet how we do it. You can check on the project for the full content of each module gradle script.

Some references

You can see that I added ktlint as well, you can check my article on it and detekt from my Kotlin Playground Series.

Another thing you might have also noticed is that I renamed my gradle scripts to contain the module where they belong in the name. You can refer to this great article from Philippe Breault that explains the process. Simple to do and quite useful in multi module projects.

And that’s it for article number 1 in this new series. Hope you enjoyed it and if you did, please don’t forget to give some 👏 and feedback is more than welcome. See you at number 2 for some more cleanup around these gradle scripts, some dagger and more 👋.

NEXT ➡ London Tube Status App — gradle cleanup and dagger