how to test:
1. click on file with big file size that was not clicked before (so it's not in the cache)
2. leave media tab view or just select other tab.
3. go back to the clicked file
4. --> see that progress bar is still spinning (otherwise it's already finished and a click should oen the file directly without showing the progress bar)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
when starting media tab from conversation info, the back button opened media tab again. to fix this FLAG_ACTIVITY_CLEAR_TOP was set as flag
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
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>
