Use the "Kotlin Android Extensions"

Peter Sommerhoff
A free video tutorial from Peter Sommerhoff
Developer & Software Engineer - With 45,000+ Happy Students
4.5 instructor rating • 6 courses • 62,651 students

Learn more from the full course

Kotlin for Android & Java Developers: Clean Code on Android

Become a professional Kotlin developer and write cleaner code in your Android apps than in Java, avoid boilerplate code

09:14:18 of on-demand video • Updated November 2020

  • Write clean code with Kotlin
  • Avoid ceremony and boilerplate code around Android APIs
  • Use functional programming to write concise, expressive code
  • Create Android apps with Kotlin
  • Write readable SQLite transactions using extension functions in Kotlin
  • Use the Kotlin Android Extensions to avoid findViewById()
  • Create multiple activities, layouts and menus
English Instructor: In this lecture, we'll finally see one of the powerful ways that Kotlin can improve your code when compared to Java. Now, normally we don't actually want to have a fixed text for our code layout here, so let's say we just remove this description, and we want to actually set that description programmatically in our Main Activity. So first of all, we're gonna have to get a reference to that text view, just to then set the text, and as I mentioned, I'm oftentimes just gonna go for the Java way to do things, and then I'm gonna improve on that by using the Kotlin way, or using some of Kotlin's features, in order to improve the code. Now, unfortunately, many other courses on this topic actually stop at the point where they just use Kotlin completely like Java, and they don't actually make any use of the benefits of Kotlin when compared to the Java language, so we're gonna do this better in this course, so you're gonna see how you can actually write cleaner code with Kotlin. Now the Java way to do this would be to create first a private member variable in our activity, and we can call this, for instance, text view description, and actually we can't even make this a val; we're gonna have to make this a var, because we'll have to initialize this with some value now, and then later on, we're gonna have to assign the actual text view. So this should be of type TextView, but we have to initialize this with some value now, so we can only go for null at this point, so we have a nullable type, and we also have a mutable variable instead of a val. And this is exactly what you'll see normally in Java code, and it's pretty much also the only way you can do this, and then inside here you can go ahead and say tvDescription equals findViewById. You can get the ID from this R file using, and then recall this tv_description. So this findViewById here is gonna be used in Java code all the time to get all the elements from the layout that you need, and then to put this into this variable here. And in Java code, you'll actually also have to cast the result of findViewById normally; here, this is gonna refer to findViewById of the text view, because that's the type of our demo variable, tv_description, so in Kotlin we don't need to explicitly define this. And now we can go ahead and say tvDescription.text and set this to, well, I should probably have copied the value of this string here, so I'm gonna do this now, switch back to Main Activity. So here you can see that with Kotlin, we also run into trouble again because this is a nullable field, so whenever one actually accesses this, we're gonna have to use the safe call operator, so only if this is not null, then we're gonna set the text. Now in other courses, you often see the double exclamation mark used very often. That's already a warning signal, or should be a warning signal for you that they just don't really understand how to work will nullables in Kotlin, and also just don't know how to avoid nulls in the first place. So here, you can simply use the safe call operator, because while this of course shouldn't be null at this point, we have just set it to the view, but it's just not necessary to go for the double exclamation mark because if this is null, then, well, you just don't want to set the text. You just want to set the text here if it's not null. So remember that if this property here, if it's actually null, then this line will just not be executed. And that's of course the safe way to do this. Alright, so that's completely the Java way to do this. So now let's go ahead and improve this one step by using Kotlin's lateinit modifier. So this means that this variable here doesn't need to be initialized at this point in time already. So this means we can now get rid of the nullability here, and instead we can still use our code as before. We just have to make sure to actually set a value to our member variable before using it. So with lateinit, we basically say that we're gonna initialize this before use. If we don't, we of course run into trouble, because, well, we can't use a non-initialized variable. But this is just a nice way, in this case, to get rid of null. But we still have a var; we can't still use a val, because we do still set tvDescription only here in this line. And it's actually not possible with the combination of lateinit. So this is already a lot better than before, because we got rid of null in our code, but now with Kotlin, there's actually a very nice way to do this even more simply, so when you go back to the built up Gradle file for the project, you can see we have this plugin here called kotlin-android-extensions, and that's gonna automatically go ahead and create member variables that we can simply access in our code without actually doing this ourselves. So the way this was called in our layout XML was tv, underscore, description, so you can see that's actually a variable here in our code already, so there's no need for us to actually create a member variable and to clutter our code with, well, when you have ten properties, so you're gonna have all those up here, then you're gonna have to initialize all of them in the onCreate method, so it's gonna really clutter up the code with just very simple initialization, and this way here, you can simply go ahead and use all the elements on the layout right away. So you could also see we have tv_title, that's also available; we could set some text there, and of course, we can also access the image view, and then use this in the same way you would with any other image view in Android, for instance setting the image bitmap. So this is a really nice way to get rid of some of the clutter and boilerplate in your code, and it's also a very safe way to do this. You don't have any trouble with null, you don't have any mutable member variables in your class, and you just got rid of lots of lines of code. But there are also some drawbacks to this approach, because first of all, this is a little bit of magic, so for many people who aren't used to this, it's gonna be unclear where this variable suddenly comes from. Of course, you can always in IntelliJ or Android Studio just use Ctrl+V to go through the declarations, and they're gonna see, "Oh, it's just the ID "of the element in the layout, "so that's where it comes from," so they're also gonna be able to know how to access other elements, like this one for instance, and it's not gonna be so magic anymore. But at first glance, it's gonna be, well, a little different than what people are used to from the Java world. And also, you should of course make sure to use good names in the layout XML. You can also go ahead, of course, in your layout now, and actually use names that follow the coding conventions for Kotlin or Java, so that in your code, you have a member variable called tvDescription, with camelcase, so that it fits better into the rest of the code, but you may also want to actually stay with the normal XML kind of naming things, because that way, it's also clearer that this is again one of those variables that comes actually from the layout. So here in this course, I'm actually gonna stick to the XML naming, so that when you see a variable with an underscore, for instance, you know immediately that this is coming from the layout. And also I'm gonna make use of Kotlin Android extensions in general in order to get rid of all the initialization code, just to access all the elements from the XML layout. Alright, so again, we made our code much more concise with this; we also made it much safer. We don't have to use null, we don't have to use mutable member variables, and it's just very easy and concise and, well, nice to use. So I hope you like this approach, using the Kotlin Android extensions, and of course, in the coming lectures, we're gonna see many more instances of how we can make our code cleaner with Kotlin. So I hope you're excited, and I'm gonna see you again in the next lecture.