APIs and networking

So far, all of our data has been written directly in the code. A real application queries a server, and that simple change introduces a difficulty of a different nature: the network is slow and fallible. A request takes anywhere from thirty milliseconds to thirty seconds. It can fail because the phone is in a tunnel, because the server is restarting, because the certificate has expired, or because the user closed the screen in the meantime.

The Flutter UI runs on a single thread. Anything that blocks this thread blocks the display: no more animation, no more scrolling, no more response to touch. After a few seconds, the operating system offers to close the app. This means a network call can never be synchronous, and the code must explicitly handle three states instead of one: loading, success, failure. The third is the one people forget, and it's the one that earns bad ratings on the app stores.

This lesson builds a complete, honest network layer: a serializable data model, an isolated service, the conversion of errors into understandable messages, and the display of all three states. We'll deliberately start with the version that freezes the app, because understanding why it freezes is worth more than reciting async.