The CommonsBlog

"Elements of Kotlin" Version 0.1 Released

Subscribers now have access to Version 0.1 of Elements of Kotlin, in PDF, EPUB, and MOBI/Kindle formats. Just log into your Warescription page to download it, or set up an account and subscribe!

This is my initial book for what I have been calling “second-generation” Android app development:

  • First-generation techniques revolved around the Android Support Library and were mostly based in Java

  • Second-generation techniques center on the Jetpack and AndroidX libraries, with more code written in Kotlin

While there are other books on Kotlin out there, I wanted to ensure that subscribers had access to one. As the book evolves, you will see that I’m also taking some different approaches towards covering Kotlin.

Part of that is because while I appreciate Kotlin as a programmer, as an educator I find Kotlin to be very “busy”. It has lots of keywords, lots of syntax rules, and lots of specialized capabilities.

From what I can tell, most of that complexity is there to allow simple Kotlin to be as simple as it is, and to allow library developers to offer similarly simple APIs. This is wonderful for experts, and the results are wonderful for everyone. However, the vast majority of developers are not writing libraries — they are the consumers of sophisticated APIs, not the producers. As a result, a lot of Kotlin seems to fall into YAGNI (You Aren’t Going to Need It) for ordinary developers.

But, along the way, they may wind up seeing aspects of complex Kotlin and have to make sense of it.

For example, the kotlinx.html library offers a DSL for HTML generation. With that DSL, you can do stuff like this:

val docs = ""

val div = document.create.div("my-css-class") {
    p { 
        +"This is preceded by a unary plus operator. "
        a(docs) { +"(no, seriously)" } 

Is having a unary-plus operator (+foo) unreasonable? No. Is offering operator overloading unreasonable? No. Is allowing the unary-plus operator be overloaded for String unreasonable? No.

But the result (+"huh?") winds up being something that an ordinary developer is likely to to respond with “Kotlin, WTF?”. As an educator, I dread languages that make learners go “WTF?”.

(plenty of things in Android app development cause developers to say “WTF?” — I don’t need a language adding to the pile of sources of “WTF?”)

My objectives with Elements of Kotlin are:

  • Help developers be able to read any Kotlin that they might encounter

  • Help developers be able to write ordinary Kotlin

  • Help curious developers discover what some of that unusual syntax or keywords are called, in case they wish to dive more deeply into how to use it for their own work

Some of this will involve finding ways to help developers find out the terms behind some of this syntax. Searching Google for kotlin +, for example, does not help much.

Right now, in Version 0.1, the book covers a lot of the core Kotlin syntax and features. There are a few core items that I need to get into, such as coroutines and Java interoperability. But a lot of what remains is covering the “WTF?” — I am expecting 40+ short chapters on things like:

  • Why is a certain generic declared out? Is this a baseball thing?

  • What is reified? Does that imply that originally the code was only ified, and we did something a second time to make it be reified?

  • Is crossinline some form of 1990’s “eXtreme” type of inline? And what does inline skating have to do with Kotlin, anyway?

  • And so on

Over the next several months, I will build to a Version 1.0 that covers everything in Kotlin 1.3. After that, updates will proceed largely based on new Kotlin releases.

Subscribers will also notice a few other new things in the Warescription. I will be explaining what else is new, and the plan for the Warescription, over the course of this week.

Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!