Kotlin Migration @ Pepperfry: Part Three — Learnings
This is the third and final part of our series on Kotlin migration undertaken for the Android app at Pepperfry. This migration included the move from Java to Kotlin along with the move from MVP to MVVM architecture.
In the first part, we discussed the motivation behind our migration:
In the second part, we discussed our process:
In this part we will be discussing our learnings from the Kotlin + MVVM migration: code conciseness myths, importance of test cases, stable releases and Android studio tools, among others.
Kotlin code != Less code
This is one of the most controversial statements we had to make. Kotlin enthusiasts and evangelists want us to believe that Kotlin code is very concise compared to Java. We did not see that materialize during the migration of our app. We did see a major drop in our lines of code, although majority of it was because we moved from MVP to MVVM. The observable pattern helped us reduce a lot of boilerplate associated around callbacks. Kotlin did help us bring conciseness and cleanliness in the code structure, but MVVM had a big role to play in it. Our reduction on purely Kotlin migration would be similar to OkHttp’s 7%.
Unit tests == Better code == Happier users
As mentioned before, being able to write tests was an important goal of this migration. We started writing tests on all the business logic inside our ViewModel classes. There were multiple occasions when we found bugs in our functions through the tests early in the lifecycle and fixed the functions to handle edge cases. This lead to a better experience for our users and a higher stability rate for our builds. Also the team was more comfortable accepting changes to existing functions as the test suite would pick up logic breaks easily.
Null safety == Stable releases
Null safety provided by Kotlin made it very difficult for us to find NullPointerExceptions in our production releases. There were a few Parameter specified as non-null is null exceptions on Kotlin functions at the start of our migration but we worked on those and see very few / almost none of these now. Gone are the days of seeing null pointers on production releases and pushing a quick fix with null checks. Also we handled errors correctly on our Rx chains and saw no OnErrorNotImplementedException crashes.
The Kotlin learning curve
We were learning as we were migrating. Kotlin does not magically help you write clean code. Features written in Kotlin took us more time to write than Java. Mistakes were made. Lessons were learnt. Longer hours were put in to learn and become better at Kotlin.
First time != Perfect
As with any new framework, it takes time to make everything perfect. The same was experienced by us. Along the way, we perfected our extensions, code structure and architecture implementation. Kotlin being a comparatively young language, errors were not always easy to understand and fix. With perseverance and weekly knowledge sharing sessions, we kept improving in both Kotlin and MVVM.
Android Studio is amazing
One of our greatest asset/tool during this migration has been the Android studio. At first, we were writing code in the Java way, using Kotlin syntax. Android studio nudged us in the correct direction helping us write Kotlin code the Kotlin way. The tips and warnings by Android studio helped us get better at Kotlin. The internal Java to Kotlin converter was also useful to convert our model objects faster.
Impact on compile time & app size
There was some buzz around Kotlin adding to app compile time and app size. This was not seen by us in practice. With an effective gradle setup and proper proguard rules, we did not see any changes in compile time & app size.
Summary
We are currently working on this migration and learning new nuances almost everyday. Overall our experience has been very positive and we have decided to go ahead with Kotlin for all our future Android development. The reasons for this can be summarized as ease of development & a stable experience for our users.
Future plans with Kotlin @ Pepperfry
We are experimenting the server side capabilities of Kotlin using Ktor. Kotlin Multiplatform (KMP) is something we have a close eye on and waiting to see how it evolves.
