Joao Alves

Hey everyone, and welcome to article number 10 on the Kotlin Playground Series. Last time we looked into a few Kotlin standard functions that are very common (let, apply, run, with and also). Today we’ll be looking into another couple of standard functions that are not as popular, maybe because we don’t do these things as often but we definitely should.

The title mentions runtime checks, so what do I mean by that? Let’s see, have you ever written some code like this in Java?

Hello everyone and welcome to article number 9 in the series. Today we’re going to look at something that maybe should have come up after the syntax articles or so, but better late than never.

I guess I was using some of these without really knowing or paying attention to the real difference between them but last week someone asked me the difference and I was like hmm… so here we are.

Hi everyone, welcome to article number 7 in the series, today we’re going to look at something different. We all know how powerful Kotlin is as a language and keep reading that you can build a full stack solution with it so why not give it a try and build a simple backend to test those claims.

Recently at work, I needed to test my network layer before the backend APIs were actually implemented. The quickest way I found to do this was to actually create a GitHub gist with the desired Json response and then use that gist raw URL in my Retrofit service rather than the real API URL. This works fine but it’s not ideal as you can imagine.

Hello everyone, welcome to article number 7 of the series. Before we jump into other examples, I think it would be nice to check the quality of the code I wrote so far to support the previous articles. So today we’ll be looking into ways of performing some static analysis on Kotlin code.

For Java code, Checkstyle and Lint are probably the most used tools but what about in Kotlin, how can we check if our code is respecting guidelines and conventions? And how we can scan the project for potential bugs? Lint you can also use for Kotlin but be aware that there’s an open issue at the moment regarding false positives with unused resources (here).

Hi there everyone, welcome to article number 6 on the series. Today we’ll be looking at Kotlin Sealed classes and how they can take enums to a completely different level and add them some swag. Let’s start with a basic enum in Java and see how it looks in Kotlin:

public enum BasicScreenStateJava {
    ERROR,
    LOADING,
    DATA
}

enum class BasicScreenState {
    ERROR,
    LOADING,
    DATA
}

Pretty simple and pretty similar right? Enums are already pretty concise in Java so Kotlin doesn’t save us any boilerplate with these. Regarding functionality, they’re also very simple as there’s not much we can do with them.