Skip to content

Display HealthBridge data in UMG

Keep HealthBridge operations outside individual row widgets. Fetch data through a controller, subsystem-aware view model, or owning screen, then pass sanitized display models into UMG.

Screen opens
↓
Show loading state
↓
Initialize or reuse HealthBridgeSubsystem
↓
Check capability and read data
↓
Map SDK records to display models
↓
Render content, empty, permission, or error state

A display model should contain only what the widget needs, such as:

  • Localized title.
  • Formatted date and duration.
  • Optional metric labels.
  • A non-sensitive icon or category.
  • Flags for route, deletion, or retry controls.

Avoid giving every widget raw record IDs, provider payloads, or permission details.

  • Loading: operation is still pending.
  • Content: records are available.
  • Empty: read succeeded with no records.
  • Permission guidance: the feature needs player action.
  • Unsupported: the active provider lacks the capability.
  • Recoverable error: retry or settings action is available.

On iOS, do not label an empty read “No health data exists.” The platform does not reveal every per-type read denial.

Select Tools > HealthBridge > Samples > Create Health Data Review Sample. Its connect panel and Workouts, Heart Rate, Health Data, and Write tabs provide a working reference for subsystem-driven UI.

Use the sample to learn the flow, then create project-owned styles and view models rather than coupling production UI to sample internals.

  • Bind events when the owner becomes active.
  • Remove native delegates when their owner is destroyed.
  • Stop monitoring when the feature no longer needs it.
  • Ignore stale completions after a screen closes.
  • Avoid starting the same read every widget tick or binding.

Do not expose raw record IDs or detailed routes in screenshots, diagnostics, or support UI. Redact health values when a screen can be captured or shared outside the intended player context.