although... i have an idea on how we could get away with it being included by default!

without imposing the Kotin stdlib on everyone

makes sense, dunno, kinda thought that because it was open it will eventually make it to a release or something, then I checked 4 and didn't see it in the changelog and.... when thanks

Kotlin users can still use java.lang.Void, right? this is just a nicety to fit in with the language?

yes

Hi guys.

May I know how to overcome this issue when I am using nullable response?

image.png

the response is not nullable

The

response?.body().result

always give me an underline and state Only safe (?.) or non-null asserted (!!.) calls are allowed on a nullable receiver of type Vibes?.

So I should remove the

?

?

yes

Jake.

It still the same.

image.png

Just wondering why only Kotlin will face this kind of issue.

the body is annotated as nullable

if you receive an HTTP 204 there will be no body

or any HTTP error

Okay.

I think I found the problem.

image.png

I think it is because I set

nullable

on the the data class.

Was there any progress on the idea of having a “retrofit interceptor” so that you can use custom annotations in building requests?

You can use

@Url

in that case

interface UserService {
    @GET("/users")
    Call<List<User>> getAll()
 
    @GET
    Call<List<User>> getNextPage(@Url url: String)
}

Is there documentation/presentations available about Retrofit CallbackAdapters?

they don't exist

Oh good point. I was referring to the CoroutineCallbackAdapterFactory that you’re defining and was wondering where the

retrofit2.CallbackAdapter

came from since it wasn’t clear in that file https://github.com/JakeWharton/retrofit2-kotlin-coroutines-adapter/blob/jakew/suspend/2018-02-16/src/main/java/com/jakewharton/retrofit2/adapter/kotlin/coroutines/experimental/CoroutineCallbackAdapterFactory.kt

ah, yes. that was just an experiment.