karntrehan
Jun 24 · 4 min read
Photo by Startup Stock Photos from Pexels

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.


Interested in working with us in one of the fastest growing startups in India? We are hiring!

Pepperfry Tech

Where the engineering team at Pepperfry shares stories about our technology, experiments, learnings and adventures.

karntrehan

Written by

Android @ Pepperfry | Co-organizer & Resident Comic @ GDG-MAD | https://karntrehan.com

Pepperfry Tech

Where the engineering team at Pepperfry shares stories about our technology, experiments, learnings and adventures.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade