After 30 seconds (when the capabilities were updated) the call buttons of federated conversations were removed (this was done back then when fed calls were not implemented).
However this happened not always because of the check
"if (this::spreedCapabilities.isInitialized) {...."
It seems this check sometimes is false when it's supposed to be true. This has be to further investigated and has to be be simplified/improved by a cleaner architecture.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The messageInputFragment was hidden by checkShowMessageInputView(), but it was immediately shown again by checkLobbyState()
This fix will execute checkShowMessageInputView() inside checkLobbyState() in the correct order.
Additionally, the check
checkLobbyState()
has to be already executed in
GetCapabilitiesInitialLoadState
as well as
checkShowCallButtons()
Otherwise the expected behavior would only be set after 30 seconds.
An improvemnt for the future must be to improve the capabilities handling.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
With server version 23.0.12 it happened that the chat did not load because values were null. Now default values in json model are set (because that's easier than changing the entity).
Additionally a check was added in CallActivity that a callStartTime of 0 would not be used (but it should not be used anyway if it would be 0 because then capability should also not be available).
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
As build script was not able to push to master, it failed and next time it tried to build the same version again.
Thats why Google complained the apk already exists.
The bot was now changed to have admin permissions. So this commit will bump the version number manually and in the next runs everything should work again.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Otherwise the WebSocket configuration and session clashes with the one
from the CallActivity, which already uses the federated settings.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Starting with Talk 20 the signaling messages that provide updates to the
participants ("participants->update" in the external signaling server,
"usersInRoom" in the internal signaling server) now include "actorType"
and "actorId" properties for each participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "federation" values are used by the external signaling server to
establish a connection with the remote signaling server in a federated
room.
For now this is applied only in calls; when the room is joined in the
chat view again after a call it will still join it in the old way,
without federation properties, which will cause the connection with the
remote signaling server to be closed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Starting with Talk 20 the signaling settings include a "federation"
property that provide the values needed to join a federated room in the
external signaling settings. The "federation" property is specific to
each conversation, and it will be returned although empty for
non-federated conversations.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
add delay between sending of queued messages to increase the chance they are received on server in the correct order. This is not the best solution though as it blocks the UI a bit so may have to be improved!
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Otherwise, it resulted in a lot of flickering because _lastCommonReadFlow was emitted every 500ms. And anyway if we know we are offline or paused then it doesn't make sense to execute the sync method.
chain which caused the flickering was:
updateUiForLastCommonRead (_lastCommonReadFlow) -> updateReadStatusOfAllMessages - notifyDataSetChanged -> onBindViewHolder -> IncomingLinkPreviewMessageViewHolder
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
In dark mode, the call buttons looked like disabled otherwise.
There is still the 3-dots menu next to the call icons like disabled for dark and light mode. But this is a different bug that needs to be fixed in another branch(could not find the reason for now).
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
same for swipeRefreshLayoutView?.isRefreshing
If searchHelper would be null (= when UnifiedSearch is not available) then going back to conversations list view would not trigger to check to show for unread mentions bubble. This fix will make it independent from searchHelper.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
no idea how this happens, however this was
reported via gplay pre launch report for 20.0.0RC1
("Detected on 10 devices during testing"):
Exception java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String com.nextcloud.talk.data.user.model.User.getBaseUrl()' on a null object reference
at com.nextcloud.talk.activities.BaseActivity.startActivity (BaseActivity.kt:240)
at com.nextcloud.talk.account.ServerSelectionActivity.showVisitProvidersInfo$lambda$5 (ServerSelectionActivity.kt:206)
at com.nextcloud.talk.account.ServerSelectionActivity.$r8$lambda$pjpPT-LQbGLSCJPXeRE8IJvpLIE
at com.nextcloud.talk.account.ServerSelectionActivity$$ExternalSyntheticLambda0.onClick (D8$$SyntheticClass)
at android.view.View.performClick (View.java:7506)
at android.view.View.performClickInternal (View.java:7483)
at android.view.View.-$$Nest$mperformClickInternal
at android.view.View$PerformClick.run (View.java:29335)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at androidx.test.espresso.base.Interrogator.loopAndInterrogate (Interrogator.java:10)
at androidx.test.espresso.base.UiControllerImpl.loopUntil (UiControllerImpl.java:7)
at androidx.test.espresso.base.UiControllerImpl.loopUntil (UiControllerImpl.java:1)
at androidx.test.espresso.base.UiControllerImpl.injectMotionEvent (UiControllerImpl.java:5)
at androidx.test.espresso.action.MotionEvents.sendUp (MotionEvents.java:6)
at androidx.test.espresso.action.MotionEvents.sendUp (MotionEvents.java:1)
at androidx.test.espresso.action.Tap.sendSingleTap (Tap.java:5)
at androidx.test.espresso.action.Tap.-$$Nest$smsendSingleTap
at androidx.test.espresso.action.Tap$1.sendTap (Tap.java:1)
at androidx.test.espresso.action.GeneralClickAction.perform (GeneralClickAction.java:4)
at androidx.test.espresso.ViewInteraction$SingleExecutionViewAction.perform (ViewInteraction.java:2)
at androidx.test.espresso.ViewInteraction.doPerform (ViewInteraction.java:23)
at androidx.test.espresso.ViewInteraction.-$$Nest$mdoPerform
at androidx.test.espresso.ViewInteraction$1.call (ViewInteraction.java:6)
at androidx.test.espresso.ViewInteraction$1.call (ViewInteraction.java:1)
at java.util.concurrent.FutureTask.run (FutureTask.java:264)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:201)
at android.os.Looper.loop (Looper.java:288)
at android.app.ActivityThread.main (ActivityThread.java:7898)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:936)
If baseUrl is really missing this may lead to followup issues, however this maybe only 'happens' in gplay pre launch report without any real world scenario. A best solution may be to make baseUrl not nullable, but don't want to do this on short term before release..
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
