Android Migration – Kotlin and Jetpack

A few years ago, I’ve published a small application on Android’s Play Store: SCOSSO .
SCOSSO is a simple, user-friendly but yet a powerful tool for rapid visual surveying of structures with any material and characteristics.

SCOSSO is my first Android application, it was developed between 2016 & 2017 using Java and the Support Library.

Over the past few months, with some time in my hands, I’ve decided to update the app to Android new stack (The app will be out soon ). This was a great opportunity to test the migration path from Java and all the new cool features promised in Jetpack. For all those that don’t know it, Jetpack is a suite of libraries, tools, and guidance to help developers write high-quality apps more easily. These components help you follow best practices, free you from writing boilerplate code, and simplify complex tasks, so you can focus on the code you care about. And…yes…it’s absolutely awesome.

In the next blogposts, I’ll share my impressions of this journey.


A wealth of posts have already been written on why Kotlin is among the best programming languages out there…I probably don’ have to add mine but…I can totally confirm it ! I’m absolutely in love with it. I won’t bother you with the details as they’re easily googleable…but the language feels fresh and very modern, it solves a ton of Java historical “problems”: null checks, var and val , small classes, string templates…etc… a lot of improvements targeted at Java’s verbosity. In fact, Android Studio bundles an automatic Java <-> Kotlin code converter. In my experience, just running it reduces the number of lines of a class of roughly 40 % . Amazing.
I love how expressive I can be with this language. It really feels: “Java on steroids“. What a lot of developers have been waiting for years, especially out of the EE world.

Jetbrains and the community have done a great work with this language,and I wish I had done the switch years ago.

Side note, I’ve recently started working for a project with Java 11 after spending a couple of years effectively far from the language and was able to appreciate how many of the improvements of Kotlin have now entered Java as well. Version 14 promises to go even further on the road of reducing verbosity, improving expressivity and perhaps taking the language ahead on the functional road.


MVVM – DataBinding – Lifecycle

I was lucky enough to see the benefits of the MVVM (Model–view–viewmodel) architecture in Android quite a few years back, even before it got mainstream (thanks to a savvy C# developer converted Android that introduced me to it! Thanks @Tom) and SCOSSO has always been making quite a heavy use of it. Traditionally Android application have had significant amounts of code used to manage the lifecycle of Fragments and Activites. The big problem was that lifecycle of core components of the UI was managed outside of the component themselves and into dedicated methods attached Ao activites and Fragments(OnResume(), OnStart()…). As everyone that has actually tried to implement a Map Activity in Android knows, this could easily become such a hurdle to the point that knowledge of this lifecycle has become one of the _standard_ interview questions for Android Developers !
Using MVVM and moving part of the data logic to a dedicated ViewModel class has allowed to keep SCOSSO logic clean. However, AndroidX and Jetpack, take everything to a whole new level. With Lifecyle-aware components and DataBindings, I can do a lot of powerful things directly in the components (and the XML) that allow me to remove enormous amounts of code that was purely managing lifecycles.
And frankly, 2-way data binding with MutableLiveData are the future of variables in Android, creating a bit of a clever Snackbar can be simplified into:


    var userError = MutableLiveData<String>()
    Log.i(TAG, "NumberFormatException : Error trying to convert $newText to Integer")


    locationInfoViewModel.userError.observe(this) {
      showError(requireView(), requireContext(), it)


Jetpack documentation says that “WorkManager is a library for managing deferrable and guaranteed background work” but if you’re looking under the hood, it’s effectively a layer on-top of RXJava and/or Kotlin’s native co-routines. The big change is that traditionally these features in Android, do not guarantee execution of the work and require wrapping logic around them to integrate them with the application lifecycle (Evernote had good library to solve these problems). WorkManager differs in nature from them because of the execution guarantees that it offers against deferrable work (well explained here) and how “native” it feels…but please, let’s just not talk about how it compares with the plethora of options available in native Java.
It’s effectively useful when doing expensive data activities such as synchronizing client-server, sending logs or doing heavy database operations. In SCOSSO I use it to pre-seed the SQLite database that I use as well as for some tests with Espresso. The API went through multiple iterations with some important deprecations and is still far from perfect however, was such an improvement for me to its implementation became a no-brainer.

One thought on “Android Migration – Kotlin and Jetpack

  1. Good Article Federico, Kotlin is superb and Google should actually promote this more.

Comments are closed.