You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question: Is it possible to use OkHttp as a network stack on Android? #224
That's an interesting question; we might get some advantages from using a fully fledged HTTP client, but on the other hand we only need a simple WebSocket.
There's also the problem (for this official library) that OkHttp only supports API levels 21 and above, which probably means it's not something we'll pursue.
Only the latest 4.x version of OkHttp actually has API 21 limit, older branch 3.12.x which is still maintained with bug fixes practically supports all relevant versions of Android. As I said, the same version of OkHttp also works on pure Java so this could easily stay a pure Java library.
And finally, I don't have a particular problem to solve (for now), but it's general practice for Android libraries like Glide, ExoPlayer, etc.., to have "modular network stack" support, where support for OkHttp can be added as a small optional Gradle dependency. This is very useful for Android applications which use OkHttp/Retrofit for most of their normal network requests, as it provides a consistent experience across multiple Android versions, which could otherwise differ significantly depending on Android version, etc..
That makes a lot of sense, thank you for expanding. I am worried the current implementation is so tightly coupled with the low-level WS library that changing this would require a complete rewrite. But I'll look into it.
I don't think we really need pure Java support, this library mainly (only?) exists to support Android. Any change that would improve the experience on Android is welcome IMO.
These 2 implement integration only for standard one-off requests, but as I said, OkHttp also has a native API for WebSocket implementation which you could use.
I have a project coming up where I'd use Pusher WebSocket, and will try to play with this myself.
Activity
elverkilde commentedon Oct 2, 2019
That's an interesting question; we might get some advantages from using a fully fledged HTTP client, but on the other hand we only need a simple WebSocket.
There's also the problem (for this official library) that OkHttp only supports API levels 21 and above, which probably means it's not something we'll pursue.
Does this solve a specific problem?
gajicm93 commentedon Oct 2, 2019
Ok let me expand on my question:
OkHttp has native WebSocket support which might make everything easier: https://square.github.io/okhttp/4.x/okhttp/okhttp3/-web-socket/
Only the latest 4.x version of OkHttp actually has API 21 limit, older branch 3.12.x which is still maintained with bug fixes practically supports all relevant versions of Android. As I said, the same version of OkHttp also works on pure Java so this could easily stay a pure Java library.
And finally, I don't have a particular problem to solve (for now), but it's general practice for Android libraries like Glide, ExoPlayer, etc.., to have "modular network stack" support, where support for OkHttp can be added as a small optional Gradle dependency. This is very useful for Android applications which use OkHttp/Retrofit for most of their normal network requests, as it provides a consistent experience across multiple Android versions, which could otherwise differ significantly depending on Android version, etc..
elverkilde commentedon Oct 3, 2019
That makes a lot of sense, thank you for expanding. I am worried the current implementation is so tightly coupled with the low-level WS library that changing this would require a complete rewrite. But I'll look into it.
I don't think we really need pure Java support, this library mainly (only?) exists to support Android. Any change that would improve the experience on Android is welcome IMO.
gajicm93 commentedon Oct 4, 2019
Yeah it would be great if WS and OkHttp implementation were modularized as optional components via interfaces.
If you need inspiration on the programming design pattern how to do this, take a look at these 2 implementations:
ExoPlayer: https://github.com/google/ExoPlayer/tree/release-v2/extensions/okhttp
Glide: https://github.com/bumptech/glide/tree/master/integration/okhttp3
These 2 implement integration only for standard one-off requests, but as I said, OkHttp also has a native API for WebSocket implementation which you could use.
I have a project coming up where I'd use Pusher WebSocket, and will try to play with this myself.