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>
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>
did not test why this can happen. autocompleteUser.id must have been null..
Exception java.lang.NullPointerException:
at com.nextcloud.talk.controllers.ContactsController.processAutocompleteUserList (ContactsController.kt:498)
at com.nextcloud.talk.controllers.ContactsController.processAutocompleteUserList (ContactsController.kt:482)
at com.nextcloud.talk.controllers.ContactsController.access$processAutocompleteUserList (ContactsController.kt:90)
at com.nextcloud.talk.controllers.ContactsController$fetchData$1.onNext (ContactsController.kt:438)
at com.nextcloud.talk.controllers.ContactsController$fetchData$1.onNext (ContactsController.kt:432)
at io.reactivex.internal.operators.observable.ObservableRetryPredicate$RepeatObserver.onNext (ObservableRetryPredicate.java:69)
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:7948)
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:1075)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
just refactoring for now. this doesn't solve the bug!
Problem that needs to be solved:
When adding a new Account (User), it is marked as "current", while for the other logged in users "current" must be unset (-> disabled).
The problem is, that for the old active user, "current" is not unset so there were multiple accounts marked as "current".
In the ChooseAccountDialogFragment, only one of the current accounts is shown at the top. Below the set status field, all accounts are listed that are not marked with "current". So as a result, there can be accounts hidden that were marked as "current".
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
-> add callback methods to ConductorRemapping to execute after chat room was left. Whenever there is a ChatController on top, it's room is now left, before replacing the controller or pushing another one on top.
this avoids problems where entering a chat before the old one was left led to sessionId="0" for the new chat.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
# reproduce:
1. click in chat where someone is mentioned.
2. click on the mention
3. go back to first chat
# result:
validSessionId() can be false in onDetach for the second chat when going back to first chat
-> leaveRoom is not executed
-> disposable is not disposed
-> getRoomInfo() continues to execute for old controller
-> e.g. appbar infos can be wrong (wrong avatar/title)
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Fresco is replaced with Coil everywhere to make it possible to set 'minSdkVersion'
to 23. But Coil is not used directly to avoid splintering the dependency
everywhere in the code. Coil is wrapped by extension functions for 'ImageView'.
Some shared functionality is moved from 'DisplayUtils' into the
'ImageViewExtensions'.
The exisiting initialization of Coil has also be changed. The usage of the self
initialized OKHttp client is removed. If this one is added the
caching of the http client is used by Coil additionally to memory and
disk cache.
Resolves: #2227, #2376
Signed-off-by: Tim Krüger <t@timkrueger.me>
In further versions of the ImagePicker library the class 'File' is used
to reference an image. Using 'File' caused the permission problems mentioned
in #2511.
Resolves: #2511
See: d7e643b560
Signed-off-by: Tim Krüger <t@timkrueger.me>
This should avoid that the capabilities not available for the server EOL
check in 'ConversationListController#onAttach'.
Missing capabilites can also have an impact on multiple actions, but the
server EOL check is the first one.
Resolves: #2418
Signed-off-by: Tim Krüger <t@timkrueger.me>
With this implementation the can publish audio & video permission are
set during the creation of the 'CallActivity'. This permissions are
fixed for the complete call. If the permissions are changed by a
moderator the call must be left and joined again.
Resolves: #1783
Signed-off-by: Tim Krüger <t@timkrueger.me>
Now the 'can ignore lobby' permission is respected.
The 'ChatController' has now a property of the type
'ParticipantPermissions' because it's needed multiple times. The
property will be updated in 'ChatController#getRoomInfo' if the
conversation is protected by a lobby.
The function 'Conversation#shouldShowLobby' is removed in this commit.
'Conversation' is a pure model class to hold the plain JSON response.
The logic is moved into the already existing function 'ChatController#shouldShowLobby'.
Resolves: #1783
Signed-off-by: Tim Krüger <t@timkrueger.me>
The chat controller gets the room information again and again to check
whether the lobby is enabled and update the UI as needed. This loop is
stopped when the chat controller is detached, but only if no call is
active; if a call is active the room information will still be got again
and again, even if the chat controller is detached.
To solve that now getting the room information is simply stopped when
the chat controller is detached, no matter if there is an active call or
not, and started again when joining the room, which is done when the
chat controller is attached.
However, this is just a quick fix that does not solve the issue in all
cases; the loop can still continue during calls, for example if the
request to get the information is sent before detaching the controller
and the response is received once the controller was detached, as that
would start the timer again.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
