`AsyncTask.THREAD_POOL_EXECUTOR`

# coroutines

[Paul Woitaschek]

AsyncTask.THREAD_POOL_EXECUTOR

[igorvd]

I'm considering using it too. But my unit tests are now failing because of the android framework dependency

[alex.krupa]

@igorvd pass your dispatcher through the constructor so that you can easily replace it with a non-Android one in unit tests.
Another solution (that may be considered not clean) would be to make the top-level property from @louiscad's suggestion a var and overwrite it with a test dispatcher.

[Paul Woitaschek]

I always inject the dispatchcer

[igorvd]

Yeah I sugest it on the project start, but my manager tought that it would not be necessary...

For now I just put it in a try-catch, and use the CommonPool in case the asyncTask is not available. At least the tests are working...

But I'll definitely refactor to inject the dispatcher eventually

[dave08]

Maybe a top level val with an if on BuildConfig might be better than try catch?

[dave08]

But injection is probably best...

[igorvd]

what should I test on buildConfig? I don't want to test for debug builds to choose the dispatcher, for example

[dave08]

https://stackoverflow.com/questions/36105135/android-studio-check-for-a-custom-build-type