Multiplatform support

Given that okio went multiplatform already, and okhttp is slowly going towards that direction, would it be possible for Retrofit to go multiplatform some day? I’m just curious what are the required steps for this, apart from the actual conversion to Kotlin (which is not planned yet, according to the issue I mentioned).

I would see moving from reflection-based annotation parsing (as I assume it’s not working in native) to compile-time annotation processing + codegen of interfaces’ implementations (instead of create method) as a necessary step, but what could be else?

[JakeWharton]

No earlier than 2 years. More realistically probably 4 or 5 years.

To say Okio went multiplatform is true, but it lacks the facilities for even implementing OkHttp in multiplatform contexts (specifically, timeouts and deadlines). So we’re really blocked on Okio finishing itself going multiplatform and exposing this behavior, likely through coroutines. Additionally, blocking IO simply doesn’t work in places like JavaScript so it’s not clear Okio is even ready to be utilized there. Essential functionality like the gzip and deflate support are absent on non-JVM platforms. That’s the first blocker.

Next, OkHttp is now written in Kotlin but it’s API is coupled to the JVM. Decoupling this will be a large effort and almost certainly require breaking the API. Not to mention the reimplementation on JS and native, or delegation to platform-specific equivalents in a way that provide consistent behavior. This can probably be done on native, but OkHttp doesn’t seem the right layer of abstraction for adapting JS clients. That’s the second blocker.

Finally, Retrofit relies on mechanisms which are not available on JS or native or do not have satisfying equivalents. Switching to code generation is not at all easy because of the behavior of converter factories and call adapter factories. This was evaluated 5-ish years ago and deemed infeasible or requiring too many trade-offs. That leaves reflection, which is possible, but blocked on Kotlin again. And it would also would likely mean taking a kotlin-reflect dependency on the JVM which is currently a complete non-starter.

Now Retrofit is a layer where abstraction over multiple HTTP clients could be done, and it probably could be done in about a year. But it would mean severely restricting the API where there weren’t any converters or adapters so suspend fun was your only choice and kotlinx.serialization types, UByteArray, or String were the only supported return types (or Response<T> of those types). That might be something I would build, but it would be the opposite of Retrofit.

It’s not that I’m opposed to this. I want this. It just doesn’t seem feasible in the next few years as it requires significant work on our upstream dependencies first. I’ll be pushing for, following, and in some cases contributing that work. But this is definitely not something you should be holding your breath on.

[JakeWharton]

No

On Sun, Sep 1, 2019, 1:55 AM mengrong.yang [e-mail] wrote:

Excluding js, is it easier to implement on other platforms?Android,IOS,MacOS,Windows,Linux and so on.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/square/retrofit/issues/3181?email_source=notifications&email_token=AAAQIENG2P7XHYEGMV6PBTDQHNKOJA5CNFSM4IH26TZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5T3FTI#issuecomment-526889677, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAQIEM52EK3STXOINFJMLLQHNKOJANCNFSM4IH26TZQ .