To be clear, are you suggesting that network requests in an Android app should block the UI thread, on the assumption that everyone will have a good enough connection (and one close enough to your server) to receive the response quickly?
> are you suggesting that network requests in an Android app should block the UI thread
I'm suggesting that if network requests over a cellular connection could just be made within a frame (really, a tick, nothing is that fast), like they are on Fortnite or Roblox for Android, for example - if people applied the same engineering practices and standards to GUI applications as for realtime multiplayer games - yes, the apps would be way better, and as a side effect, way easier to author. The server and deployment story would get more complicated. But maybe that's a good thing, to put the hard work where it's easier to do.
For a concrete example of what that would look like, the io_uring thing posted here just a bit ago was really fascinating. It's probably the way HTTP should have been done in Java from the get go - a request that returns immediately, but you must poll in the GUI that actually needs its results to render, and you must poll at the right time. Clunky, but still, all synchronous and all direct.
Go look up dead reckoning, those types of games are built to handle 100-250ms of latency which is way outside a frame/tick.
It's very kind of you to commit to building a cell tower in the grounds of the rural hotel I was at yesterday.