The ParticipantDisplayItems were created and destroyed based on the peer
connections. Now a ParticipantDisplayItem of "video" type is associated
to a call participant, while an additional item is created and destroyed
depending on the state of the screen peer connection of the call
participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The listeners for call participant messages and for the call participant
nick provided by offers / answers were created and destroyed based on
the peer connections, although they were implicitly associated to a call
participant. Now they are explicitly created and destroyed based on its
associated call participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
CallParticipant provides a read-only CallParticipantModel and internally
handles the data channel and peer connection events that modify the
model. Nevertheless, the CallParticipant requires certain properties to
be externally set, like the userId or the peer connections.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of explicitly setting the values on the ParticipantDisplayItems
now the values are set on the CallParticipantModels, and the items are
automatically updated from their model when they change.
Different items are still used for the audio/video and screen shares of
the same participant, so the type is used to select from which
properties of the model is the item updated.
As the model may be updated from background threads it is explicitly
observed by the items from the main thread using a Handler shared by all
the items.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Clients that modify the model would define the variables using the
mutable subclass, while clients that only need to access the model are
expected to use the read-only base class.
The read-only class provides an observer; as it is expected that the
model will be modified from background threads but observed from the
main thread the observer can be registered along a handler to be
notified on its thread, independently of on which thread the values were
set.
Currently there does not seem to be a need to observe each value on its
own, so the observer is notified in a coarse way when any value changes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of explicitly calling "notifyDataSetChanged" after setting
values on a ParticipantDisplayItem now the adapter observes all its
items and calls "notifyDataSetChanged" automatically when any of them
changes.
Although this adds some boilerplate code it will make possible to update
the ParticipantDisplayItems and automatically propagate the changes to
the adapter when a model changes, rather than having to explicitly do it
from the CallActivity.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Generic final attributes first, followed by object specific final
attributes and then other object attributes.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the session ID, user ID and the stream type attributes are
still kept, as they can be useful to identify the instance when
debugging.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than just providing a coarse "connected" or "not connected" value
now the views receive the raw ICE connection state. Combined with other
properties this will make possible to show a finer grained status (like
done in the WebUI), although for now just "connected" or "not connected"
is still shown as before.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
