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>
