Closed espinr closed 1 year ago
@espinr Thanks for the comparison analysis
Open for discussion: which way we prefer?
In the case of quick apps, there is a specific destroy
event whose handler can be used to clean up connections and notify the system that this app is no longer available. For instance, it is used for unsubscribing to system messages (that can be received from other apps).
Perhaps we can implement a destroy
or unload
(as included in the page lifecycle) status. This event would mark the end of the session, and the removal of all the temporary resources from the cache. This state is already mentioned in the explainer.
I also understand that most MiniApp user agents perform this removal once the platform meets some criteria (inactivity and/or allocation of resources in the background). The criteria may vary depending on the implementations, so we could specify that the platform SHOULD/MUST terminate the app's execution based on these criteria (to be determined by the concrete implementation).
During the privacy review, we are asked to clarify the concept of a mini app "session". Since the answer is related to the lifecycle, I wonder how we can define a session regarding app statuses and events.
The concept of a session I'm referring to is the period starting when the app is loaded (after initialization) and finishing when it is destroyed (cache information is removed).
I did a comparison among the different mini app vendors at w3c/miniapp-manifest#56 .
Could we specify anything to clarify when a app is unloaded?