With this implementation the can publish audio & video permission are
set during the creation of the 'CallActivity'. This permissions are
fixed for the complete call. If the permissions are changed by a
moderator the call must be left and joined again.
Resolves: #1783
Signed-off-by: Tim Krüger <t@timkrueger.me>
During the migration from Java to Kotlin this was not done and resulted
in
BundleKeys.INSTANCE.getKEY_CALL_VOICE_ONLY()
instead of
BundleKeys.KEY_CALL_VOICE_ONLY
Signed-off-by: Tim Krüger <t@timkrueger.me>
Now the 'can ignore lobby' permission is respected.
The 'ChatController' has now a property of the type
'ParticipantPermissions' because it's needed multiple times. The
property will be updated in 'ChatController#getRoomInfo' if the
conversation is protected by a lobby.
The function 'Conversation#shouldShowLobby' is removed in this commit.
'Conversation' is a pure model class to hold the plain JSON response.
The logic is moved into the already existing function 'ChatController#shouldShowLobby'.
Resolves: #1783
Signed-off-by: Tim Krüger <t@timkrueger.me>
The GitHub API response contains the base branch in which the changes should
pulled into. This is now extracted with 'jq' from the response.
Also some Shellcheck issues were fixed.
Signed-off-by: Tim Krüger <t@timkrueger.me>
"endPeerConnection()" removes the item from the list, so neither a
for-each loop nor an iterator can be used to traverse the list (as a
"ConcurrentModificationException" would be thrown). To solve that now
the list of connections is first traversed to get all the sessions, and
then the list of sessions is traversed to end the connections.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call activity unregisters from the event bus events when stopped.
However, when the call activity is being closed the new activity can
start before the call activity is stopped; if the new activity causes
new signaling messages to be sent those messages were handled by the
call activity too.
The chat controller joins the conversation again when it is attached,
and the call activity automatically joins the call when it receives a
"roomJoined" event. Due to all that, when the call activity was closed
and the chat controller was opened the call was joined again (and then
left once the call activity was finally destroyed).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the local participant leaves the call the participant list will be
updated with the new call flags. However, that does not necessarily mean
that a moderator ended the call; the call could have been left too by
the Android app due to a forced reconnection or a time out when starting
the call. In those cases the call activity should be kept open, and only
when the local participant left the call due to a remote action the call
activity should be closed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the view is shutting down the call is always left, so the status
should be accordingly set.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the HPB is used and the publisher fails (which is a disconnection
that can not be automatically solved by itself) a forced reconnection is
triggered. This restarts the call, so some feedback should be provided
in the UI about it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the participants that are not connected yet are clearly marked as
such now the participants are shown as soon as they are found rather
than waiting for a connection to be established.
There is a drawback, however; if a participant will never have a
connection (for example, if the HPB is used and that participant does
not have publishing permissions) the participant will be endlessly shown
with the progress bar. Nevertheless, before they were not shown at all,
which was probably even more puzzling.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that this still notifies a data set change if the properties are
set to the same value that they had already, but at least it is not
notified when no data was actually changed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
RTCPeerConnections have several states but, for simplicity, for now the
events posted reflect only if the connection is fully established or
not (which includes both a broken connection or an established
connection that is unstable or being updated), which is enough for a
basic information about the connection state in the UI.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The local stream is set only when the activity is created. However, it
was disposed when hanging up, which happens not only when closing the
activity, but also in cases in which the call activity is kept open and
the participant reconnects to the call (for example, when starting the
call times out), which caused the local stream to freeze. Now the local
stream is disposed only when the call activity is destroyed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The call state uses a RelativeLayout with a wrap content height where
the state icons (including the progress bar) position was set as above
the message. However, this caused the call state to wrap only the text;
the icons were indeed above the message, but out of the view boundaries.
Now the icons are wrapped in a FrameLayout and the text position is set
below that frame layout instead, which causes the RelativeLayout height
to correctly wrap its content.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
