chore: Adding spec for existing Lifecycle APIs #166
Conversation
| ## 2. Lifecycle States | ||
|
|
||
| Firebolt platforms **MUST** support running one or more apps | ||
| concurrently. The platform **MUST** manage transition of apps from state |
There was a problem hiding this comment.
From this sentence, it is not clear if running multiple apps concurrently is a must. "Firebolt platforms MUST support running at least one application. They MAY support running multiple apps concurrently." - would be more clear.
| *Unloading* an app refers to the process of notifying an app to do any | ||
| needed clean up, and then *terminating* it. | ||
|
|
||
| *Terminating* an app refers to shutting down the app's container and |
There was a problem hiding this comment.
Backgrounding Suspending Unsuspending are missing in this Overview section to complete the whole picture.
|
|
||
| | | CPU | Active | Visible | RCU | AV | Description | | ||
| |-----------|-------|-------|-------|-------|-------|---------------------------| | ||
| | Initializing | ✔ | | | | | App is preparing to be minimally usable. | |
There was a problem hiding this comment.
"minimally usable" is confusing. When an app is in an "Inactive" state is it 'minimally usable'? Since it is not shown to the user, it doesn't receive RCUs events, and doesn't use AV - it is not usable, maybe 'operational' is the better term?
| | Inactive | ✔ | | | | | App is ready for use, but not part of the user experience. | | ||
| | Foreground | ✔ | ✔ | ✔ | ✔ | ✔ | App is the primary user experience. | | ||
| | Background | ✔ | ✔ | ✔\* | ✔\* | ✔ | App is a secondary user experience, e.g. covered by a system modal. | | ||
| | Unloading | ✔ | | | | | App will be unloaded soon. | |
There was a problem hiding this comment.
According to the diagram, the state is called "Unloaded" and it denotes the 'Unloading' process has finished.
| A Firebolt app, once running, **MAY** be in one of several states and | ||
| **MUST NOT** be in more than one state at a time. | ||
|
|
||
| | | CPU | Active | Visible | RCU | AV | Description | |
There was a problem hiding this comment.
What is the definition of 'Active'? If the app uses CPU it is active somehow.
| This state allows an app to be running, but not in one of the two active | ||
| states, i.e. foreground and background. Inactive apps can execute code, | ||
| but are not visible, do not receive any input from RCUs, and cannot use | ||
| the video decoder. Apps should free up memory and other resources in |
There was a problem hiding this comment.
Consider changing this sentence to "cannot use the audio-video decoder"
| app has registered its implementation of the | ||
| Lifecycle.ResourceDeallocator interface, then the platform **MUST** call | ||
| the apps ResourceDeallocator.unload method via the onRequestUnload RPC | ||
| call and wait for either the onUnloadResponse or onUnloadError handshake |
There was a problem hiding this comment.
Chapter "4.7. ResourceDeallocator Interface" does not specify the ResourceDeallocator.unload() method.
Calling ResourceDeallocator during unload is not needed, because already app can release it's resources in its 'unloading state (i.e. after app receives 'unloading' event, before app calls Lifecycle.finished() method).
Perhaps this section can be removed.
| initializing state, then it cannot be closed, and the remainder of this | ||
| section does not need to happen. | ||
|
|
||
| Finally the platform transitions the app to the inactive state. |
There was a problem hiding this comment.
This chapter lacks information ResourceDeallocator.inactive() method call.
| [Discovery](https://comcastcorp.sharepoint.com/:w:/r/sites/hqppa/Shared%20Documents/Global%20App%20Platform/Firebolt/Requirements/Core/Discovery/Discovery%20Requirements.docx?d=w81397bb577d149b995636834c4c3a302&csf=1&web=1&e=bdLI4q) | ||
| in [Core | ||
| Requirements](https://comcastcorp.sharepoint.com/:f:/r/sites/hqppa/Shared%20Documents/Global%20App%20Platform/Firebolt/Requirements/Core/Discovery?csf=1&web=1&e=qtZhFJ). | ||
|
|
There was a problem hiding this comment.
These are the references to internal Comcast documentation, not available to the other parties.
| The Lifecycle.loading() API allows an app to notify the platform that it | ||
| is presenting a custom loading screen and would like to be moved into | ||
| the background state so the user can see the loading screen. This method | ||
| **MUST NOT** be called more than once. |
There was a problem hiding this comment.
It's not clear how long the custom loading screen will be displayed by the app?
i.e. when the platform shall change an app state to 'foreground'?
Shall the platform wait for the Lifecycle.ready() call?
| many decoders are available is a decision for each device based on | ||
| resources. See [Background App | ||
| Requirements](https://comcastcorp.sharepoint.com/:w:/r/sites/hqppa/Shared%20Documents/Global%20App%20Platform/Firebolt/Requirements/Core/Lifecycle/Background%20App%20Requirements.docx?d=w185d9112bcd44376bb0635dad816919b&csf=1&web=1&e=cjmuSJ) | ||
| for more info. |
There was a problem hiding this comment.
There shall be some use cases discussed regarding audio-video decoder management between the foreground and background apps.
The following cases shall be discussed:
- System ui overlying app that uses audio-video decoder.
- Audio player in background (not visible)
How the resource conflicts between foreground and background apps shall be solved:
- shall the foreground app always be prioritized over background app when allocating AV decoders.
- shall the audio playback from background app be stopped when foreground app starts audio playback?
- then when foreground app stops av playback, shall the background playback be resumed?
No description provided.