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>
