Gamar Mustafa
05/31/2024, 7:42 AMlateinit ? we are gonna use that property as soon as our activity/fragment is created, so what's the goal/gain here by using lateinit?Joffrey
05/31/2024, 7:43 AMGamar Mustafa
05/31/2024, 7:43 AMJoffrey
05/31/2024, 7:45 AMGamar Mustafa
05/31/2024, 7:46 AM_binding and binding? one immutable and one mutable. then we wouldn't have to deal with nullabilityJoffrey
05/31/2024, 7:55 AMlateinitmohamed rejeb
05/31/2024, 8:04 AM_binding but you need to know that we do that in purpose, so we can clear the binding and set it back to null in onDestroy to make it eligible for garbage collection, if you have this use case you can do it this way, otherwise lateinit is enough.Gamar Mustafa
05/31/2024, 8:11 AMlateinit . I just want to know what we gain by using lateinit .
private var _binding: FragmentMyBinding? = null
private val binding get() = _binding!!
//or
private lateinit var binding: FragmentMyBinding
if we don't gain anything by using lateinit , why people still use it instead of using the first approach? I still can make _binding null to clear the binding.Joffrey
05/31/2024, 8:15 AM_binding property to null later, so binding doesn't have a clear scope for its safe usage. The error thrown by binding would also be quite generic. If you want to fix these little details, you'll end up with even more code. But to be frank this pattern is exactly what the lateinit syntax is meant to express. So basically by using lateinit you have less code, you express the intent better, and it's slightly more constrained.hfhbd
05/31/2024, 8:18 AMmohamed rejeb
05/31/2024, 8:19 AMGamar Mustafa
05/31/2024, 8:19 AMSo basically by using it you have less code, you express the intent better, and it's slightly more constrainedthis is what I was inquiring about. Thanks @Joffrey!
hfhbd
05/31/2024, 8:20 AMJavier
05/31/2024, 10:02 AMval + Lazy without issues