loading...
Cover image for Matt's Tidbits #60 - Cleanly handling null values in Kotlin

Matt's Tidbits #60 - Cleanly handling null values in Kotlin

mpeng3 profile image Matthew Groves Originally published at Medium ・2 min read

Last time I wrote about some strange, unexpected lint errors I encountered when upgrading to Android Gradle Plugin 3.6.1. This week, I have a quick tidbit to share about cleanly handling null values in Kotlin.

Cleanliness is at the top of mind for a lot of people right now, but this concept applies to your code too! Dealing with lots of dirty/complicated/bad code is a big contributor to technical debt.

I'm sure you've probably seen (or written) code like this before:

fun getResource(): Resource {
  val resource = Repository.getResource()
  return resource?.run {
    if(resource.isValid()) {
      resource
    }
    else {
      getPlaceholderResource()
    }
  } ?: getPlaceholderResource()
}

Isn't it annoying that in this code you have to write getPlaceholderResource() twice? Good news - there's a better way!

Kotlin has a really powerful feature, called Extension Functions, which let you add additional functionality to existing classes. Under the hood, they work a lot like a traditional Java static method. The best part is, that allows us to call them, even if we don't have an instance of the object they're being called on!

Take, for example, this sample extension function:

fun Resource?.safeIsValid(): Boolean {
  return this != null && this.isValid()
}

The magic of this is at the very beginning - the Resource? part - this specifies that we are defining this extension function for possible null values of Resource. Kotlin calls this an "Extension function with nullable receiver". With this in place, we can simplify our code to look like this:

fun getResource(): Resource {
  val resource = Repository.getResource()
  return if(resource.safeIsValid()) {
    resource
  }
  else {
    getPlaceholderResource()
  }
}

Notice how when we use this extension function, we don't have to use the safe call operator ?. to call our new method, but can instead just use the regular . notation.

I think this is much more maintainable and easy to use, what about you? Original credit for this idea comes from this article: https://medium.com/the-kotlin-chronicle/null-safety-through-kotlin-extension-functions-9a4c6ff10765

I hope you learned something helpful, and stay safe out there! How is your project using extension functions with nullable receivers? Do you have any cases where you don't use this? Let me know in the comments below! And, please follow me on Medium if you're interested in being notified of future tidbits.

Interested in joining the awesome team here at Intrepid? We're hiring!

This tidbit was originally delivered on September 13, 2018.

Posted on by:

mpeng3 profile

Matthew Groves

@mpeng3

Software engineer with 10+ years of professional experience in C++, C#, Java, and Kotlin.

Discussion

markdown guide
 

Really cool! Kotlin extension functions rule!