I would make sure to use the IO dispatcher instead and probably a lifecycle scope.
I would make sure to use the IO dispatcher instead and probably a lifecycle scope.
That’s true, but does your answer on SO pay the bills for running and serving the content?
Answer my original question first and you have your proof or not. If you can’t answer, there’s your proof.
Yeah, information was freely traded before the advent of capitalism, and you’re still free to walk over to your neighbor’s house and ask questions about your code, but they’re not going to be near the quality of a large scale service like SO.
Where do you expect the resources to come from to have and serve content reliably? They don’t run on hatred of capitalism, they run on money.
Seems like too little too late. Unless… there’s built in functionally to gaslight me, shut my questions down as duplicates, and tell me I shouldn’t be doing something someway without any knowledge of my constraints. Otherwise how would it be any better than the others that were already trained on SO data?
Ah yes the same evil capitalism that:
Do you have a better system in mind?
For the dispatchers, the docs do a better job explaining then I should try to give, but in short IO is optimized for long running operations, whereas Default is optimized for running more intensive computations.
For the lifecycle scope that’s basically it. Fragments, Activities, and ViewModels all have their own variants of this. It’s almost always bad practice to have a coroutine not scoped to some form of lifecycle or you could easily end up with a bunch of memory leaks and unreported issues (https://kotlinlang.org/docs/coroutines-basics.html#structured-concurrency).