I don't see any safely issues with the first. But you cannot use first approach in some cases. For e...

# coroutines

[gildor]

I don't see any safely issues with the first. But you cannot use first approach in some cases. For example you cannot use it for Android Fragments when Job can be recreated

[louiscad]

I checked for Fragment.viewLifecycleOwner, an a new one is generated on each view creation (including retained fragments), so now I'm confident the first approach is correct (and the second is the same but with extra allocation)

[gildor]

Sure, if you connect it to viewLifecycleOwner

[gildor]

It still can make sense for similar code with complicated lifecycle. But I think one should use one everywhere when it's possible

[gildor]

Also instead updating Job each time you can update coroutineContext instead to avoid allocation on access

[louiscad]

That's right, although I'm not sure it's worth the hassle managing such reuse, especially when all the view has been destroyed and will be created again (which is orders or magnitude more allocation)

[kingsley]

I do use the first one like:

override val coroutineContext = SupervisorJob() + Dispatchers.Main

No extra field is needed, since I can easily do coroutineContext.cancel() directly.
I use the supervisor job since I only want it to be explicitly canceled