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>
