# Send start/stop typing
Send "Typing" every 10 sec when there was a change
Send stop typing:
- when input is deleted
- when there was no input during the 10s timer
- when on leaving room
# Receive start/stop typing
Clear typing for participant after 15s if no start typing-message was received.
Use userId instead sessionId to manage typing participants. This ensures participants are not shown multiple times when using multiple devices with the same user (multisession). To get the userId via websocket, SignalingMessageReceiver and WebSocketInstance had to be modified to pass the CallWebSocketMessage in case the signalingMessage.type is related to typing. Not sure if this is the best solution but didn't find any other way.
Typing is not handled when the userId is of the own user (this could happen when using multiple devices)
In case userId is null (which happens for guests), their sessionId is used as key for the typingParticipants map.
# Other
Disable setting for typing indicator when no HPB is used + Avoid crash in chat when no HPB is used.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Fields should be declared at the top of the class, before any method declarations, constructors, initializers or inner classes.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Like done with SignalingMessageReceiver, an implementation specific to
each signaling server type (internal or external) is added.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same participant list messages that were already
handled are taken into account, but at a later point further messages,
like participants joining or leaving the conversation, could be added
too.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Although "unshareScreen" is technically bound to a specific peer
connection it is instead treated as a general message on the call
participant.
Nevertheless, call participant messages will make possible (at a later
point) to listen to events like "raise hand" or "mute" (which, again,
could be technically bound to a specific peer connection, but at least
for now are treated as a general message on the call participant).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Unlike the WebRtcMessageListener, which is bound to a specific peer
connection, an OfferMessageListener listens to all offer messages, no
matter which peer connection they are bound to. This can be used, for
example, to create a new peer connection when a remote offer for which
there is no previous connection is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only WebRTC messages can be listened to, although it will be
extended with other kinds later.
This commit only introduces the base class, although it is not used yet
anywhere; a concrete implementation will be added in a following commit.
The test class is named "SignalingMessageReceiverWebRtcTest" rather than
just "SignalingMessageReceiverTest" to have smaller, more manageable
test classes for each listener kind rather than one large test class for
all of them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
