SuuntoPlus uiView lifecycle — subscription behaviour

[matram]

The reference manual states “never subscribe in onLoad, since there is no onUnload” and “subscriptions are unsubscribed automatically after view is deactivated”. It also documents onDeactivate and the $.unsubscribe() token pattern.

What the manual does not explain is: which events trigger deactivation (lap and auto-lap overlays do), that the Zapp output channel is also severed, what the silent failure looks like in practice, or how to diagnose it. The findings below describe the practical implications of the documented rule.

Struggling with understanding this I did some systematic testing. The findings are below

Lifecycle overview

Event	When it fires	Fires how many times
onLoad	When the uiView is first shown	Once per exercise session
onActivate	Each time the view becomes the active screen	Repeatedly — on first show, and again after any overlay or screen switch

Overlays that trigger a new onActivate: manual lap, auto-lap, and likely other system overlays.

What survives across multiple onActivate calls

Thing	Survives?
Variables declared in onLoad	Yes — persist for the full session
$.subscribe() set up in onLoad	No — severed by firmware on second onActivate
$.subscribe() set up in onActivate	Effectively yes — old one severed, new one created each time
Zapp output channel (output.X → /Zapp/{zapp_index}/Output/X)	No — also severed on second onActivate
evaluate() in main.js	Yes — unaffected, keeps running throughout

The key insight: the firmware severs all $.subscribe() calls regardless of where they were set up, but since onActivate runs again, subscriptions placed there are automatically re-created.

Recommended pattern

Place data variables in onLoad (they persist) and subscriptions in onActivate (they are re-created on each activation).

onActivate = "
  // Subscriptions here — re-created on every activation
  $.subscribe('/Dev/Time/Tick10hz', function() {
    // render / refresh canvases
  })

  $.subscribe('/Activity/Move/-1/HeartRate/Current', function(v) {
    // access variables declared in onLoad — they persist
    if (isFinite(v) && v > 0) {
      hrRecord[hrTickCount] = Math.floor(v * 60);
      hrTickCount++;
    }
  })
  "

onLoad="
  // Data variables here — survive the full session
  var hrRecord = new Uint8Array(3800);
  var hrTickCount = 0;
  // ...
  "

Do not subscribe to Zapp outputs (/Zapp/{zapp_index}/Output/Name) for data that must survive lap overlays — the output channel is severed along with the subscription.

How this was verified

systemEvent() was used to log lifecycle events with sequential counters:

// In onLoad:
loadCount++;
systemEvent('onLoad #' + loadCount);   // should always be #1

// In onActivate:
activateCount++;
systemEvent('onActivate #' + activateCount);  // increments on each overlay

// In subscription callback:
systemEvent('hrTick=' + hrTickCount);   // stops if subscription was severed

After a lap overlay the log showed onActivate #2 followed by no further hrTick entries — confirming the subscription was severed. Moving the subscription to onActivate resolved it: hrTick entries continued uninterrupted through all subsequent laps.

Hopes this helps provide some additional information around this topic.