Consider interacting with the network off the calling thread

[jzbrooks]

When retrofit added suspend support, its suspending functions ran the actual network interaction off the calling thread. While it's fairly easy to wrap connect-kotlin generated suspend calls in a withContext dispatch, having that thread switch happen automatically seems less error prone. Since we use both buf and retrofit in our codebase, this is a relatively common source of confusion that often results in NetworkOnMainThreadExceptions.

Square's implementation uses their own executor, but using the built-in Dispatchers.IO might work too? I'm unsure which would be preferable.

square/retrofit#2886

[jhump]

@jzbrooks, what version are you using? As of v0.5.0, you can set a property on the ProtocolClientConfig so that this dispatch happens automatically. The change was made here: #218.

[jzbrooks]

Hey @jhump, that's exactly what I was looking for. I missed that note on the release. Thanks!

[erawhctim]

Any reason why this isn't enabled by default?

[jhump]

Any reason why this isn't enabled by default?

@erawhctim, at the time I added it, I was concerned about it being surprising behavior. Also it's not backwards compatible: if you have application code that did not configure this new property and explicitly dispatched to a particular context, the library under the hood would re-dispatch back to its default context, which may be surprising or problematic.

I'm certainly open to changing the default behavior though before we get to a v1.0.0 release. But I was thinking of making that change in the same release as other more significant (and backwards-incompatible) API changes, so that it's less likely to be overlooked when someone upgrades.

[erawhctim]

very wise; that makes a lot of sense 👍 Setting that as the default for v1.0 sounds ideal.