This article outlines how our team for Android Application Development migrated all of our Android projects from Java to Kotlin, and how we introduced other fun things like MVVM, Android Architecture Components, Dagger 2 and more goodies into our Android projects at Tintash. We will also discuss the "why", was it really required, why and how we did it and the problems we faced in doing so.


Android Architecture was required to create harmony in the app development team


Why was it required?

First, some background on how we used to develop Android apps a few years ago before the Android Architecture Components entered the scene: everybody in our Android team used to have their own style of creating applications, there was no unified approach or a standard on how to develop Android applications. As an example, some of us were using an MVC like approach, and some were using a combination of different design patterns to tone down big fat activity classes, whereas the most enlightened ones were writing most of the business logic in Activities and Fragments themselves.

Deep down, in our hearts, we knew that this wasn’t right, that there was a better way of developing Android apps. Right about this time, automation and test driven development were gaining popularity. But we knew that the apps we were currently writing were providing low automation coverage. In fact, when we tried to provide automated test coverage for one of the applications, we had to change the architecture to MVVM because the business logic of our app was highly coupled with the UI logic. This change of architecture required us to refactor a sizeable portion of the codebase. Besides, we had to mock a lot of the UI components and use method stubs to actually be able to test out the core business logic. The time and amount of effort that went into some of that work was equivalent to writing some of these components from scratch, and in some instances it took even longer than that.

Google architecture is an excellent tool for designing games


Why did we do it?

Meanwhile, as we were struggling with these issues, Google introduced Architecture components and Kotlin for Android in 2017. So we set about reading about them, experimenting with them, and generally testing the new technology out, even though initially we couldn't integrate them in any of our production applications because of stability concerns. As a team, we are always looking for new stuff to play around with and to make sure that we remain up to date with the latest tools and technologies; therefore, we played with a couple of sample projects available online to get some hands-on experience for them, and to scope out how we may benefit from using them. Turned out they were the answer to our problems, as we could now potentially write Android apps that could provide high test-ability coverage, and provided a unified architecture for the entire team to follow while allowing everybody to practice their own individual styles of programming.

Another major announcement that Google made in 2017 was introducing Kotlin as an official development language for Android. The language inherently solves the much dreaded and all-famous null pointer exception which plagues most Android apps written in Java. Another advantage it has over Java is that it requires less code to be written for the same set of tasks. As an example of this, the famous app AppLock reduced 30% of their total lines of code when they converted their Java code to Kotlin. These two were the major reasons for us wanting to adopt Kotlin as the primary language for Android development, apart from our enthusiasm for keeping our tech stack updated and learning new technology.

How did we do it?

We started toying with the idea of using Architecture components and Kotlin in our production apps. The major concerns were around meeting commercial deadlines since they are usually the primary concern for any services-providing company for client satisfaction. So in order to avoid disrupting the running processes, we approached it with the divide and conquer rule. A cool aspect of this learning process was the knowledge transfer sessions, KT sessions for short. One of the senior Android engineers on Project Y team learned Kotlin and started implementing the incoming new features using the new language, while on a different project another engineer started working with the architecture components. Meanwhile, the rest of the team divided various components from JetPack, and libraries like Dagger2, RxJava, etc. amongst themselves and learned them on behalf of the team. Once they were ready, the engineers took turns to hold several KT sessions to train the rest of the Android team in their respective assigned task.

Final word

As a result of this entire effort, we were not only able to learn and have our team up to date on the latest technologies and trends but also shift all of our existing Android projects to Kotlin, the Architecture Components, and upgrade them to providing better test-ability coverage. And any new project we start now is implemented using the latest technologies on Android from the very beginning.


Topics: javascript, android development, android architecture components, kotlin, dagger 2, UI Components, MVVM, Rx Java, JetPack

Maaz Azhar

Written by Maaz Azhar

Lead Android Developer at Tintash