This blog post (originally titled “Late for the Kotlin party”) has been in the file cabinet since spring and the “see the light of the optical cable” moment was postponed, because of, reasons. By now the original title has become outdated, but I kept most of the original structure and I think that the advices and notes in the post will work well for newcomers, so let it be.
You’re an Android developer and you’ve been slacking off learning Kotlin, staying in the comfort zone, maintaining Java code project(s), recently started Android and Java was overwhelming enough, or whatever the reason is - and now you’re figuring out that you’re kinda late? Well I guess so was I . This blog post is result of my Kotlin learning woes that I've structured in form of "Kotlin notes”/”point board”.
It is what it is, you have to do it if you want to stay relevant and even if your current position might not require that from you, things might change and you might end up in this position. Buckle up, I’ve made a crash transition course. There are a lot of layers to this, but it’ll get you started.
Let’s start with the resources, there are way too much resources and I’ll try to keep as tidy as possible:
- Kotlinlang docs - I know this is not the advice to give in the age of “googling everything”, but try to memorize as much as possible – like you’re studying for exam, a lot of things will be new and they might not have context but with trying out stuff and looking at examples the pieces will fall together. You won’t be able to memorize everything and you’ll need to come back from time to time, but I’ve found this approach very helpful and having those “aha, so that’s what they’ve meant with that/so that’s how I use this-and-this-thing” moments To be noted, also: official Android documentation – as it comes to examples that matter you. You’ll come here when troubles arise just to have reality check that you’re not that smart and that component you thought was intuitive and you knew how it worked does not quite resemble the reality.
-
Blogs – dev.to/medium posts from enthusiast from the industry are probably the best source where you can learn new stuff – they are usually targeted and are result of some difficulty that was overcame by someone patient enough to derivate the effort into tutorial/github project/”copy – paste code”.
Books – there are couple books, but the one that I think cuts it – is "Kotlin for Android Developers - Learn Kotlin the easy way while developing an Android App" by Antonio Leiva and if you have the means I recommend you get your hands to it. Dependent on your level will be the level of how useful you’ll find it (ideally you’ll create the app along reading, or just read it and try to replicate some of the code and concepts into your own idea/s), still be open there are always chances to learn new stuff.
r/androiddev/ - stay up-to-date everything including Kotlin – read it once or twice a week. Or daily, with the coffee mug. Great community that can also help with some issues and point out for you other learning resources.
When you go trough the resources and get a bit knowledge on the matter you'd like to see examples and how the pros are doing it. This article points out 10 Android apps that are written in Kotlin and are open source on Github, I suggest you check them out a little bit latter, when you start coding in Kotlin and get stuck or look for ideas to solve something.
First thing you hear when Kotlin witness knocks on your door is that NullPointerException doesn’t exist anymore and your life will get easier. Yeah, you also need to learn a bunch of new stuff and there are A LOT of new stuff. I know, I know, like every good programming story starts, this one also starts with a lie - that it’ll take you just few days. Amm, no. It’s different from Java and no matter what they say, it takes time (effort) to get familiar with the new terms, paradigms and then to know when to apply{} them (needless to say, pun intended). Yes, you can read Kotlin code even if you never written one line.
Everything starts with Any. Here are the basics:
This doesn't look so bad right? Let's go with more complex subjects, remember those Utils classes you’ve been copy-pasting from project to project? Well, you don’t need to now, you can replace them with extensions for the most part or change the structure a bit. To be noted, some more interesting concepts like lambdas (that have been around), inline functions are introduced that will yield the wanted result - making modular, reusable code snippets and blocks, happen with less work. These concepts come along with a lot of baggage and there's a steep learning curve since some of the examples might look too abstract and then real life app usage might seem too complex and hard to understand. I'll just throw them out there, yet it'll take time and effort to be able to know and understand when to use them. Probably the easiest and most intuitive part of the code when you come across these concept is when you build your util classes or when you handle events and callbacks. Start from there and build from that.
Let’s dwell into something you’ll come across and use frequently – high-order functions that implement idiomatic patters – apply, let, also and run/with. The concept is introduced in the standard Kotlin library and they are meant to help the developer achieve more with writing less – a very rough, Java-resembling explanation of the functions is that they are “enhancement” of this.
This table sums it all up and how time passes and you get experience, it’ll become more and more apparent:
Yes, making decisions is hard:
On this subject, here’s a great blog post that you should read.
Another thing that's specific to Kotlin are Delegated properties, based on the delegation pattern, which by definition is an object-oriented design pattern that allows object composition to achieve the same code reuse as inheritance. The explanation in Android terms can be simplified as value assignment to property under certain conditions.Delegates can be standard from Kotlin and custom, defined by the developer. In the following gist, more details:
Regardless of the language, you should use generics and more importantly you need to know when and why to use them. By trying to make your code look fancy you might end up over-engineering the whole damn thing, but that's a general rule and subject out of the scope of this blog post. Some simple examples how generics are done in Kotlin:
One new thing that has been out there for a while, but now with Kotlin is introduced in Android are Coroutines. The main purpose of Couroutines is to tak over the async/background-running parts of the app and make them smoother and nicer. That's in theory. There are few resources on this and even though rock star part of the community has already started using them, it might be too early for you to implement these in more serious project. Here are the basics
You should take into account other subjects that are complex regardless of the language, but do have some specifics, like implementing patterns and when to use them. Architectures that are popular and have pretty detailed explanation and examples can be found here:
- MVP (Vanilla MVP)
- MVVM
- some people like MVI, but I'd recommend you say no to MVI
Watch out when you implement Dagger. Things get funky and you need to use some of the things discussed in the gists above in order to make it work. The official coffee maker documentation is not very intuitive, so for more here and here (alternative: Koin, with caution).
Very popular Kotlin library that makes Android development easier - Anko. Suggestion - don't use it until you get grasp of things.
Last, but not least - testing - a bit different, but that is such a broad subject that will probably be touched upon in some other blog post in the near future.
tl;dr -> How is Kotlin different from Java:
- New syntax, obviously - funky (and useful stuff)
- No NullpointerException (by default)
- String Literals
- Companion objects
- Delegates (lateinit, by lazy)
- Lambdas (are everywhere)
- let, apply, also, it, when, run - rough explanation: enhancements of "this."
- Overriding properties
- Data classes (no more getters and setters)
- Sealed Classes
- Inline classes
- Extensions (say goodbye to ___Utils.class)
- Inline functions
- Function types
- Functions with variable number of arguments (Varargs)
- Operator overloading
- Coroutines
To wrap it up on a Zen note, to self and whoever got to here by reading: you can’t use everything at once and you can’t know everything. Some things that are hot and all the cool kids are using them, are going to get extinct before you know it. Others are here to stay. In a sense everything in the industry is hype, things are fast changing (and evolving) and you should adopt to the changes fast. Only a fool can think that Kotlin is gonna disappear anytime soon, so all feelings aside, this is (and will be) the way to go when it comes to Android development.
P.S. This tutorial (in form of workshop) from Yelp's GitHub is just awesome!
Top comments (0)