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.