https://kotlinlang.org logo
Join Slack
Powered by
I don't do it to "avoid that its type can be null"...
# android
a
I don't do it to "avoid that its type can be null", I do it to handle the fact those properties are non-null but can't be initialized until 
onCreate
is called, in that case I think 
lateinit
is a godsend
a
Exactly, I agree with you. However, static analysis tools such as detekt consider the usage of lateinit a bad practice for property initialization and I'm trying to convince my team that it could be used for that purpose
a
Does the team have some other opinion on that? If so, what's their alternative?
I bet detekt means lateinit is bad in case it can be replaced with ordinary non-null property
I think nullable property is a lot worse than lateinit
a
Their alternative is make the property nullable
a
Try using constructor injection or delegation to initialize properties
I think that's the key
you can do 
var dependency: SomeType by Delegates.notNull()
but it's effectively the same as lateinit
a
Behind the scenes its the same thing though
a
so if you can't do constructor injection (as is the case for activities and fragments and others) you're left with lateinit
a
Yup
a
when introducing that rule, they said explicitly they wouldn't want to enforce it by default, because of activities for example
a
Do you think its a different scenario when assigning 'binding' (from databinding) properties? They have to be assigned from Fragment#onCreateView or Activity#onCreate
a
like with butterknife?
I'd make such property nullable only if it is optional
if I expect it to always be there I make it lateinit as well
👍 1
a
Yea, that's my approach also
a
yeah, so for the result of 
DataBindinUtil
setContentView
and similar I use lateinit as well, no reason to make it nullable
but sometimes it doesn't need to be a class property, it can be local
and it's not nullable then obviously, so why make it nullable when it's a class property
a
But most of the times you assign the 'viewmodel' to the binding after onCreateView
So it makes sense that it is a class property
a
agreed
a
Well, so I'll keep trying to convince them. Thanks for the insights
👍 1
a
good luck 😄
😁 1
a
Team decided to go with lateinit, 👏
As a matter of fact it was all a misunderstanding
t
Yeah, definitely use lateinit - Kotlin is designed to have the flexibility and syntax of modern managed languages but it tends to follow a lot of the rules of microprocessor development when it comes to how you should approach things. Which makes sense why we have Kotlin-Native and micro support for it.
I actually aim to never use var when writing Kotlin
metal 1
But in this case, its ok. It was put there for a reason.
👍 1
2 Views
Open in Slack
PreviousNext
Powered by