Better documentation about async argument

[tir38]

I like that the async argument got added in #416. But even after reading https://medium.com/@sweers/rxandroids-new-async-api-4ab5b3ad3e93 I still don't know when to use it. This got raised on the original issue: #228 (comment) Right now I'm inclined to to just slap it on every call. Any guidance in either readme or javadoc would be much appreciated.

[ZacSweers]

Here's a good answer from Jake: https://www.reddit.com/r/androiddev/comments/97u44h/rxandroids_new_async_api/e4blnkd/

Nothing runs between the [Application] constructor and onCreate so you don't gain anything. If you want to run earlier you should put it in a static init block. But then content providers might still run first. So you have to put it in the static init block of an app component factory. And that is truly the earliest application code can run.

[JakeWharton]

How often are you calling this API? It should be once for the whole app. We couldn't make it the default, but it would have been if we could.

[hannesstruss]

@hzsweers 🔍 🕵️ the Medium post is also slightly confusing:

Edit: Due to classloading, the below code was slightly wrong for setInitMainThreadSchedulerHandler. To avoid initialization of the default one, you should call AndroidSchedulers.from(...) from inside the lambda/callable passed in, rather than before.

In the code samples, AndroidSchedulers.from is still called outside the lambda, yet the edit paragraph states the code was wrong, implying it was corrected. :)

[tir38]

Ahh ok. I misread the blog post. I assumed that we had to decide to supply this to every instance of:

.observeOn(AndroidSchedulers.from(Looper.myLooper(), true))

[JakeWharton]

No you should never do that. Schedulers are long-lived instances–ideally singletons.

[tir38]

I guess there are now enough conversations floating around here, reddit, and SO that it should be clear when/how to use this.