RealtimeController controls aspects meetings concerning realtime UX
that for performance, privacy, or other reasons should be implemented using
the most direct path. Callbacks generated by this interface should be
consumed synchronously and without business logic dependent on the UI state
where possible. All methods are prefixed with
realtime to make it easier to
perform audits of realtime control paths.
For an example involving performance implications, consider that volume indicator state is received for each attendee multiple times a second. The handler that receives WebSocket messages derives which indicators have updated and passes that information synchronously through the RealtimeController, which in turn provides the consumer of the volume indicator callbacks an opportunity to immediately render the information to the UI.
For an example involving privacy implications, consider that a mute button must accurately represent the mute state as otherwise a user may think they are muted when they are not. Creating a direct path from the mute button to the place where the underlying media stream is disabled ensures that muting is instantaneous and cannot fail.
When you are done using a
RealtimeController, you should perform some
cleanup steps in order to avoid memory leaks:
Returns whether the user can unmute.
Returns whether the current user is muted.
Mutes the audio input. If there is an active audio input, then a volume indicator update is also sent with the mute status for the current attendee id. It then synchronously notifies the callbacks if mute state changed. This mute is local and overrides any remote unmuted state received for the same attendee id.
Trigger callbacks when receiving a message from data channel
Send message via data channel
Sets whether the user will be able to mute and then synchronously fires the callbacks if can-mute state changed.
Sets the audio input and stores the current mute state. Any previous media stream is first muted before it is replaced.
Subscribes to changes in attendee ids in order to discover attendee ids to subscribe and unsubscribe to for volume indicator updates.
Subscribes to receive a callback when a fatal error is generated while processing an action. Receiving this callback potentially means that it was not possible to successfully mute, and so should be handled by tearing down the current connection and starting over.
Subscribes to changes in local signal strength
Subscribes to local audio mutes and unmutes
Subscribe to local send message event
Subscribes to the changes to the can unmute local audio state.
Subscribes to volume indicator changes for a specific attendee id with a callback. Volume is between 0.0 (min volume) and 1.0 (max volume). Signal strength can be 0 (no signal), 0.5 (weak signal), or 1 (good signal). A null value for any field means that it has not changed.
Unmutes the audio input if currently allowed. If there is an active audio input, then a volume indicator update is also sent with the mute status for the current attendee id. It then synchronously notifies the callbacks if mute state changed. This unmute is local and overrides any remote muted state received for the same attendee id.
Unsubscribe from a message topic
Unsubscribe from local send message event
Unsubscribes to volume indicator changes for a specific attendee id. Optionally, you can pass a callback parameter to unsubscribe from a specific callback. Otherwise, all callbacks will be unsubscribed (e.g. activeSpeaker).
Unsubscribes to changes in attendee ids
Unsubscribes to changes in local signal strength
Unsubscribes to local audio mutes and unmutes
Unsubscribes to the changes to the can unmute local audio state.
Generated using TypeDoc