Screens & Components

Designing Screens

Screens are what the app shows, and they are designed in the platform rather than written in code.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

What a screen carries

• A key and a title, and an icon.
• A type, deciding how it behaves.
• Navigation — whether it appears in the app’s navigation and in what order.
• Data binding — the datastore, the browse view or input view it uses.
• Filter, sort field, sort direction and page size.
• Layout — the arrangement of its components.
• Permission and group requirements.
• Offline caching for that screen.
• Minimum app version.

Bind to a view, not a raw table

A screen bound to a browse view inherits that view’s columns, filtering and ordering, and stays in step when the view changes. Binding to a table means rebuilding all of that per screen.

Filter and page size matter more on a phone

A list of eight hundred records is unusable on a small screen and slow on a mobile connection. Filter to what this user needs — their jobs, today’s work, their region — and keep the page size modest.

The instinct to show everything and let people search is a desktop instinct.

Fewer screens in navigation

Mobile navigation has room for about five items. Put the daily tasks there and reach everything else from within a screen.

An app whose navigation lists twelve screens is one where people cannot find the two they need.

Sort for the task

Most recent first, or nearest due first, or by distance. The default order on a phone matters far more than on a desktop, because nobody scrolls to find something and nobody re-sorts.

Minimum app version protects you

A screen using something only newer builds understand can name the version it needs, so older installs simply do not receive it rather than receiving something they cannot render.

Screens ship immediately

Changing a screen reaches installed apps without a rebuild or a store release. That is what makes this practical — you can improve the app weekly.

It also means a mistake reaches everybody immediately, so treat a screen change as a live change.

Test on a real phone

Not a simulator on a large monitor. Text size, tap targets, list density and how much is visible without scrolling are all different, and all decide whether the app is usable in the field.

Worked example

A field app has four screens in navigation — today’s jobs, my week, scan, and profile — each bound to a browse view filtered to the signed-in engineer, sorted by scheduled time, twenty per page. Everything else is reached from within a job.

Recommendations

• Bind to browse views, not raw tables.
• Five navigation items at most.
• Filter hard — a phone is not a desktop.
• Test on a real device in real conditions.

Components

Components are what a screen is made of — fields, buttons, lists, a camera, a map.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

What a component carries

• A key, a type and a label.
• A bound field, where it shows or captures data.
• Configuration, actions and visibility rules.
• A required capability, where it needs a device permission.
• A minimum app version.
• Column span and order, and a parent for nesting.

Capability is the important field

A camera component needs the camera capability; a map needs location. If the installed binary does not declare that capability, the component is omitted entirely from what the app receives.

That is the correct behaviour and it explains the most confusing symptom in the whole module: a component you configured that simply is not there on the device. The answer is almost always that the installed build predates the capability.

Minimum app version does the same job over time

A component using something only newer builds understand names the version it needs, so older installs do not receive it. Between the two mechanisms, an app on an old build degrades rather than breaking.

Design for thumbs

Tap targets large, spacing generous, the important action within reach of a thumb on a large phone. A component grid that works on a desktop is usually too dense on a phone.

Capture rather than type

The whole point of a native app. A barcode scan instead of a reference number, a photograph instead of a description, a location stamp instead of an address, a signature instead of a name.

Every field a user does not have to type on a phone in the rain is a field that gets filled in correctly.

Visibility rules keep screens short

Show a component only when it is relevant — the "reason" field when the outcome is a failure, the parts list when the job type needs one. A long form with most fields irrelevant is the commonest reason mobile forms are abandoned.

Actions are what buttons do

Keep them few and unambiguous. On a phone there is no room for a row of eight buttons, and a misfired action is easier than on a desktop.

Test each component on the device

Particularly the capability-dependent ones. A camera component behaves differently on iOS and Android, and permission prompts appear at different moments.

Worked example

A job screen uses a barcode component to identify the asset, a camera component for before-and-after photographs, a signature component for sign-off, and a location stamp. The parts list appears only when the job type requires it. Nothing requires typing except a short note.

Recommendations

• Check the capability when a component does not appear.
• Capture, do not type, wherever possible.
• Use visibility rules to keep forms short.
• Test capability components on both platforms.

Offline and Permissions

Unlike the progressive web app, the native app can work genuinely disconnected.

Where to find it

Architect Panel → Mobile Apps:

• Mobile Canvas — the app, its screens and its settings
• App Builds & Releases — building and submitting
• Mobile Devices — the devices that have installed it

Architect Panel → Configuration:

• Site Settings — the Mobile Apps option group

Offline mode

The app has an offline mode and a window in days. Screens are individually marked for offline caching, so you choose what is available when there is no signal rather than trying to cache everything.

Cache the screens people need in the field

Today’s work, the job detail, the form they complete. Not the reports, not the history, not the search.

Being selective keeps the cached data small, which matters on a phone, and keeps sensitive data off devices unnecessarily.

Queued changes and the retry window

Changes made offline are queued and sent when a connection returns, within a configured retry window measured in days. Beyond that window, an unsent change is stale enough that sending it is probably wrong.

Duplicates are prevented explicitly

Each queued operation carries an idempotency key. If the same key arrives again, the stored response is replayed rather than the operation being performed twice — and a key reused for a genuinely different request is refused with an explicit error.

This is what stops a flaky connection producing three copies of the same job completion, which is the characteristic failure of offline apps that do not do this.

Tell users what is queued

Somebody working offline needs to know their work is held and not yet sent. An app that looks identical online and offline produces users who close it believing work is saved.

Screen permissions

Each screen can require a permission or name the groups that may see it. Screens the user cannot reach are not delivered to their app at all, rather than shown and refused.

That is the right behaviour — it keeps the app small and it does not advertise what somebody cannot have.

Offline data is data on a device

A phone that is lost has cached records on it. Consider what is cached, keep the window short, require biometric unlock, and be able to revoke a device.

"How long is customer data held on an engineer’s phone" is a question you should be able to answer with a number.

Test offline properly

Flight mode, complete a real task, close the app, reopen it, restore the connection, and confirm exactly one record arrived. That last check is the one people skip and the one that matters.

Worked example

A field app caches today’s jobs and their forms for three days, queues completions with idempotency keys, and shows a banner listing unsent items. Testing in flight mode with a forced app restart confirmed one record arrived, not two.

Recommendations

• Cache only field screens, not the whole app.
• Keep the offline window short — it is data on a phone.
• Show users what is queued.
• Test that exactly one record arrives after reconnecting.