For v21.0.0, the following crash was reported:
Exception java.lang.NullPointerException: null cannot be cast to non-null type com.nextcloud.talk.chat.data.model.ChatMessage
at com.nextcloud.talk.chat.ChatActivity.onLoadMore (ChatActivity.kt:3107)
at com.stfalcon.chatkit.messages.MessagesListAdapter.onLoadMore (MessagesListAdapter.java:148)
at com.stfalcon.chatkit.messages.RecyclerScrollMoreListener.onScrolled (RecyclerScrollMoreListener.java:82)
at androidx.recyclerview.widget.RecyclerView.dispatchOnScrolled (RecyclerView.java:5688)
at androidx.recyclerview.widget.RecyclerView.dispatchLayoutStep3 (RecyclerView.java:4741)
at androidx.recyclerview.widget.RecyclerView.dispatchLayout (RecyclerView.java:4367)
at androidx.recyclerview.widget.RecyclerView.onLayout (RecyclerView.java:4919)
This is now improved:
- lastOrNull prevents exceptions if no matching item is found
- as? is a safe cast that returns null if the cast fails
Whole expression becomes null-safe, and id will be null if anything along the way doesn't match. Only when not null, onLoadMore continues.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
to be discussed: does it make sense to show a dialog instead? At least when it's created via 1:1 conversation
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
snackbars disaapear with the switch to a different screen. Toasts survive the switch so they are visible during the activities switch
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
- Most code removed from ChatActivity
- Most work in MediaPlayerManager
- Added BackgroundVoiceMessageCard
Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>
because setData was called too late (after sendTempChatMessages was called from messageInputFragment, internalConversationId was not initialized in repository).
With this change, internalConversationId, credentials and urlForChatting are initialized earlier which should avoid the issue.
However conversationModel is still initialized quite late and should be accessed with caution. This could may be improved by better architecture..
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
onDestroy is not called when navigating to the next activity or bringing the app to background. That's why the adapter was not set to null and all messages were added another time the next time the activity comes to foreground. With this fix, the adapter is set to null in onStop.
All in all, the adapter handling may not be the best, but will be replaced by Compose anyway..
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
when being offline and no messages are set -> hide shimmer
when messages are received -> hide shimmer and "offlineNoMessages"-info
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
This is necessary especially to cancel the long polling when configuration change was made, e.g. screen was rotated. Otherwise multiple long polling requests would be running after configuration changes.
Because it not possible to launch a new coroutine in a scope that was canceled, it is necessary to re-initialize the scope.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
if chatMessageList is empty after handleSystemMessages it makes no sense to call the following methods.
Also processMessagesFromTheFuture was executed which caused that the popup was shown.
A better solution for the future should be to handle(remove) the "to-hide" system messages already in the repo or viewmodel
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
The idea to show the progress bar (aka shimmer animation) was that it show not be shown at all if loading messages happens in less than a second (this was a better UX in my opinion).
The idea was to hide the progress bar when
ChatMessageStartState was triggered.
However there can be moment when adapter is still empty after ChatMessageStartState and if in this moment the DELAY_TO_SHOW_PROGRESS_BAR is reached before the adapter is actually filled, the overlay happens.
It could be a solution to move the hiding of the progress bar, however then special cases might have to be handled.
For simplicity, the logic for DELAY_TO_SHOW_PROGRESS_BAR is removed. Progress bar is always shown without a delay so it wont be triggered on a later moment and can't overlay the chat.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
By using
networkMonitor.isOnline.first()
the function
unregisterNetworkCallback
was triggered, which sometimes causes the ConnectivityManager$TooManyRequestsException.
So each time isOnline.first() was called, the callbackFlow would:
- Register a new NetworkCallback.
- Emit a value and cancel the flow.
- Unregister the NetworkCallback.
The exception was:
Exception android.net.ConnectivityManager$TooManyRequestsException:
at android.net.ConnectivityManager.convertServiceException (ConnectivityManager.java:3771)
at android.net.ConnectivityManager.sendRequestForNetwork (ConnectivityManager.java:3960)
at android.net.ConnectivityManager.sendRequestForNetwork (ConnectivityManager.java:3967)
at android.net.ConnectivityManager.registerNetworkCallback (ConnectivityManager.java:4349)
at android.net.ConnectivityManager.registerNetworkCallback (ConnectivityManager.java:4319)
at com.nextcloud.talk.data.network.NetworkMonitorImpl$isOnline$1.invokeSuspend (NetworkMonitorImpl.kt:61)
To fix this, the cold flow from callbackFlow is converted to a StateFlow.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
If user sent a message as a first message in today's chat, the temp message will be deleted when messages are retrieved from server, but also the date has to be deleted as it will be added again when the chat messages are added from server. Otherwise date "Today" would be shown twice.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
reason was that the UI was not yet loaded but isScrolledToBottom was already called, so findFirstVisibleItemPosition returned -1.
Fix for now is to return true for isScrolledToBottom when position is -1
They does not solve the root cause for now. It should be made sure the code is not executed until UI is ready.
A quick try with
repeatOnLifecycle(Lifecycle.State.STARTED)
when collecting getMessageFlow did not help.
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
TODO:
check id type --> see TODO "currentTimeMillies fails as id because later on in the model it's not Long but Int!!!!" in OfflineFirstChatRepository.kt
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
(as datasources should be only used in repositories)
use coroutines instead RxJava for api calls triggered by MessageInputViewModel
Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
