Android module and Async Dns

[yschimke]

Primarily an Android specific implementation of AsyncDns.
This is intended to unblock the Happy Eyeballs, fast follows implementation to handle IPv4 and IPv6 separately.

AsyncDns should be considered an experimental public API.

@swankjesse I don't know how to do this in okhttp core using Flow. Bringing in kotlinx.coroutines is probably awkward for JVM clients already frustrated at getting kotlin, and more likely to introduce versioning issues that stdlib (which has been perfect).

Also an optional okhttp-android module, to allow specific implementations that are network aware*. Published as an AAR file which might help with android specific optimisations like baseline profiles.

Android apps may often need to understand network conditions, choose the appropriate network, and when doing so
should use the appropriate socket factory, dns, and even proxy.

[yschimke]

Two remaining topics

1. When to pull over the changes for DnsOverHttps
2. When to consider the design for other Dns records like Svcb, Https (draft RFC https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/)

[swankjesse]

It gets complicated using one instance to deal with either 1 or 2 responses.

What if we make it so each request gets a single response, and let the caller pick what’s in that response? If the caller wants one callback we can give them that, and if they want two callbacks we can give them that too?

interface AsyncDns {
  fun lookup(hostname: String, callback: Callback)

  interface Callback {
    fun onFailure(hostname: String, e: IOException)
    fun onResponse(hostname: String, response: List<InetAddress>)
  }

  companion object {
    /** Unions the results from [SYSTEM_IPV4_ONLY] and [SYSTEM_IPV6_ONLY]. */
    val SYSTEM: AsyncDns
    val SYSTEM_IPV4_ONLY: AsyncDns
    val SYSTEM_IPV6_ONLY: AsyncDns
  }
}

[swankjesse]

Nice

[swankjesse]

I’d like to run with this on OkHttp 5, and make it so our default Dns internally is async.

[yschimke]

What if we make it so each request gets a single response, and let the caller pick what’s in that response? If the caller wants one callback we can give them that, and if they want two callbacks we can give them that too?

Makes sense, I'll simplify to this API.

[yschimke]

These are not nice from java, but as these are Android specific, I think Kotlin is a good assumption.

[swankjesse]

Yay!

[swankjesse]

Is this comment out of date?

[swankjesse]

Hide public constructor?

[swankjesse]

(Hmmm . . . . actually for Network this is useful . . . hmmmm)

[yschimke]

Yep - I actually liked this bit. There are bugs in stackoverflow because android/wear networking returns differing/empty results across Wifi, LTE, Bluetooth paired connections (on Wear).

The choice is implicit currently with Dns.SYSTEM, and this makes it explicit.

[swankjesse]

Need this be a public API? (I think it has to be??)

[yschimke]

Yep - part of public API.

[swankjesse]

For a follow-up I think we could make it so the main OkHttp artifact’s Platform class directs us to use this code when running on the Android platform?