request maximum_file_preview_size instead hardcoded 100px for file previews
but somehow this his no effect because many file previews are not found on sermo?!
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this is done because in a next step this logic should also be used by the SharedItemsAdapter
extracting is not yet done in a clean way. in a next step some better architecture patterns must be used to separate layers
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Via the conversation info or the menu entry in the conversation menu a
overview of shared items can be opened.
Signed-off-by: Tim Krüger <t@timkrueger.me>
The call flags describe the streams provided by the client, so in a
video call both audio and video are provided, not just video.
Note that as publishing permissions are currently not implemented in the
Android app the provided flags do not take into account the available
permissions. Nevertheless, the server restricts the flags based on the
permissions, so the other participants would see the appropriate flags.
In the future it would be better to send the right flags directly from
the Android app.
Similarly, for now, it is just assumed that both audio and video tracks
will be provided by the Android app, but the flags should reflect the
actually available tracks (for example, if it was not possible to get a
video track for some reason the call flags should not include
"WITH_VIDEO").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The toggleEmojiPopup method is a hacky workaround to avoid bug #1914
As the bug happens only for the very first time when the popup is opened,
it is closed after some milliseconds and opened again.
200 milliseconds seems to be a good value to initialize the popup correctly with the desired size
downside: there is even some flickering when opening the "more emojis" window
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The Android app creates a connection with a participant when that
participant joins the call and ends it when the participant leaves the
call. However, it also created a connection when any signaling message
was received from a participant that had no connection yet. Due to this
if a signaling message was received from a participant before that
participant was in the call the Android app tried to establish a
connection too soon, which would be rejected by the HPB.
Similarly, if a signaling message was received from a participant after
that participant left the call a connection will try to be established.
That would fail, but the connection object was not removed, and if that
participant joined the call again no connection would be established, as
a connection for that participant was already found, even if it was not
usable.
To solve that now a connection is created when a signaling message is
received only if that message is an offer (which is necessary without
HPB if the other participant sends the offer before this participant
"noticed" that she is in the call); otherwise the message is ignored.
Besides that a connection will no longer be created either when setting
up the video stream. However, this would be just for correctness and it
should not make any difference, as the MediaStreamEvents that cause that
are only emitted by changes in peer connections, so they should be
already created.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
