Services
Timers, battery, connectivity, and location — drive your app with values beyond the screen
2 min read
A Service isn't visible UI — it's a source of live values while your app runs. A timer that fires on a schedule, this device's battery and network state, the current location — these come from services.
Service types
- Timer — fires at an interval (once or repeating).
- Battery — battery level and charging state. No permission needed.
- Connectivity — whether the device is online and how (Wi-Fi / cellular). No permission needed.
- Location — the current location (latitude, longitude, altitude, speed, …). Asks for the user's location permission.
A service is either project-wide or owned by one screen. A screen-owned service starts when its screen appears and stops when it disappears.
What happens on fire
Choose what a service does each time it fires.
- Run an Action Flow — runs the Action Flow you pick. The reading is injected as the flow's parameter, ready to use in its actions.
- Data Binding — no Action Flow: fields of the reading are written straight into project data. Labels, maps, and anything bound to that data refresh immediately.
Each service type's reading is described by a read-only built-in schema, referenceable anywhere you work with data.
Starting and stopping
- Auto Start — starts automatically when the app (or the owning screen) starts.
- The Service Start / Service Stop actions turn services on and off from Action Flows.
- A service fires once with its current value the moment it starts, so your first screen is already filled in.
A 1-second repeating Timer + write the current time + a bound Label — three pieces and you have a clock app. Bind the Location service's reading to a Map and the map follows you around.