3 ms·

On Android, this uses curl and not HttpUrlConnection so its not very native.

jeroenhd 3y ago
I'm not sure if HttpUrlConnection is still the way to go on Android. Its lack of caching providers has driven most apps to using other HTTP clients (often from Java land, but also some Kotlin native wrappers). The Android SDK docs provide an entirely different approach to "simple" HTTP requests: https://developer.android.com/guide/topics/connectivity/cronet/start https://developer.android.com/guide/topics/connectivity/cron... It appears Google recommends CroNet, which is Chromium's network stack. I can see why (the Chromium stack is probably the most optimised stack for client-server applications that Google maintains) but even Google seems to have abandoned their Java 7 wrappers for something better. I wouldn't have picked curl for Android myself (CroNet sure sounds like it makes more sense) but it'll work just as well and saves everyone the time of figuring out obscure errors that will undoubtably show up eventually writing wrappers like these.
- lenkite 3y ago
  Ah..thanks for the info. They have yet to update their training articles. Still demonstrate use of the old HttpUrlConnection. https://developer.android.com/training/articles/security-ssl https://developer.android.com/training/articles/security-ssl. HttpUrlConnection includes a response cache (android.net.http.HttpResponseCache) actually. The Android implementation has significant differences from the usual JDK implementation.
  - jeroenhd 3y ago
    I think "they have yet to update their training articles" is a great summary of the introductory Android documentation. They give you the basics in the form of useful guides, then tell you to use the more modern API (Jetpack and such). The Jetpack documentation often comes down to Javadocs and one or two bits of example code of very specific use cases. This is especially annoying when there are multiple "new" libraries. Last time I tried to relearn native Android development, I got halfway through the "new" way to do things before Android Studio told me the stuff I was doing was deprecated and referred me to a whole different library without any useful training materials. At some point Google should really just redo their documentation to get everything in sync.
Klonoar 3y ago
You are correct; this gets brought up whenever I bring up the point. :) I'm mostly putting it out there to make people realize that their pursuit of isolated library code is potentially missing out on obscurely documented reasons as to why one should consider the built-in APIs. I would say anything that might exist to cover this in Rust should not use `curl` under the hood either, though in practice I think that's unlikely to happen since Rust (IMO) has a stronger networking story.

I'm not sure if HttpUrlConnection is still the way to go on Android. Its lack of caching providers has driven most apps to using other HTTP clients (often from Java land, but also some Kotlin native wrappers). The Android SDK docs provide an entirely different approach to "simple" HTTP requests: https://developer.android.com/guide/topics/connectivity/cronet/start https://developer.android.com/guide/topics/connectivity/cron... It appears Google recommends CroNet, which is Chromium's network stack. I can see why (the Chromium stack is probably the most optimised stack for client-server applications that Google maintains) but even Google seems to have abandoned their Java 7 wrappers for something better. I wouldn't have picked curl for Android myself (CroNet sure sounds like it makes more sense) but it'll work just as well and saves everyone the time of figuring out obscure errors that will undoubtably show up eventually writing wrappers like these.

lenkite 3y ago
Ah..thanks for the info. They have yet to update their training articles. Still demonstrate use of the old HttpUrlConnection. https://developer.android.com/training/articles/security-ssl https://developer.android.com/training/articles/security-ssl. HttpUrlConnection includes a response cache (android.net.http.HttpResponseCache) actually. The Android implementation has significant differences from the usual JDK implementation.
- jeroenhd 3y ago
  I think "they have yet to update their training articles" is a great summary of the introductory Android documentation. They give you the basics in the form of useful guides, then tell you to use the more modern API (Jetpack and such). The Jetpack documentation often comes down to Javadocs and one or two bits of example code of very specific use cases. This is especially annoying when there are multiple "new" libraries. Last time I tried to relearn native Android development, I got halfway through the "new" way to do things before Android Studio told me the stuff I was doing was deprecated and referred me to a whole different library without any useful training materials. At some point Google should really just redo their documentation to get everything in sync.

Klonoar 3y ago

You are correct; this gets brought up whenever I bring up the point. :) I'm mostly putting it out there to make people realize that their pursuit of isolated library code is potentially missing out on obscurely documented reasons as to why one should consider the built-in APIs. I would say anything that might exist to cover this in Rust should not use `curl` under the hood either, though in practice I think that's unlikely to happen since Rust (IMO) has a stronger networking story.