4 ms·

If you use Android along with dependency injection (Dagger2). This was at least necessary when Kotlin was close to 1.0. This was the only part where I ever use

by weitzj 10y ago

If you use Android along with dependency injection (Dagger2). This was at least necessary when Kotlin was close to 1.0. This was the only part where I ever used lateinit.

snuxoll 10y ago
Dagger supports constructor injection, why would lateinit be necessary?
- dpkirchner 10y ago
  Many of the classes you'd write as an Android developer are instantiated by the system somewhere using only those constructors that the system expects to exist. Views, for example, are typically instantiated based on XML layout files that simply reference views by name, without a way to specify a specific constructor to use.
  - snuxoll 10y ago
    Ah, yes - layout inflation is such fun. Still, there are libraries you can use that don't require usage of lateinit. Kotterknife [1] is an option, the Kotlin android extensions [2] is another option though relying on code generation it may not be the first choice of people. Delegates in Kotlin are a powerful tool, and a great way to handle cases where you think lateinit is necessary but really isn't. Otherwise, if you're going with Kotlin anyway you can just get rid of layout XML altogether with anko [3] or even give MVVM a shot with KBinding [4]. [1]: https://github.com/JakeWharton/kotterknife https://github.com/JakeWharton/kotterknife [2]: https://kotlinlang.org/docs/tutorials/android-plugin.html https://kotlinlang.org/docs/tutorials/android-plugin.html [3]: https://github.com/Kotlin/anko https://github.com/Kotlin/anko [4]: https://github.com/BennyWang/KBinding https://github.com/BennyWang/KBinding
    - dpkirchner 10y ago
      I haven't seriously tried Kotterknife, anko (been meaning to!), or KBinding (hadn't heard of it before, will check it out) -- I'm currently enjoying the Kotlin android extensions for referencing views inside custom viewgroups. I use field injection to pull in instantiated Picasso/Glide image libraries and to create/bind to persistent view presenters (it's a Mortar/Flow based app currently). I'm not sure if this is best practice or what but I feel reasonably comfortable having image loaders in the view (when those image loaders do their real work off the UI thread of course). Speaking of Kotterknife, I'm actually in the process of migrating away from Butterknife as I slowly port the app over to Kotlin. Butterknife is immensely useful for Java-based apps, IMO, but the Kotlin android extensions provide most of what I need and Kotlin's syntax largely takes care of the boilerplate I was avoiding by going with BK in the first place. I do miss string/integer/other binding but it's not so bad and, IIRC, kotterknife doesn't provide that anyway -- I explored adding it [1] but I didn't enjoy writing all that code and ended up giving up. I forgot to mention another use-case for lateinit: junit tests. I use lateinit in the test class when testing code that uses constructor injection. This is probably less controversial because it is just tests, though. [1] https://github.com/dpkirchner/kotterknife/commit/39dda1965ee29740cab2e95c3930d968855f1f8b https://github.com/dpkirchner/kotterknife/commit/39dda1965ee...

by weitzj 10y ago

If you use Android along with dependency injection (Dagger2). This was at least necessary when Kotlin was close to 1.0. This was the only part where I ever used lateinit.

snuxoll 10y ago

Dagger supports constructor injection, why would lateinit be necessary?

dpkirchner 10y ago
Many of the classes you'd write as an Android developer are instantiated by the system somewhere using only those constructors that the system expects to exist. Views, for example, are typically instantiated based on XML layout files that simply reference views by name, without a way to specify a specific constructor to use.
- snuxoll 10y ago
  Ah, yes - layout inflation is such fun. Still, there are libraries you can use that don't require usage of lateinit. Kotterknife [1] is an option, the Kotlin android extensions [2] is another option though relying on code generation it may not be the first choice of people. Delegates in Kotlin are a powerful tool, and a great way to handle cases where you think lateinit is necessary but really isn't. Otherwise, if you're going with Kotlin anyway you can just get rid of layout XML altogether with anko [3] or even give MVVM a shot with KBinding [4]. [1]: https://github.com/JakeWharton/kotterknife https://github.com/JakeWharton/kotterknife [2]: https://kotlinlang.org/docs/tutorials/android-plugin.html https://kotlinlang.org/docs/tutorials/android-plugin.html [3]: https://github.com/Kotlin/anko https://github.com/Kotlin/anko [4]: https://github.com/BennyWang/KBinding https://github.com/BennyWang/KBinding
  - dpkirchner 10y ago
    I haven't seriously tried Kotterknife, anko (been meaning to!), or KBinding (hadn't heard of it before, will check it out) -- I'm currently enjoying the Kotlin android extensions for referencing views inside custom viewgroups. I use field injection to pull in instantiated Picasso/Glide image libraries and to create/bind to persistent view presenters (it's a Mortar/Flow based app currently). I'm not sure if this is best practice or what but I feel reasonably comfortable having image loaders in the view (when those image loaders do their real work off the UI thread of course). Speaking of Kotterknife, I'm actually in the process of migrating away from Butterknife as I slowly port the app over to Kotlin. Butterknife is immensely useful for Java-based apps, IMO, but the Kotlin android extensions provide most of what I need and Kotlin's syntax largely takes care of the boilerplate I was avoiding by going with BK in the first place. I do miss string/integer/other binding but it's not so bad and, IIRC, kotterknife doesn't provide that anyway -- I explored adding it [1] but I didn't enjoy writing all that code and ended up giving up. I forgot to mention another use-case for lateinit: junit tests. I use lateinit in the test class when testing code that uses constructor injection. This is probably less controversial because it is just tests, though. [1] https://github.com/dpkirchner/kotterknife/commit/39dda1965ee29740cab2e95c3930d968855f1f8b https://github.com/dpkirchner/kotterknife/commit/39dda1965ee...