Case — a mobile application

the same API, a different conversation

What it is

A fourth consumer of the same API: a Flutter application. In substance the screen is the one from article 14.3 — a list of cities with temperatures — but the conversation with the AI comes out different, and the differences are worth seeing side by side.

Step 1. What changes in the mini-spec

Three lines compared with article 14.2 — and each one drags work behind it:

The API's address. localhost in an application on a phone points at the phone itself, not at your machine. During development you need the machine's address on the local network; in production, a real domain. It is the first thing people trip over, and an AI doesn't warn you because it doesn't know where you are running things.

The network drops. For a website that is rare; for a phone it is normal (article 11.5). Which means the last data has to be kept on the device and shown with a "updated at such-and-such" note, rather than an empty screen.

Updates aren't instant. A website updates when the page is reloaded, an application when the user agrees to it (article 12.3). Which means the API can't break compatibility: the temp field stays temp forever.

Step 2. The request

Flutter 3.38, Dart 3.10. State with provider 6,
don't add other state libraries.

One screen: a list of cities with temperatures.
Data: GET http://<address>/cities,
the response [{"name": String, "temp": double?}].

I need:
- a City model with fromJson, no casts,
  temp honestly nullable
- four states: loading, error, empty, data
- the API address in a setting, not hard-wired
- the layout checked at 360 wide and with a long name

The list of files and what's in each first. Code after
"yes".

Compare it with the request from article 14.3: half the lines match word for word. Four states, explicit types, the address in a setting — these aren't properties of React or Flutter but properties of the task "show data from the network". Which is why a good request carries over between stacks almost in full.

Three things differ, and all three are about the platform: the versions (here you must name them), the state library, and checking on a narrow screen.

Step 3. What to check in the answer

Since it can't be run, what is left is what can be read. In order of importance:

1. The API version. The stack's main problem (article 11.2). Outdated widget and parameter names; flutter analyze usually finds them.

2. !, late, dynamic in the JSON parsing. The server can answer with an error, and json['temp'] as double will kill the application. The model should have an honest double? and a check, not a cast.

3. The four states — are they all there? The most frequent: "the data arrived" exists, the rest doesn't.

4. Requests in build. Going to the network belongs to the data layer, not to the build method (article 11.4).

5. dispose on the controllers. Forgotten cleanup.

6. Fixed sizes. Overflow on a narrow screen.

That is the same list as in article 11.6 — here it is simply applied to a specific task.

Step 4. A conversation worth starting early

I'm going to release this application to a store.
List what has to be decided before the first release and
what can't be changed after it.

The answer to that question is taken apart in article 12.2, and it is exactly why the mobile case is worth planning longer than the others: a website is redone in an evening, and an application identifier never is.

Step 5. An honest conclusion

Of the API's four consumers (the bot, the website, the application, the script) this one is the most expensive: its own stack, its own build, its own release process, no possibility of rolling back. And its screen is the same as the website's.

The question worth asking yourself before starting rather than after: do you need this application, or is a website open on a phone enough? For a list of cities with temperatures the answer is usually "the website is enough". An application is justified when you need something a website doesn't have: working without a network, notifications, the camera, background work.

And that is the architectural decision from chapter 13 — the very one an AI will take for you if you don't take it yourself.

Cheat sheet