Kotlin katas

Learn how to refactor an app with Kotlin

Jorge Sánchez (xurxodev)
ProAndroidDev
Published in
5 min readJul 7, 2017

--

After learning something new, we usually practice what we learnt by creating something from scratch, either a simple app or by practicing algorithms using testing-based methodologies such as TDD.

However, when we want to translate this new knowledge into our work, it is common for us to find a significant barrier: we do not have to create something from scratch, but we are working on an existing project.

When this happens we are not very sure how to apply our new knowledge.

Why learn refactoring?

For me, the main problem is that the new concepts are only assimilated creating something from scratch.

I think it is important to combine other practices where you refactor something that already exists, because the inputs that are acquired when learning by refactoring are different and complement to those acquired when learning to create something from scratch.

For a long time, I have been facilitating the classic TDD katas in the companies where I teach, and we combine them with katas where we do not create something from scratch: what we do is refactor an existing application.

I have created a Kotlin version of these katas where the goal is to practice Kotlin while we are refactoring a simple application towards good Android development practices.

As Kotlin is fully interoperable with Java, refactoring existing applications by using Kotlin will be more frequent than creating them from scratch.

These practices come a little closer to what we usually do every day at work.

The application to refactor

The application is simply a list of movies and their corresponding detail screen.

Kotlin Kata Movies

It is an application strongly coupled to the Android Framework without a testable architecture; it has no well-identified domain logic and presentation logic, there is no tests and it is written with Kotlin.

The GitHub Repository

The repository where I have the katas is this:

In the master branch all the katas are resolved by me and each kata has its own branch.

The kata are evolutionary, therefore each kata has as initial state my solution in the previous kata.

If you are doing all the katas one by one, the best thing to do is starting from your own previous solution.

In companies, I usually propose to develop the katas in pairs so as to do pair programming.

Kata 1 - Dependency Injection

Kotlin with Dagger 2

The branch for this kata is kata di movies.

The goal is to start refactoring towards a more testable application.

When a more testable architecture is built in an application, new dependencies will emerge and it may be more complicated to build the dependency injection infrastructure.

I think it is better to build this infrastructure when there are not many dependencies, because it will be easier to assimilate.

Dagger 2 is used as a dependency injector because this app is an Android application.

You learn to identify dependencies, you practice how to configure Dagger, and you create one module and a component at least.

In the case of dagger 2 there is some variation in the configuration regarding java, so this kata is good to start with.

Kata 2 - Model View Presenter

Kotlin with Model View Presenter

The branch for this kata is kata mvp movies.

The goal is to separate the presentation logic by using the MVP pattern.

In this kata you learn to identify what logic of presentation is and you begin to use the principle of dependency inversion so that the presenter does not depend directly on the view, but on an abstraction.

The second part of the kata consists of extracting the navigation between the screens in a navigator object, thus releasing the activity from that of that responsibility.

Once this kata is finished, the activity has only one responsibility: to represent the information.

Kata 3 - Clean Architecture

Kotlin with Clean Architecture

The branch for this kata is kata domain data movies.

The goal is practicing Clean Architecture using Kotlin.

The use case identification is practiced and the dependence inversion principle is still used since the domain layer can not depend on any external layer.

As we are working with Kotlin, it is a good time to change the chip from using interfaces as callbaks, as usual in Java, to using Kotlin lambdas.

Kata 4 - Testing with Espresso

Testing with Kotlin using Espresso

The branch for this kata is kata espresso movies.

The goal is to practice testing with Espresso and Kotlin.

In addition, it was planned to perform the kata in two ways: first without using the Robot Pattern, and later refactoring the tests to use the Robot Pattern.

In this way we also practice how to clean the acceptance tests of frameworks.

This kata can optionally be started in the first place.

Conclusions

With this series of katas you will practice kotlin while you are refactoring an existing app, using some good development practices on Android.

This will help you to better incorporate this new knowledge every day at work, where not only we create something from scratch but we work with legacy code most of the times.

To learn the basics of kotlin I recommend the book of my friend Antonio Leiva:

Kotlin for Android Developers: Learn Kotlin the easy way while developing an Android App

--

--