If you really want to achieve a great experience for an interactive networked application, you should engineer things where everyone is close enough to your ser

If you really want to achieve a great experience for an interactive networked application, you should engineer things where everyone is close enough to your servers to get a response quickly. Or design an experience that does not need to be network interactive. > 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.