I think I've seen you mention this before here, and it led me to writing a note about this topic in some documentation at work. So, thanks for the heads-up. Do you have any idea what would be required to write a URLSession backend for ureq/reqwest?

To be honest I've not looked into how tricky it would be - if anything I went the opposite route of experimenting with a reqwest-API-compatible wrapper for URLSession but didn't get too far due to other projects taking up my time. It might be the easier path though - one crate that basically uses a `reqwest`, `ureq` or `URLSession` backend since the former two would still work on Android to start.

For reqwest specifically I guess it would also depend on how badly you want `async` support or not (i.e just the blocking module API).

Thanks, sounds like your initial approach would be easier, a blocking API is fine for me. I'll look into it a little further.

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

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/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.

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.

HttpUrlConnection includes a response cache (android.net.http.HttpResponseCache) actually. The Android implementation has significant differences from the usual JDK implementation.

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.

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.