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.