Stating mobile interface tasks

what to name besides the appearance

What it is

The techniques from article 10.5 work here too: describe states rather than pixels, give a signature, ask in parts.

But a mobile application has things a website doesn't — and if you don't mention them, the AI won't ask.

What to tell the AI

Six things specific to mobile

1. Versions. Flutter breaks compatibility more often than most frameworks:

Flutter 3.38, Dart 3.10. Code for those versions only.
If you propose something from a later one, say so.

2. The state library. Name it and the project won't grow a second one (article 11.4).

3. Screen size and orientation. Phones differ, and "it looks fine" on one means nothing:

Check the layout on a narrow screen (360 logical pixels)
and in landscape orientation. Don't use fixed heights.

4. What happens with no network. A mobile app loses its network constantly — that is the norm, not the exception:

The network can drop at any moment. What do we show:
while loading, on a network error, on an empty response,
on successful data. All four are needed.

5. Permissions. The camera, location, notifications, files — all of them require asking the user, and a refusal has to be handled:

I need location. Handle three cases: granted, denied,
denied permanently. In the last case, an offer to open
the settings.

The third case is always forgotten, and it is the nastiest: the application asks endlessly for a permission the system will never show again.

6. Platform differences. Android and iOS behave differently: the back button, the safe areas at the screen's edges, the look of dialogs.

We're building for Android and iOS. Flag the places where
the behaviour will differ.

What not to do

Don't ask for "make it look nice". That is the anti-pattern from article 3.16, and in Flutter it is especially destructive: you will get a ten-level tree with eyeballed sizes.

Don't describe things in pixels. Theme.of(context) and the ready-made spacing widgets exist precisely for that (article 11.3).

Don't ask for a whole screen. Four steps are cheaper: data model → card widget → list screen with its states → error handling.

A check worth ordering straight away

Once you've written it: list what I should check by hand on
a device. Include the narrow screen, no network, and a
denied permission.

That list is a draft of the checklist from article 11.6, written for this particular task.

What to look for

Only the happy case is built. As in React: "the data arrived" is there, loading, errors and emptiness are not.

No handling of a denied permission. The application hangs on the request.

Fixed sizes. It will fall apart on a different phone.

Strings not pulled out. Labels written straight into the widgets — add a second language and everything has to be rewritten.

Platform differences ignored. It works on Android and behaves strangely on iOS.

Cheat sheet