As it stands, code and callbacks to an initialized SSAPP can linger because of insufficient sanitation when the SSAPP is closed.
There are two cases where these issues are triggered: closing the SSAPP from the "x" and when the SSAPP closes itself.
The first case has no workaround. Second case can be worked around by the SSAPP developer for most part by closing all callbacks and behaviours it initialized.
A key example of how this can be a problem:
User opens SSAPP
SSAPP activates camera torch
User closes SSAPP from "x"
SSAPP camera torch remains active along with any other registered callbacks or initiated camera processes
Solution:
Implement "onDismounted" callback that gets called by the EPI core application when "x" is pressed or the SSAPP window is closed in any way.
As it stands, code and callbacks to an initialized SSAPP can linger because of insufficient sanitation when the SSAPP is closed.
There are two cases where these issues are triggered: closing the SSAPP from the "x" and when the SSAPP closes itself.
The first case has no workaround. Second case can be worked around by the SSAPP developer for most part by closing all callbacks and behaviours it initialized.
A key example of how this can be a problem:
Solution: Implement "onDismounted" callback that gets called by the EPI core application when "x" is pressed or the SSAPP window is closed in any way.
It should be possible to send messages downstream even though the SSAPP is technically an iFrame mount. https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
It would be up to the SSAPP developer to implement a receiver for this.