Hey all. I am trying to see what Kotlin is about a...

# android

[Alin B.]

Hey all. I am trying to see what Kotlin is about and since I come from java one thing that I see is the way Nulls are handled. Of course, the habit for having null default values and != null check is strong on my end and the first step would be to better understand how to program without having the nulls in mind. So for starters, having a class class Person(val firstName: String, val lastName: String, var age: Int) and avoiding null means that whenever I instantiate it, I need to pass default values? So maybe have firstName="", lastName="" and age=0?

[Lucas Ł]

you can define default values (for `var`s and `val`s) like so:

class Person(val firstName: String="", val lastName: String="", var age: Int=0)

and you don't need to set them when instantiating/using the constructor, for `val`s however keep in mind they are final

[gildor]

Kotlin do not force you to avoid nulls, I think it’s wrong statement.
Yeah, use non-null types is more pleasant, but nulls still welcome and best way to handle many cases. Also Kotlin provides syntactic sugar to handle nullable types, like safe call operator, elvis operator, smart cast

What Kotlin really does: has nullable types and force you to handle them in a safe way

So I would say: use non-null types if it make sense for your use case and use nulls if it also make sense.
For some cases like primitives or String I still use almost exclusively non-null types, because it’s more efficient for primitives and string has good default value - empty string,

[Alin B.]

Thank you very much for your details. My thought is not get starting on the wrong foot with kotlin. Because for instance I could have used default values in java also so that would avoid a lot of NPE, but I haven't done it and now I wonder why...

[Alin B.]

But having a "" for String, doesn't mean that most likely I'll need to check if tat string is not "" so I can do something with it? isn't like replacing != null with !="" ?

[gildor]

It depends on your case. If you want to somehow define absence of value, just use nulls, no need to use default empty string. If you just want to avoid NPE, use default value empty string

In most cases empy string is just fine and no need to check for empty string

[gildor]

but I haven’t done it and now I wonder why...

Because it’s a lot of boilerplate code, for class constructors or for method arguments. Also java doesn’t support default method params, so everyting become even worse for a method with many nullable params, because you have to overload this method to make API more pleasant

[Alin B.]

Indeed, it makes sense what you are saying, Java has a lot more "ceremony" around its classes.

[gildor]

again, there is no universal advice, use nullable or non-nullable types depending on your use case and choose what is better for your particular case null or default value.

[Alin B.]

I have to admit I am a little afraid to dive into this since I also need to learn MVVM and the arch components, but hopefully it will not be a hard thing to get familiar with. I've watched some video demos and Kotlin looks really cool. One other thing I've seen is that var should only be used if really needed and stick with val instead. What would be the reason for this?

[gildor]

because immutable always better than mutable 🙂

[gildor]

if some variable/property initialised only once why do you want to declare it as var?

[Alin B.]

probably this is equivalent with final in java?

[gildor]

also, one more note about case with empty string. If in some case you want to check for empty string you still should do this even for nullable type, there is no way to avoid it

[gildor]

yes, it’s like final and on JVM uses final modifer in bytecode

[Alin B.]

What if a class has a List<Items> as field. that should also be declared as new empy List so it's not null?

[gildor]

just use emptyList<Items>() as default value

[gildor]

but again, it’s not a requirement, everything depends on case, Kotlin even provide extensions to idiomatically handle nullable lists:

val list: List<Items>? = null
list.orEmpty().doSomething()

[Alin B.]

@gildor thank you so much for your time and right on point answers! I really appreciate it. Do you think it's work switching to Kotlin from Java considering the future?

[gildor]

Our team started to use Kotlin almost 2.5 years ago, much earlier than Kotlin became official language for Android and never regret about this decision.
But now I don’t see any reason to avoid Kotlin. On Android it’s not even future, it’s present.

[Lucas Ł]

If you look at it objectively, you obviously still need to know both java and kotlin, because most companies maintain old code bases, while writing new stuff in Kotlin, just because it's better on so many levels.

Java-Kotlin interoperability basically shuts down any uncertainties for a lot of dev teams.

[gildor]

Yeah, sure, I agree with this. Depends what is “switching to Kotlin” for you.
You cannot work as JVM developer without knowledge of Java

[Alin B.]

I usually create Android projects for clients and usually from scratch so probably it's better to do them directly in kotlin. And also from what I saw, it's possible to do node.js in kotlin and that would also be a big plus for backend development.

[gildor]

Yeah, sure. But my personal opinion, that if I would choose backend platform I would rater choose JVM than node.js.

[Alin B.]

Thank you again for your time. I've found https://github.com/googlesamples/android-sunflower and this seems like a good place to dig into the projiect and see how they've matched the jetpack components and mvvm.