following lines for ChatActivity were removed:
android:launchMode="singleInstance"
android:noHistory="true"
this solves:
- share files from local storage broken
- broken transitions (caused by "singleInstance")
- fix to open chat when navigating back from conversation info
- fix weird mixed conversations when opening a conversation by notification while being in another conversation
launchMode="singleInstance" was introduced when reimplementing breakout rooms for the conductor to activity migration. So for now this reverting might introduce problems for breakout rooms.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Although listening from the signaling was working fine and this
unfortunately adds a lot of extra code it is conceptually "more
correct", as the UI should not directly deal with the signaling if there
is a higher abstraction available. Nevertheless, this should ease adding
other similar changes, like reactions.
Note that although there were already listeners for
CallParticipantModel.Observer in the CallActivity they were not reused,
as they handle totally unrelated things.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The CallParticipantModel observer now also emits one-time events that
are not reflected in the model state.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
hide delete option from conversation info edit view if no custom avatar is set
remove themed avatars (This is the price of being able to have emoji avatars)
fix dark mode url
remove avatarVersion from url if it's null
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Since most controllers were replaced by activities, the screen locking was temporarily broken. This commit fixes the screen locking to also work with the activities.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
only show users avatars.
conversation avatars were removed again for now, because this would need more work to add custom view to the supportActionBar in order to show themed drawables.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
otherwise:
E FATAL EXCEPTION: main
Process: com.nextcloud.talk2, PID: 13169
io.reactivex.exceptions.UndeliverableException: The exception could not be delivered to the consumer because it has already canceled/disposed the flow or the exception has nowhere to go to begin with. Further reading: https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling | kotlin.UninitializedPropertyAccessException: lateinit property optionsMenu has not been initialized
at io.reactivex.plugins.RxJavaPlugins.onError(RxJavaPlugins.java:367)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:126)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8757)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
Caused by: kotlin.UninitializedPropertyAccessException: lateinit property optionsMenu has not been initialized
at com.nextcloud.talk.conversation.info.ConversationInfoActivity.showOptionsMenu(ConversationInfoActivity.kt:214)
at com.nextcloud.talk.conversation.info.ConversationInfoActivity$fetchRoomInfo$1.onNext(ConversationInfoActivity.kt:670)
at com.nextcloud.talk.conversation.info.ConversationInfoActivity$fetchRoomInfo$1.onNext(ConversationInfoActivity.kt:652)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:124)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8757)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this looks smoother when loading the avatars (less flickering)
"error" and "fallback" take over if something goes wrong.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Placeholder avatars now also come from the server. This means themed avatars from the android app itself are no longer used here. The static placeholder icons defined in loadConversationAvatar are only used when the http request fails completely.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Placeholder avatars now also come from the server. This means themed avatars from the android app itself are no longer used here. The static placeholder icons defined in loadConversationAvatar are only used when the http request fails completely.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Problem:
i want to load avatars and if no avatar is received, i want to show the placeholder.
However with coil it's not possible to make the placeholders rounded. See https://github.com/coil-kt/coil/issues/37
I could just set the old rounded drawables that we have, but then theming wouldn't work!
So i ask myself what the best solution could be:
- Somehow check beforehand if an avatar is set at all? and then choose between loading the avatar or loading the the static drawables in their own loading request.
- Somehow check if the avatar response is empty. And if yes, make another request to load the static drawables.
- Use jetpack compose instead of coil to clip the image? See https://stackoverflow.com/questions/66014834/how-to-draw-a-circular-image-in-android-jetpack-compose
- create new svg's? Somehow it should be possible to invert a circle and just overlay it over an image..?
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Because of "supported-reactions" and "predefined-backgrounds" the capabilities cannot be parsed with
`var config: HashMap<String, HashMap<String, String>>?`
As a result it was not possible to login into the app.
This is now
`var config: HashMap<String, HashMap<String, @RawValue @Contextual Any>>?` while always checking for the type when accessing the values.
"supported-reactions" and "predefined-backgrounds" are not handled yet.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
for now the message is shown empty. should be improved!
D/AndroidRuntime: Shutting down VM
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.nextcloud.talk2, PID: 29567
java.lang.NullPointerException
at com.nextcloud.talk.models.json.chat.ChatMessage.getText(ChatMessage.kt:264)
at com.nextcloud.talk.adapters.messages.OutcomingTextMessageViewHolder.processParentMessage(OutcomingTextMessageViewHolder.kt:168)
at com.nextcloud.talk.adapters.messages.OutcomingTextMessageViewHolder.onBind(OutcomingTextMessageViewHolder.kt:100)
at com.nextcloud.talk.adapters.messages.OutcomingTextMessageViewHolder.onBind(OutcomingTextMessageViewHolder.kt:54)
at com.stfalcon.chatkit.messages.MessageHolders.bind(MessageHolders.java:596)
at com.stfalcon.chatkit.messages.MessagesListAdapter.onBindViewHolder(MessagesListAdapter.java:110)
at com.nextcloud.talk.adapters.messages.TalkMessagesListAdapter.onBindViewHolder(TalkMessagesListAdapter.java:50)
at com.nextcloud.talk.adapters.messages.TalkMessagesListAdapter.onBindViewHolder(TalkMessagesListAdapter.java:32)
at androidx.recyclerview.widget.RecyclerView$Adapter.onBindViewHolder(RecyclerView.java:7678)
at androidx.recyclerview.widget.RecyclerView$Adapter.bindViewHolder(RecyclerView.java:7761)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryBindViewHolderByDeadline(RecyclerView.java:6582)
at androidx.recyclerview.widget.RecyclerView$Recycler.tryGetViewHolderForPositionByDeadline(RecyclerView.java:6848)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6688)
at androidx.recyclerview.widget.RecyclerView$Recycler.getViewForPosition(RecyclerView.java:6684)
at androidx.recyclerview.widget.LinearLayoutManager$LayoutState.next(LinearLayoutManager.java:2362)
at androidx.recyclerview.widget.LinearLayoutManager.layoutChunk(LinearLayoutManager.java:1662)
at androidx.recyclerview.widget.LinearLayoutManager.fill(LinearLayoutManager.java:1622)
at androidx.recyclerview.widget.LinearLayoutManager.scrollBy(LinearLayoutManager.java:1425)
at androidx.recyclerview.widget.LinearLayoutManager.scrollVerticallyBy(LinearLayoutManager.java:1158)
at androidx.recyclerview.widget.RecyclerView.scrollStep(RecyclerView.java:2009)
at androidx.recyclerview.widget.RecyclerView$ViewFlinger.run(RecyclerView.java:5789)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1301)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1309)
at android.view.Choreographer.doCallbacks(Choreographer.java:923)
at android.view.Choreographer.doFrame(Choreographer.java:847)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1283)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8741)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
With this, it's not opened again with onBackPressed in location view. But it still opens again when app was interrupted and being shown again.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ProfileController$save$1.onError (ProfileController.kt:457)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.checkTerminated (ObservableObserveOn.java:281)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal (ObservableObserveOn.java:172)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run (ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run (HandlerScheduler.java:124)
at android.os.Handler.handleCallback (Handler.java:883)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loop (Looper.java:237)
at android.app.ActivityThread.main (ActivityThread.java:8167)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:496)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1100)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController.setupSwipeToReply (ChatController.kt:419)
at com.nextcloud.talk.controllers.ChatController.access$setupSwipeToReply (ChatController.kt:221)
at com.nextcloud.talk.controllers.ChatController$getRoomInfo$1.onNext (ChatController.kt:378)
at com.nextcloud.talk.controllers.ChatController$getRoomInfo$1.onNext (ChatController.kt:362)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal (ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run (ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run (HandlerScheduler.java:124)
at android.os.Handler.handleCallback (Handler.java:883)
at android.os.Handler.dispatchMessage (Handler.java:100)
at android.os.Looper.loop (Looper.java:237)
at android.app.ActivityThread.main (ActivityThread.java:7830)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:492)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1040)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.extensions.ImageViewExtensionsKt.replaceAvatar
at com.nextcloud.talk.utils.DisplayUtils.loadAvatarImage (DisplayUtils.java:465)
at com.nextcloud.talk.controllers.ProfileController$uploadAvatar$1.onNext (ProfileController.kt:645)
at com.nextcloud.talk.controllers.ProfileController$uploadAvatar$1.onNext (ProfileController.kt:639)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal (ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run (ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run (HandlerScheduler.java:124)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Chips with emojis were not shown correctly.
The message with the emoji was not correctly replaced, that's why now the key itself is passed and replaced with the chip instead to replace a text with emoji with a chip.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This change will use the own okHttpClient which also contains the trusted key.
It will avoid the SSLHandshakeException:
E/RealImageLoader: javax.net.ssl.SSLHandshakeException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
at com.google.android.gms.org.conscrypt.ConscryptFileDescriptorSocket.startHandshake(:com.google.android.gms@224915028@22.49.15 (100400-499306216):25)
at okhttp3.internal.connection.RealConnection.connectTls(RealConnection.kt:379)
at okhttp3.internal.connection.RealConnection.establishProtocol(RealConnection.kt:337)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Before this change the initinalization of the trusted key store was
combined in one try-catch-block. If anything went wrong an new in memory
trusted key store was created. Programming against an exception is an
bad pattern.
So the initialization is now splitted into multiple try-catch-blocks
with it's own scopes and the decision if the trusted key store is newly
created in memory or loaded from a exisitng file is done by an if
condition check.
Signed-off-by: Tim Krüger <t@timkrueger.me>
this is already done in onAttach which seems to do the job fine after using workManager queues and fixing to set externalSignalingServer to user.
See commits da1714bb and 29a37086
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This is necessary as many of the workers store user data. When running in parallel, there are race conditions and user data that was stored by one worker gets directly overwritten by the next worker. E.g. this happened with the "externalSignalingServer" attribute of user:
SignalingSettingsWorker saved the user with the externalSignalingServer value, but then
CapabilitiesWorker kicked in and saved the user without this value.
Because of this, in WebsocketConnectionsWorker getExternalSignalingServer() of the user was null.
Because of this, webSocketConnectionHelper.getExternalSignalingInstanceForServer(..) was not called.
So the webSocketInstanceMap in WebSocketConnectionHelper was never filled.
This is why WebSocketConnectionHelper.getMagicWebSocketInstanceForUserId(..) in ChatController failed to get a webSocketInstance.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Without this fix, the call buttons became huge in landscape mode.
The LinearLayout of the callControls now has a fixed width which comes in handy in landscape mode.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
the "historyRead" didn't make any sense to me, and deleting it solved the issue to avoid duplicated messages when the response was HTTP_CODE_NOT_MODIFIED
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The solution was to avoid recursive call off pullChatMessages if lookIntoFuture is false.
However the recursive call has to be made when fetching messages for the first time:
if (isFirstMessagesProcessing || lookIntoFuture) {
pullChatMessages(true,...)
}
For this, setting of isFirstMessagesProcessing had to be moved below this code.
Furthermore in the commit:
add logging & refactoring
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
currentConversation should have already been set, but it makes sense to set it with the most current data of this case.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController.startACall (ChatController.kt:2792)
at com.nextcloud.talk.controllers.ChatController.onOptionsItemSelected (ChatController.kt:2699)
at com.bluelinelabs.conductor.Controller.optionsItemSelected (Controller.java:1399)
at com.bluelinelabs.conductor.Router.onOptionsItemSelected (Router.java:703)
at com.bluelinelabs.conductor.internal.LifecycleHandler.onOptionsItemSelected (LifecycleHandler.java:282)
at android.app.Fragment.performOptionsItemSelected (Fragment.java:2652)
at android.app.FragmentManagerImpl.dispatchOptionsItemSelected (FragmentManager.java:3189)
at android.app.FragmentController.dispatchOptionsItemSelected (FragmentController.java:374)
at android.app.Activity.onMenuItemSelected (Activity.java:4517)
at androidx.activity.ComponentActivity.onMenuItemSelected (ComponentActivity.java:514)
at androidx.fragment.app.FragmentActivity.onMenuItemSelected (FragmentActivity.java:352)
at androidx.appcompat.app.AppCompatActivity.onMenuItemSelected (AppCompatActivity.java:266)
at androidx.appcompat.view.WindowCallbackWrapper.onMenuItemSelected (WindowCallbackWrapper.java:110)
at androidx.appcompat.app.ToolbarActionBar$2.onMenuItemClick (ToolbarActionBar.java:66)
at androidx.appcompat.widget.Toolbar$1.onMenuItemClick (Toolbar.java:221)
at androidx.appcompat.widget.ActionMenuView$MenuBuilderCallback.onMenuItemSelected (ActionMenuView.java:781)
at androidx.appcompat.view.menu.MenuBuilder.dispatchMenuItemSelected (MenuBuilder.java:836)
at androidx.appcompat.view.menu.MenuItemImpl.invoke (MenuItemImpl.java:159)
at androidx.appcompat.view.menu.MenuBuilder.performItemAction (MenuBuilder.java:987)
at androidx.appcompat.view.menu.MenuBuilder.performItemAction (MenuBuilder.java:977)
at androidx.appcompat.widget.ActionMenuView.invokeItem (ActionMenuView.java:625)
at androidx.appcompat.view.menu.ActionMenuItemView.onClick (ActionMenuItemView.java:156)
at android.view.View.performClick (View.java:7881)
at android.widget.TextView.performClick (TextView.java:16203)
at android.view.View.performClickInternal (View.java:7858)
at android.view.View.-$$Nest$mperformClickInternal
at android.view.View$PerformClick.run (View.java:30863)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8772)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController$onViewBound$11.onTouch (ChatController.kt:867)
at android.view.View.dispatchTouchEvent (View.java:15540)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3316)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:2990)
at com.android.internal.policy.DecorView.superDispatchTouchEvent (DecorView.java:1112)
at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent (PhoneWindow.java:1971)
at android.app.Activity.dispatchTouchEvent (Activity.java:4388)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent (WindowCallbackWrapper.java:70)
at com.android.internal.policy.DecorView.dispatchTouchEvent (DecorView.java:1070)
at android.view.View.dispatchPointerEvent (View.java:15803)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent (ViewRootImpl.java:8153)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess (ViewRootImpl.java:7877)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:7213)
at android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:7270)
at android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:7236)
at android.view.ViewRootImpl$AsyncInputStage.forward (ViewRootImpl.java:7434)
at android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:7244)
at android.view.ViewRootImpl$AsyncInputStage.apply (ViewRootImpl.java:7491)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:7217)
at android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:7270)
at android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:7236)
at android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:7244)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:7217)
at android.view.ViewRootImpl.deliverInputEvent (ViewRootImpl.java:10788)
at android.view.ViewRootImpl.doProcessInputEvents (ViewRootImpl.java:10676)
at android.view.ViewRootImpl.enqueueInputEvent (ViewRootImpl.java:10632)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent (ViewRootImpl.java:10926)
at android.view.InputEventReceiver.dispatchInputEvent (InputEventReceiver.java:285)
at android.os.MessageQueue.nativePollOnce
at android.os.MessageQueue.next (MessageQueue.java:335)
at android.os.Looper.loopOnce (Looper.java:186)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8757)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController.processMessagesFromTheFuture (ChatController.kt:2500)
at com.nextcloud.talk.controllers.ChatController.processMessages (ChatController.kt:2443)
at com.nextcloud.talk.controllers.ChatController.processMessagesResponse (ChatController.kt:2404)
at com.nextcloud.talk.controllers.ChatController.access$processMessagesResponse (ChatController.kt:221)
at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext (ChatController.kt:2315)
at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext (ChatController.kt:2300)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal (ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run (ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run (HandlerScheduler.java:124)
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:7872)
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)
I don't know why scrollToPositionWithOffset was used. scrollToPosition(0) works just fine.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When clicking on a conversation in conversation overview, restrict opening immediately.
If joinRoomWithPassword in ChatController is reached in any other way (for example by creating a new conversation while being in a call), then it's restricted to join the room.
All this is done to avoid NPE:
D/ChatController: pullChatMessages - pullChatMessages[lookIntoFuture > 0] - got response
W/System.err: java.lang.NullPointerException
W/System.err: at com.nextcloud.talk.controllers.ChatController.modifyMessageCount(ChatController.kt:2536)
W/System.err: at com.nextcloud.talk.controllers.ChatController.addMessagesToAdapter(ChatController.kt:2515)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessagesFromTheFuture(ChatController.kt:2489)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessages(ChatController.kt:2437)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessagesResponse(ChatController.kt:2398)
W/System.err: at com.nextcloud.talk.controllers.ChatController.access$processMessagesResponse(ChatController.kt:221)
W/System.err: at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext(ChatController.kt:2309)
W/System.err: at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext(ChatController.kt:2294)
W/System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:201)
W/System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255)
W/System.err: at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:124)
W/System.err: at android.os.Handler.handleCallback(Handler.java:883)
W/System.err: at android.os.Handler.dispatchMessage(Handler.java:100)
W/System.err: at android.os.Looper.loop(Looper.java:224)
W/System.err: at android.app.ActivityThread.main(ActivityThread.java:7590)
W/System.err: at java.lang.reflect.Method.invoke(Native Method)
W/System.err: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:539)
W/System.err: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
Known issues:
- doesn't respect handling for other instances. E.g. when receiving notification from other instance and open it.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Fix to always allow opening same room when being in call
Fix to set also other properties for ApplicationWideCurrentRoomHolder when joining room in chat.
Otherwise it could have been possible to not be allowed to open this chat again from conversation list while being in call.
In a next step, ApplicationWideCurrentRoomHolder should be refactored to hold the conversation itself. Maybe in a map of users to handle different instances.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Before it was requested every 5 sec even when not waiting in a lobby.
This is a first improvement to reduce requests. In a next step, more signaling messages should be handled to maybe even avoid recursive calls at all.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
1)
Use session id returned from join room
= introduce sessionIdAfterRoomJoined to make clear this is the session to use instead of currentConversation?.sessionId
See https://nextcloud-talk.readthedocs.io/en/latest/conversation/#get-user-s-conversations :
"'0' if not connected, otherwise an up to 512 character long string that is the identifier of the user's session making the request. Should only be used to pre-check if the user joined already with this session, but this might be outdated by the time of usage, so better check via Get list of participants in a conversation"
2)
Also, trigger getRoomInfo() or handleFromNotification() in onAttach() instead of in onViewBound.
onViewBound is not called when returning back from an other view (e.g. conversation infos) so after this, new messages were not handled.
Furthermore, getRoomInfo()/joinRoomWithPassword() in onViewBound and onAttach were sometimes both called, because the handling of validSessionId was buggy. This resulted in duplicated messages.
3)
Use ApplicationWideCurrentRoomHolder to set sessionId from call and check in ChatController if there is already a session for the room. If yes, use this instead to joinRoom again.
This is necessary for PictureInPicture mode. Otherwise, call would be left whenever ChatController joins room again.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
avoid:
2023-03-01 16:47:40.443 23569-23628 UploadAndS...ilesWorker com.nextcloud.talk2 E Something went wrong when trying to upload file
java.lang.NullPointerException
at com.nextcloud.talk.jobs.UploadAndShareFilesWorker.showFailedToUploadNotification(UploadAndShareFilesWorker.kt:258)
at com.nextcloud.talk.jobs.UploadAndShareFilesWorker.doWork(UploadAndShareFilesWorker.kt:163)
at androidx.work.Worker$1.run(Worker.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
2023-03-01 16:47:40.444 23569-23607 WM-WorkerWrapper com.nextcloud.talk2 E Work [ id=27e4e319-a966-4515-ac07-d6ad7ee68268, tags={ com.nextcloud.talk.jobs.UploadAndShareFilesWorker } ] failed because it threw an exception/error
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at androidx.work.impl.utils.futures.AbstractFuture.getDoneValue(AbstractFuture.java:516)
at androidx.work.impl.utils.futures.AbstractFuture.get(AbstractFuture.java:475)
at androidx.work.impl.WorkerWrapper$2.run(WorkerWrapper.java:311)
at androidx.work.impl.utils.SerialExecutor$Task.run(SerialExecutor.java:91)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
Caused by: java.lang.NullPointerException
at com.nextcloud.talk.jobs.UploadAndShareFilesWorker.showFailedToUploadNotification(UploadAndShareFilesWorker.kt:258)
at com.nextcloud.talk.jobs.UploadAndShareFilesWorker.doWork(UploadAndShareFilesWorker.kt:167)
at androidx.work.Worker$1.run(Worker.java:86)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
2023-03-01 16:47:40.446 23569-23607 WM-WorkerWrapper com.nextcloud.talk2 I Worker result FAILURE for Work [ id=27e4e319-a966-
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
2023-02-27 12:29:00.275 995-995 AndroidRuntime.........
java.lang.NullPointerException
at com.nextcloud.talk.controllers.ChatController.modifyMessageCount(ChatController.kt:2536)
at com.nextcloud.talk.controllers.ChatController.addMessagesToAdapter(ChatController.kt:2515)
at com.nextcloud.talk.controllers.ChatController.processMessagesFromTheFuture(ChatController.kt:2489)
at com.nextcloud.talk.controllers.ChatController.processMessages(ChatController.kt:2437)
at com.nextcloud.talk.controllers.ChatController.processMessagesResponse(ChatController.kt:2398)
at com.nextcloud.talk.controllers.ChatController.access$processMessagesResponse(ChatController.kt:221)
at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext(ChatController.kt:2309)
at com.nextcloud.talk.controllers.ChatController$pullChatMessages$2.onNext(ChatController.kt:2294)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255)
at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:124)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8741)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
...for preparation to replace Dialog that was openend in ChatController. It will be replaced by Notification Actions.
The dialog was not opened when already being in a chat, because remapChatController only moved the currentChatController to top so to won't be initialized again. That's why the dialog didn't pop up for this case.
As a solution, the actions should be available directly inside the notification.
For this, it must be avoided that the "recording available" notification is closed whenever the chat is opened.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
more call recording states are:
3 = Starting video recording
4 = Starting audio recording
5 = Recording failed
these actions were added:
- Show grey recording icon to moderators if recording is starting
- Show toast to moderators if recording failed
- Add system message for recording failed
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this is not working yet. It's for now commented out in order to continue with "request help" feature for breakout rooms.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This commit only sets up the listeners, but the actual handling of the
"switchto" event still needs to be added.
Note that in CallActivity the SignalingMessageReceiver is available both
when using the internal and the external signaling server. On the other
hand, in ChatController it is available only for the external signaling
server. Right now that is not a problem, as the message notified by the
LocalParticipantMessageListener is currently sent only by the external
signaling server, but this may need to be adjusted in the future.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController.startPlayback (ChatController.kt:985)
at com.nextcloud.talk.controllers.ChatController.access$startPlayback (ChatController.kt:219)
at com.nextcloud.talk.controllers.ChatController$downloadFileToCache$1.invoke (ChatController.kt:1130)
at com.nextcloud.talk.controllers.ChatController$downloadFileToCache$1.invoke (ChatController.kt:1128)
at com.nextcloud.talk.controllers.ChatController.downloadFileToCache$lambda$19 (ChatController.kt:1128)
at com.nextcloud.talk.controllers.ChatController.$r8$lambda$oLS0bGL_zLma74VfkfStO_mReb4
at com.nextcloud.talk.controllers.ChatController$$ExternalSyntheticLambda10.onChanged
at androidx.lifecycle.LiveData.considerNotify (LiveData.java:133)
at androidx.lifecycle.LiveData.dispatchingValue (LiveData.java:151)
at androidx.lifecycle.LiveData.setValue (LiveData.java:309)
at androidx.lifecycle.MutableLiveData.setValue (MutableLiveData.java:50)
at androidx.lifecycle.LiveData$1.run (LiveData.java:93)
at android.os.Handler.handleCallback (Handler.java:942)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8775)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1067)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
There are no known bugs that were caused by not setting the active user here, but this should be done.
See fb7ea25b for reference
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When two or more users were setup, the active user was not updated when opening the app from notification. As a result, it was not possible to send files, mention people...
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this shouldn't make a difference. class variable was unused before..
Signed-off-by: Andy Scherzinger <info@andy-scherzinger.de>
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
without this fix following Exception occurred:
I/RealImageLoader: 🚨 Failed - https://sermo.nextcloud.com/index.php/core/preview.png?file=%2F2022-09-12_163513.jpg&x=90&y=90&a=1&mode=cover&forceIcon=1 - coil.network.HttpException: HTTP 401:
E/RealImageLoader: coil.network.HttpException: HTTP 401:
at coil.fetch.HttpUriFetcher.executeNetworkRequest(HttpUriFetcher.kt:227)
at coil.fetch.HttpUriFetcher.access$executeNetworkRequest(HttpUriFetcher.kt:30)
at coil.fetch.HttpUriFetcher$executeNetworkRequest$1.invokeSuspend(Unknown Source:15)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at kotlinx.coroutines.internal.LimitedDispatcher.run(LimitedDispatcher.kt:42)
at kotlinx.coroutines.scheduling.TaskImpl.run(Tasks.kt:95)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:570)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.kt:750)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.kt:677)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.kt:664)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
E/AndroidRuntime: FATAL EXCEPTION: RxCachedThreadScheduler-6
Process: com.nextcloud.talk2, PID: 25086
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean org.webrtc.DataChannel.send(org.webrtc.DataChannel$Buffer)' on a null object reference
at com.nextcloud.talk.webrtc.PeerConnectionWrapper.sendChannelData(PeerConnectionWrapper.java:275)
at com.nextcloud.talk.activities.CallActivity$17.onNext(CallActivity.java:2311)
at com.nextcloud.talk.activities.CallActivity$17.onNext(CallActivity.java:2303)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:201)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255)
at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
at java.util.concurrent.FutureTask.run(FutureTask.java:264)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:558)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:936)
Caused by java.lang.reflect.InvocationTargetException:
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:548)
Caused by java.io.IOException: Prepare failed.: status=0x1
at android.media.MediaPlayer._prepare
at android.media.MediaPlayer.prepare (MediaPlayer.java:1309)
at com.nextcloud.talk.controllers.ChatController.initMediaPlayer (ChatController.kt:1023)
at com.nextcloud.talk.controllers.ChatController.startPlayback (ChatController.kt:981)
at com.nextcloud.talk.controllers.ChatController.access$startPlayback (ChatController.kt:219)
at com.nextcloud.talk.controllers.ChatController$downloadFileToCache$1.invoke (ChatController.kt:1111)
at com.nextcloud.talk.controllers.ChatController$downloadFileToCache$1.invoke (ChatController.kt:1109)
at com.nextcloud.talk.controllers.ChatController.downloadFileToCache$lambda$18 (ChatController.kt:1109)
at com.nextcloud.talk.controllers.ChatController.$r8$lambda$6crsUAwqqfwhlukFd40yEwEwluI
at com.nextcloud.talk.controllers.ChatController$$ExternalSyntheticLambda9.onChanged
at androidx.lifecycle.LiveData.considerNotify (LiveData.java:133)
at androidx.lifecycle.LiveData.dispatchingValue (LiveData.java:151)
at androidx.lifecycle.LiveData.setValue (LiveData.java:309)
at androidx.lifecycle.MutableLiveData.setValue (MutableLiveData.java:50)
at androidx.lifecycle.LiveData$1.run (LiveData.java:93)
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:7872)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This might happen sometimes. For now it's a try-catch instead trying to control the state of the mediaPlayer which could be quite difficult.
this will avoid the following exception:
java.lang.IllegalStateException
at android.media.MediaPlayer.isPlaying(Native Method)
at com.nextcloud.talk.activities.CallActivity.stopCallingSound(CallActivity.java:2640)
at com.nextcloud.talk.activities.CallActivity.lambda$setCallState$31$com-nextcloud-talk-activities-CallActivity(CallActivity.java:2583)
at com.nextcloud.talk.activities.CallActivity$$ExternalSyntheticLambda7.run(Unknown Source:2)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:237)
at android.app.ActivityThread.main(ActivityThread.java:8167)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:496)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1100)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
W/System.err: java.lang.NullPointerException
W/System.err: at com.nextcloud.talk.controllers.ChatController.determinePreviousMessageIds(ChatController.kt:2498)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessagesNotFromTheFuture(ChatController.kt:2463)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessages(ChatController.kt:2355)
W/System.err: at com.nextcloud.talk.controllers.ChatController.processMessagesResponse(ChatController.kt:2314)
W/System.err: at com.nextcloud.talk.controllers.ChatController.access$processMessagesResponse(ChatController.kt:219)
W/System.err: at com.nextcloud.talk.controllers.ChatController$pullChatMessages$3.onNext(ChatController.kt:2260)
W/System.err: at com.nextcloud.talk.controllers.ChatController$pullChatMessages$3.onNext(ChatController.kt:2248)
W/System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.drainNormal(ObservableObserveOn.java:201)
W/System.err: at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.run(ObservableObserveOn.java:255)
W/System.err: at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:124)
W/System.err: at android.os.Handler.handleCallback(Handler.java:883)
W/System.err: at android.os.Handler.dispatchMessage(Handler.java:100)
W/System.err: at android.os.Looper.loop(Looper.java:224)
W/System.err: at android.app.ActivityThread.main(ActivityThread.java:7590)
W/System.err: at java.lang.reflect.Method.invoke(Native Method)
W/System.err: at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:539)
W/System.err: at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
instead popToRoot, which should be the ConversationsListController for most cases.
Exception java.lang.IllegalArgumentException: fromIndex(0) > toIndex(-1)
at java.util.ArrayList.subListRangeCheck (ArrayList.java:1018)
at java.util.ArrayList.subList (ArrayList.java:1008)
at com.nextcloud.talk.controllers.ConversationInfoController.popTwoLastControllers (ConversationInfoController.kt:628)
at com.nextcloud.talk.controllers.ConversationInfoController.leaveConversation (ConversationInfoController.kt:552)
at com.nextcloud.talk.controllers.ConversationInfoController.onAttach$lambda$1 (ConversationInfoController.kt:181)
at com.nextcloud.talk.controllers.ConversationInfoController.$r8$lambda$VRoZoNH5wtuepilLynILWSZOZYA
at com.nextcloud.talk.controllers.ConversationInfoController$$ExternalSyntheticLambda8.onClick
at com.yarolegovich.mp.util.CompositeClickListener.onClick (CompositeClickListener.java:22)
at android.view.View.performClick (View.java:7455)
at android.view.View.performClickInternal (View.java:7428)
at android.view.View.access$3600 (View.java:813)
at android.view.View$PerformClick.run (View.java:28495)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:223)
at android.app.ActivityThread.main (ActivityThread.java:7700)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:612)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:997)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this commit tries to avoid the IllegalStateException in stacktrace below.
I'm not sure how this happened. It came from LockedController#unlock (--> binding?.unlockContainer?.setOnClickListener) which should only be visible when somehow it's "failed" to show the keyguard lockscreen. And somehow for this case the router backstack must have been empty.
Instead to dismiss the current controller, popToRoot() should avoid trying to pop the last remaining controller.
Exception java.lang.IllegalStateException: Trying to pop the current controller when there are none on the backstack.
at com.bluelinelabs.conductor.Router.popCurrentController (Router.java:118)
at com.nextcloud.talk.controllers.LockedController.checkIfWeAreSecure (LockedController.kt:147)
at com.nextcloud.talk.controllers.LockedController.unlock (LockedController.kt:90)
at com.nextcloud.talk.controllers.LockedController.onViewBound$lambda$0 (LockedController.kt:64)
at com.nextcloud.talk.controllers.LockedController.$r8$lambda$sNoJ_x5yMnHnIHeqt2umoDILkpk
at com.nextcloud.talk.controllers.LockedController$$ExternalSyntheticLambda0.onClick
at android.view.View.performClick (View.java:7745)
at android.view.View.performClickInternal (View.java:7722)
at android.view.View.access$3700 (View.java:854)
at android.view.View$PerformClick.run (View.java:29111)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:210)
at android.os.Looper.loop (Looper.java:299)
at android.app.ActivityThread.main (ActivityThread.java:8319)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:556)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1038)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ChatController$onViewBound$11.onTouch (ChatController.kt:858)
at android.view.View.dispatchTouchEvent (View.java:15072)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at android.view.ViewGroup.dispatchTransformedTouchEvent (ViewGroup.java:3923)
at android.view.ViewGroup.dispatchTouchEvent (ViewGroup.java:3597)
at com.android.internal.policy.DecorView.superDispatchTouchEvent (DecorView.java:1016)
at com.android.internal.policy.PhoneWindow.superDispatchTouchEvent (PhoneWindow.java:1962)
at android.app.Activity.dispatchTouchEvent (Activity.java:4265)
at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent (WindowCallbackWrapper.java:70)
at com.android.internal.policy.DecorView.dispatchTouchEvent (DecorView.java:974)
at android.view.View.dispatchPointerEvent (View.java:15335)
at android.view.ViewRootImpl$ViewPostImeInputStage.processPointerEvent (ViewRootImpl.java:7820)
at android.view.ViewRootImpl$ViewPostImeInputStage.onProcess (ViewRootImpl.java:7593)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:6927)
at android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:6984)
at android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:6950)
at android.view.ViewRootImpl$AsyncInputStage.forward (ViewRootImpl.java:7148)
at android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:6958)
at android.view.ViewRootImpl$AsyncInputStage.apply (ViewRootImpl.java:7205)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:6931)
at android.view.ViewRootImpl$InputStage.onDeliverToNext (ViewRootImpl.java:6984)
at android.view.ViewRootImpl$InputStage.forward (ViewRootImpl.java:6950)
at android.view.ViewRootImpl$InputStage.apply (ViewRootImpl.java:6958)
at android.view.ViewRootImpl$InputStage.deliver (ViewRootImpl.java:6931)
at android.view.ViewRootImpl.deliverInputEvent (ViewRootImpl.java:10422)
at android.view.ViewRootImpl.doProcessInputEvents (ViewRootImpl.java:10270)
at android.view.ViewRootImpl.enqueueInputEvent (ViewRootImpl.java:10226)
at android.view.ViewRootImpl$WindowInputEventReceiver.onInputEvent (ViewRootImpl.java:10554)
at android.view.InputEventReceiver.dispatchInputEvent (InputEventReceiver.java:259)
at android.os.MessageQueue.nativePollOnce
at android.os.MessageQueue.next (MessageQueue.java:335)
at android.os.Looper.loopOnce (Looper.java:186)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.RuntimeException:
at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:6032)
at android.app.ActivityThread.handleDestroyActivity (ActivityThread.java:6077)
at android.app.servertransaction.DestroyActivityItem.execute (DestroyActivityItem.java:47)
at android.app.servertransaction.ActivityTransactionItem.execute (ActivityTransactionItem.java:45)
at android.app.servertransaction.TransactionExecutor.executeLifecycleState (TransactionExecutor.java:176)
at android.app.servertransaction.TransactionExecutor.execute (TransactionExecutor.java:97)
at android.app.ActivityThread$H.handleMessage (ActivityThread.java:2443)
at android.os.Handler.dispatchMessage (Handler.java:106)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Caused by java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallActivity.onDestroy (CallActivity.java:1244)
at android.app.Activity.performDestroy (Activity.java:8571)
at android.app.Instrumentation.callActivityOnDestroy (Instrumentation.java:1364)
at android.app.ActivityThread.performDestroyActivity (ActivityThread.java:6019)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Note the slight difference in naming between the signaling message
("raiseHand", the action) and the stored data ("RaisedHand", the record
of the action).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
with this fix it's also not necessary to check for HPB in the app. The "recording" value from capabilities is set accordingly on server side.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
RecordingStartedState is set when the signaling message is received. There is no need to set this by CallStartRecordingObserver. Otherwise the toast "The call is being recorded" would have been shown twice when starting the recording.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
first it was tried with sampling rate 44100 but this showed an error on safari when try to playback.
by direct comparison to 44100, 22050 has lower quality but it's totally okay compared to the quality before when no sampling rate was set. I'm not sure why it failed on safari, because the iOS app also uses 44100.
see https://github.com/nextcloud/talk-android/pull/2714
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
this could happen very rarely when clicking very fast to accept the call before the conversation was set.
Exception java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallNotificationActivity.proceedToCall (CallNotificationActivity.kt:156)
at com.nextcloud.talk.activities.CallNotificationActivity.initClickListeners$lambda$0 (CallNotificationActivity.kt:126)
at com.nextcloud.talk.activities.CallNotificationActivity.$r8$lambda$0cnB_UmYcTD4PyxIBSZCZs1m_6s
at com.nextcloud.talk.activities.CallNotificationActivity$$ExternalSyntheticLambda0.onClick
at android.view.View.performClick (View.java:6612)
at android.view.View.performClickInternal (View.java:6581)
at android.view.View.access$3100 (View.java:785)
at android.view.View$PerformClick.run (View.java:25904)
at android.os.Handler.handleCallback (Handler.java:873)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loop (Looper.java:280)
at android.app.ActivityThread.main (ActivityThread.java:6706)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:858)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Exception java.lang.NullPointerException:
at com.nextcloud.talk.activities.CallActivity.hangupNetworkCalls (CallActivity.java:1749)
at com.nextcloud.talk.activities.CallActivity.hangup (CallActivity.java:1741)
at com.nextcloud.talk.activities.CallActivity.lambda$initClickListeners$8$com-nextcloud-talk-activities-CallActivity (CallActivity.java:465)
at com.nextcloud.talk.activities.CallActivity$$ExternalSyntheticLambda16.onClick
at android.view.View.performClick (View.java:7792)
at android.view.View.performClickInternal (View.java:7769)
at android.view.View.access$3800 (View.java:910)
at android.view.View$PerformClick.run (View.java:30218)
at android.os.Handler.handleCallback (Handler.java:938)
at android.os.Handler.dispatchMessage (Handler.java:99)
at android.os.Looper.loopOnce (Looper.java:226)
at android.os.Looper.loop (Looper.java:313)
at android.app.ActivityThread.main (ActivityThread.java:8751)
at java.lang.reflect.Method.invoke
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:1135)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
When the HPB is not used and a PeerConnectionWrapper is created it
always sent an offer if the local session ID is higher than the remote
session ID. However, in the case of screen shares the participant
sharing the screen always sends an offer, no matter the session ID.
Therefore, when that offer was received the new PeerConnectionWrapper
object sent a new offer, which in turn created an extra connection in
the browser.
Although the screen share connection happens to work the underlying
behaviour was wrong, so now no offer is sent for received screen share
connections and it is always waited until the offer is sent by the other
participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
logic for setting the placeholder was moved to getPayloadForImageLoader.
This is a better solution than in commit
9557bec9 where the onBind method had to be called in between other code.
This is still not the best solution because getPayloadForImageLoader now contains more logic than it should (which is also not only responsible for the placeholder). Anyway as this is a hotfix it's the best solution for the moment.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
follow up to commit 7464e6994b673d2b575903a76752bf39bed9d622
the problem was that the "super" methods also contain logic to show/hide the avatar. So this result must be overwritten again after calling the super method.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
without this fix, "getPayloadForImageLoader" was called before the placeholder was set (so it was null until getPayloadForImageLoader was called again after ~30seconds.). This is fixed by calling the super method at the end of "onBind".
min height was set to avoid very tiny previews (like for the placeholders)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
since null checks are done for the nullable bindings by PR #2694, the try-catch blocks arent necessary anymore.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
it seems async calls are not cancelled reliable so it was decided to always check for null bindings to avoid NPEs
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The peer connections will be of either "video" or "screen" type, so they
can be simply removed based on the session id and an explicit type.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of trying to create a video peer connection for any joined
participant now only a call participant is created for any joined
participant, and a video peer connection is created only for those
participants that are publishing audio or video.
If a call participants does not have a video peer connection the call
participant is now seen as "connected" from the UI, as there is no need
to show a progress bar for that participant.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As CallParticipantList starts listening on the signaling messages as
soon as it is created it needs to be created and destroyed right before
entering and exiting a call. Otherwise it could receive messages on
other states (for example, while the "connection timeout" message is
shown) and thus once the local participant joined the event would not
include the other participants already in the call as joined (although
they would be anyway reported as unchanged).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same signaling messages that were already handled are
still handled; in the future it could be extended to handle other
messages, like the one sent by the external signaling server when a
participant leaves the room (in some cases no participants update
message is sent if the participant leaves the call and room at the same
time, which causes the participants to still be seen as in call until a
new update is received).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The observers were created for any peer connection, but after recent
changes they ignored all changes but those from the self peer
connection. Therefore it is enough to just add an explicit listener on
that peer connection rather than on all of them.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The connection state changes to "closed" only when the connection is
closed. However, closing a connection does not fire any event (not even
the "iceConnectionStateChanged" event), so the event handler can be
removed as it will never be executed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
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>
Now that the event is posted only for proximity sensor changes the
condition is no longer needed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Proximity sensor events should not have been part of
PeerConnectionEvent. However, now that all the peer connection related
properties were removed the remaining event can be renamed to something
more accurate.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The observer is just an adapter for the "PeerConnection.Observer"
provided by the WebRTC library; a custom observer is used to expose only
the events needed outside "PeerConnectionWrapper".
For now only the same events that were already handled are taken into
account, but at a later point additional events (like "onAddTrack"
instead of "onAddStream", which is deprecated) could be added too.
Note that the thread used to handle the events has changed; the EventBus
subscriber mode was "MAIN", but as the events were posted from a
PeerConnection observer, which run in a worker thread rather than in the
main thread, the subscriber was executed in the main thread rather than
in the same thread as the poster. Due to this the actions performed by
the handler now must be explicitly run in the main thread.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than simplifying the states to "CONNECTED" and "DISCONNECTED" now
the raw state is posted, and the handler then decides how to treat them
(which, for now, is exactly as before).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Rather than emitting PUBLISHER_FAILED when the publisher connection
fails now PEER_FAILED is emitted when any connection fails, and the
handler checks if the connection was the publisher one to apply the
specific behaviour.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The publisher peer connection when the HPB is used is a sender only
connection, so it never adds or removes a remote stream.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The MediaStreamEvent was posted when the connection with the remote peer
was established. However, the MediaStream is added earlier (as soon as
the remote description is received), so the event is moved to better
reflect that.
Note that checking if the connection is an MCU publisher is no longer
needed, as publisher connections are sender only and therefore no remote
stream is added for publisher connections.
In any case, note that the stream will not start until the connection is
established, and a progress bar will be anyway shown on the
ParticipantDisplayItem until it is connected.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The user ID set when creating the ParticipantDisplayItem was got from
the join event when the external signaling server was used, and from an
API call when the internal signaling server was used. However, the user
ID is already known from the signaling message that updates the
participant list, and is the one set on the ParticipantDisplayItems
when a participant joins the call. Therefore the other sources are not
needed, so now it is unified to always use the value from the signaling
message.
Note that in the rare cases in which a ParticipantDisplayItem is created
before the participant is seen as in the call the user ID will be
temporary unknown, although it will be automatically fixed once the
participant list update is received. Moreover, even if the other sources
were used it was not guaranteed that the user ID was known, so this
should not be a problem.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The ParticipantDisplayItem for "video" was created when a participant
joined the room, but the item for "screen" was created when the stream
for the screen was connected. Due to this the item for the remote screen
share just "popped up" once connected, but there was no hint of a
connection being established, like done with the video streams.
Now the ParticipantDisplayItems are created as soon as a
PeerConnectionWrapper is created and then updated as needed (for example
to set the user ID or the stream), which causes the item to immediately
appear and a progress bar to be shown until the connection is
established.
Although the ParticipantDisplayItem may be created on a different thread
(the main thread) than the PeerConnectionWrapper "runOnUiThread"
executes the enqueued messages in order (and it also establishes a
"happens-before" relation with further calls of "runOnUiThread" due to
the internal use of synchronized blocks, although it is not explicitly
documented), so the item will be already created when later updated.
This also holds true when an offer is received even before the
participant is seen as joined (a very rare case that can happen if the
signaling message with the updated participant list is lost for any
reason); the ParticipantDisplayItem is created when the offer is
received and it is later updated with the user ID once a new signaling
message with the updated participant list is received.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Instead of creating a new ParticipantDisplayItem from scratch, which
resets the full grid, now the existing one is updated; a new one is
created only if no item existed already for the session and video stream
type of the media event.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The nick was displayed when updated through a data channel message, or
when a ParticipantDisplayItem was created and the nick was already
received. However, when the HPB is not used the nick is not sent after a
connection is established, as it was sent already in the offer or
answer. The nick from the offer or answer has not been received yet when
the ParticipantDisplayItem is initially created, so the nick only
appeared because a new ParticipantDisplayItem is created again when the
connection is finally established. Due to all that the displayed nick is
now updated as soon as it is received in an offer or answer, which
ensures that the nick is shown independently of when was the
ParticipantDisplayItem created.
Note that this only applies to non-HPB scenarios; when the HPB is used
the nick is got from the participant list update sent through signaling
messages, so it is already known when creating the display item (in some
very strange cases it might happen that an offer is received before the
participant list was updated, but this should not happen, and in any
case it will be handled at a later point).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
For now only the same data channel messages that were already handled
are taken into account, but at a later point the missing messages
("speaking" and "stoppedSpeaking") could be added too.
Note that the thread used to handle the data channel messages has
changed; the EventBus subscriber mode was "MAIN", but as the messages
were posted from a DataChannel observer, which run in a worker thread
rather than in the main thread, the subscriber was executed in the main
thread rather than in the same thread as the poster. Due to this the
actions performed by the handler now must be explicitly run in the main
thread.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the call is a voice only call there will be no received video tracks
(they would have been stopped when each connection is established), so
changing the enabled state has no effect (as the adapter only tries to
show the received video if it is available).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the display name is not known whether "Guest" or something else needs
to be shown is not a responsibility of the web socket, so now an empty
string is returned instead.
In practice this should not make any difference, though, as the display
name of users is always known as soon as the user joined, and if the
nick of a guest is not known the UI will set it to "Guest".
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
PeerConnectionWrappers should not be concerned with the nick of
participants. Moreover, the nick is included in offers and answers due
to legacy reasons and only when the internal signaling server is used.
Due to that the nick was moved out of PeerConnectionWrapper; although
the handling is now different the end result should be the same (there
might be some differences in very specific sequences of events, but in
any case all this is just a temporary step and any leftover issue should
be addressed once call participants and peer connections are split).
As the PeerConnectionWrapper does not keep track of the nick now the
nick changed event is always emitted when a nick changed data channel
message is received, even if the nick did not actually change.
Nevertheless, before it was anyway always emitted if it was for a user
and only when it was for a guest it was emitted only on real changes. In
any case this is not expected to cause any issue (other than some
unneeded view updates, but that will be addressed at a later point by
updating the views only when the model actually changed).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
If the nick is not known whether "Guest" or something else needs to be
shown is a responsability of the UI, so now the PeerConnectionWrapper
just returns an empty string and the UI shows the default guest nick if
needed.
Moreover, the nick stored in the PeerConnectionWrapper was not always
correct, as if no nick was received it was returned as "Guest" even
if the connection belonged to a user. Now "Guest" is used only for
actual guests.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The generic data channel message works fine for receiving, but it could
not be used for sending, because the serialization of the payload failed
(the generated JsonMapper did not call 'writeFieldName("payload")',
apparently because the payload was defined as "Any", so there was no
field name set when serializing the payload contents).
It is very likely that the nick data channel message, which has an
explicit payload type and was used only for sending but not for
receiving, was added back in the day just to work around that
limitation. However, due to how the JsonMappers are generated if several
properties with the same name are defined only the first one will be
parsed, and only those with a value will be serialized. This makes
possible to define first a generic payload property and then a payload
property with an explicit type to have a single data channel message
class that can be used both for sending and receiving.
As the nick data channel message is now no longer needed it was removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Note that the thread used to send the message does not change; the
EventBus subscriber mode was "BACKGROUND", but as the messages were
posted from a WebSocket handler (when requesting offers to the HPB) and
peer connection observers (when sending offers/answers and candidates,
both with and without HPB), which run in worker threads rather than in
the main thread, the subscriber was executed in the same thread as
the poster.
For legacy reasons, when the internal signaling server is used the
offers and answers are expected to also provide the nick of the local
participant. When the external signaling server is used the field can be
included, but it is just ignored and not sent to the other clients. As
the local participant nick is a value unrelated to the peer connection
and is only needed with one type of signaling server the messages are
adjusted as needed before being sent rather than handling this inside
the PeerConnectionWrapper.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Like done with SignalingMessageReceiver, an implementation specific to
each signaling server type (internal or external) is added.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As the "requestoffer" message is just a signaling message the generic
method can be used instead.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
"requestoffer" messages are compatible with the generic messages, so for
simplicity the generic message is used now instead of having specific
classes just for it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Messages sent to the internal signaling server need to be serialized
twice, first the signaling message and then the wrapper as a whole. Due
to this the NCMessageWrapper was not actually used.
For simplicity the manual serialization was kept rather than adding
something like "NCMessageWrapperToSend" where a serialized signaling
message could be set before serializing it.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
