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

@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.

I always inject the dispatchcer

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

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

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