-
Notifications
You must be signed in to change notification settings - Fork 7.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run suspending calls on Dispatchers.Default
#3693
base: trunk
Are you sure you want to change the base?
Run suspending calls on Dispatchers.Default
#3693
Conversation
cb34de1
to
4bb9250
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JakeWharton any thoughts on this?
4bb9250
to
98ad945
Compare
Modified to remove the public API to set the |
98ad945
to
b0770ff
Compare
Dispatchers.Default
b0770ff
to
632bc53
Compare
This addresses a need for off-main-thread invocation of Call.Factory.newCall to support lazy HttpClient initialization.
632bc53
to
84350cc
Compare
@@ -30,57 +30,63 @@ import kotlin.coroutines.resumeWithException | |||
inline fun <reified T: Any> Retrofit.create(): T = create(T::class.java) | |||
|
|||
suspend fun <T : Any> Call<T>.await(): T { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use these would be less git changes, and needs to rebase.
suspend fun <T : Any> Call<T>.await(): T = withContext(Dispatchers.Default) {
suspend fun <T : Any> Call<T?>.await(): T? = withContext(Dispatchers.Default) {
suspend fun <T> Call<T>.awaitResponse(): Response<T> = withContext(Dispatchers.Default) {
Run suspending calls within an optional
CoroutineDispatcher
, orDispatchers.Default
if none is provided.Our first call to any Retrofit method is blocked by the initialization of our
OkHttpClient
(a prerequisite for the creation of aCall
). Onsuspend
APIs in Android, this is a problem: up until the invocation ofcall.enqueue
, the caller will be running synchronously on the UI thread, which means the UI thread is blocked waiting onOkHttpClient
initialization. This has been causing ANRs for us, even after attempting to work around by triggering initialization earlier in the app's lifecycle.This fixes the issue by running all calls on a
CoroutineDispatcher
, either one provided inRetrofit.Builder
or, failing that,Dispatchers.Default
.Since this changes forces all exceptions off of the calling stack frame and onto a
CoroutineDispatcher
, the hacks to get around limitations in exception throwing from Java Proxy objects can be safely removed.