If you work with Kotlin on a daily basis you probably love the language and don’t want to go back to Java. Though, many of us work on a codebase that isn’t purely Kotlin. Our Android codebase at SoundCloud still has a fair amount of code written in Java. This percentage gets smaller over time but there is no urgent need for mass migration of the remains right now.

Therefore, every once in a while, I find myself, changing Java files. In those cases, I miss some of the Kotlin functions I’m used to; I can easily think of string…

Photo by Belinda Fewings on Unsplash

Most Kotlin developers would agree that a val property is equivalent to a final property in Java. What if I tell you that this is not completely true and sometimes you might need a final val?

Opposite to Java, Kotlin properties are final by default unless they are explicitly marked as open! This would mean there is no need for the final keyword, right? Let’s Google that:

If you have ever worked with LiveData you probably have written code similar to this:

class MyViewModel: ViewModel() {   val loading: LiveData<Boolean>
get() = _loading
private val _loading = MutableLiveData<Boolean>()}

This seems nowadays the typical way developers would expose some immutable LiveData, while being able to have a mutable version inside the implementation we would write data into.

Every time I saw, or even had to write, this kind of code something cringed inside me. As I quoted in one of my talks this feeling in our brain is for real:

social missteps activate regions in the brain, [..]…

And why you should avoid using the “NewApi” suppression!

The idea of “Compat” libraries was probably one of the key aspects of Android dominating the mobile space. Other than with iOS, Android users often could not update their operating system after a new version launch, simply as their phones won’t allow them to, the Android problem of fragmentation. But developers still wanted to use the latest features to compete. The solution was simple: instead of adding new APIs to the operating system, you shipped those directly with your app by using a “backport” version Google gave you.

It all started…

Playing well together

The idea of LiveData was an interesting one. Based on the idea of reactive streams, that was on the peak at that time with RxJava plus adding automatic lifecycle handling — a problem on Android. LiveData had bad timing though. It arrived just before Kotlin made its impact in the Android community and sometimes both don't play that nice together. Let’s explore why and what can happen!

The good and the bad

The idea of LiveData was pretty simple: a lifecycle-aware implementation of the Observable pattern. In addition, if you resubscribe, you will get the last emitted value again. …

Even if you live on the Kotlin side of things maybe once in a while you also check Swift code. If you do, you probably noticed how similar both languages are. To me, Kotlin looks more concise but I’m also biased as I work with Kotlin daily. On the other hand, Swift has some great features too. One is the guard keyword, a really nice tool Swift developers have that we are missing. Can we bring it to Kotlin?

What is guard?

guard is used to exit a block of code early, if a given condition is not met. …

I guess many of us love Elvis, both the artist and the operator in Kotlin. But it can lead to some hidden pitfalls if you are not aware of how it works.

I only realized recently when Vladimir Zdravkovic put some code on twitter and ask us to guess what it’s printing:

Avoiding implicit connections and learn how extension functions can help you writing good APIs

Writing your classes with a good API is hard but important. As the writer is trying to make it easy for the user, we sometimes tend to repeat ourselves by adding convenient methods.

Think about the List interface in Java. To check if there are no elements in the list we could check list.getLength() == 0 or we simply ask for isEmpty().

The 2nd one reads much better. But it also adds a duplication and implicit connection between the two: If the list is empty, it can’t contain any elements! This must be respected by every implementer of the interface!

How tools made us forget how to write sane constructors

In an ideal world, developers get smarter every day. The code we write this year should be better than the code we wrote 10 years ago, which in turn should be better than the code 20 years ago. Today we have better tools, more modern languages, and better practices.

But as often in life, we realize we are not living in that ideal world. In nearly every codebase I see today, there are things that would shock a developer two decades ago. …

A pragmatic guide to dependency injection on Android

© Kai Oberhäuser on Unsplash

Over the years many of us used different frameworks for dependency injection (DI). I remember writing an article about Transfuse a couple of years ago for a German magazine. Before that when I was working for eBay Kleinanzeigen we had a complete self-written DI approach. There was no magic and therefore it taught me a lot about the internals of those frameworks. Later at Groupon, I introduced Dagger1 in the Merchant app, which at some point was migrated to Toothpick aligning with the consumer app, who moved there from RoboGuice. At…

Danny Preussler

Android @ Soundcloud, Google Developer Expert, Goth, Geek, writing about the daily crazy things in developer life with #Android and #Kotlin

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store