Now that the event is posted only for proximity sensor changes the
condition is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Proximity sensor events should not have been part of
PeerConnectionEvent. However, now that all the peer connection related
properties were removed the remaining event can be renamed to something
more accurate.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The observer is just an adapter for the "PeerConnection.Observer"
provided by the WebRTC library; a custom observer is used to expose only
the events needed outside "PeerConnectionWrapper".
For now only the same events that were already handled are taken into
account, but at a later point additional events (like "onAddTrack"
instead of "onAddStream", which is deprecated) could be added too.
Note that the thread used to handle the events has changed; the EventBus
subscriber mode was "MAIN", but as the events were posted from a
PeerConnection observer, which run in a worker thread rather than in the
main thread, the subscriber was executed in the main thread rather than
in the same thread as the poster. Due to this the actions performed by
the handler now must be explicitly run in the main thread.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than simplifying the states to "CONNECTED" and "DISCONNECTED" now
the raw state is posted, and the handler then decides how to treat them
(which, for now, is exactly as before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than emitting PUBLISHER_FAILED when the publisher connection
fails now PEER_FAILED is emitted when any connection fails, and the
handler checks if the connection was the publisher one to apply the
specific behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The publisher peer connection when the HPB is used is a sender only
connection, so it never adds or removes a remote stream.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The MediaStreamEvent was posted when the connection with the remote peer
was established. However, the MediaStream is added earlier (as soon as
the remote description is received), so the event is moved to better
reflect that.
Note that checking if the connection is an MCU publisher is no longer
needed, as publisher connections are sender only and therefore no remote
stream is added for publisher connections.
In any case, note that the stream will not start until the connection is
established, and a progress bar will be anyway shown on the
ParticipantDisplayItem until it is connected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The user ID set when creating the ParticipantDisplayItem was got from
the join event when the external signaling server was used, and from an
API call when the internal signaling server was used. However, the user
ID is already known from the signaling message that updates the
participant list, and is the one set on the ParticipantDisplayItems
when a participant joins the call. Therefore the other sources are not
needed, so now it is unified to always use the value from the signaling
message.
Note that in the rare cases in which a ParticipantDisplayItem is created
before the participant is seen as in the call the user ID will be
temporary unknown, although it will be automatically fixed once the
participant list update is received. Moreover, even if the other sources
were used it was not guaranteed that the user ID was known, so this
should not be a problem.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The ParticipantDisplayItem for "video" was created when a participant
joined the room, but the item for "screen" was created when the stream
for the screen was connected. Due to this the item for the remote screen
share just "popped up" once connected, but there was no hint of a
connection being established, like done with the video streams.
Now the ParticipantDisplayItems are created as soon as a
PeerConnectionWrapper is created and then updated as needed (for example
to set the user ID or the stream), which causes the item to immediately
appear and a progress bar to be shown until the connection is
established.
Although the ParticipantDisplayItem may be created on a different thread
(the main thread) than the PeerConnectionWrapper "runOnUiThread"
executes the enqueued messages in order (and it also establishes a
"happens-before" relation with further calls of "runOnUiThread" due to
the internal use of synchronized blocks, although it is not explicitly
documented), so the item will be already created when later updated.
This also holds true when an offer is received even before the
participant is seen as joined (a very rare case that can happen if the
signaling message with the updated participant list is lost for any
reason); the ParticipantDisplayItem is created when the offer is
received and it is later updated with the user ID once a new signaling
message with the updated participant list is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of creating a new ParticipantDisplayItem from scratch, which
resets the full grid, now the existing one is updated; a new one is
created only if no item existed already for the session and video stream
type of the media event.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The nick was displayed when updated through a data channel message, or
when a ParticipantDisplayItem was created and the nick was already
received. However, when the HPB is not used the nick is not sent after a
connection is established, as it was sent already in the offer or
answer. The nick from the offer or answer has not been received yet when
the ParticipantDisplayItem is initially created, so the nick only
appeared because a new ParticipantDisplayItem is created again when the
connection is finally established. Due to all that the displayed nick is
now updated as soon as it is received in an offer or answer, which
ensures that the nick is shown independently of when was the
ParticipantDisplayItem created.
Note that this only applies to non-HPB scenarios; when the HPB is used
the nick is got from the participant list update sent through signaling
messages, so it is already known when creating the display item (in some
very strange cases it might happen that an offer is received before the
participant list was updated, but this should not happen, and in any
case it will be handled at a later point).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same data channel messages that were already handled
are taken into account, but at a later point the missing messages
("speaking" and "stoppedSpeaking") could be added too.
Note that the thread used to handle the data channel messages has
changed; the EventBus subscriber mode was "MAIN", but as the messages
were posted from a DataChannel observer, which run in a worker thread
rather than in the main thread, the subscriber was executed in the main
thread rather than in the same thread as the poster. Due to this the
actions performed by the handler now must be explicitly run in the main
thread.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the call is a voice only call there will be no received video tracks
(they would have been stopped when each connection is established), so
changing the enabled state has no effect (as the adapter only tries to
show the received video if it is available).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the display name is not known whether "Guest" or something else needs
to be shown is not a responsibility of the web socket, so now an empty
string is returned instead.
In practice this should not make any difference, though, as the display
name of users is always known as soon as the user joined, and if the
nick of a guest is not known the UI will set it to "Guest".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
