-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
- Hooked up websocket manager with SDK Flow #12
Conversation
@@ -196,7 +196,7 @@ class ChatViewModel @Inject constructor( | |||
} | |||
|
|||
|
|||
private fun createParticipantConnection(chatDetails: ChatDetails?) { | |||
private fun createParticipantConnection1(chatDetails: ChatDetails?) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious - why do we have a createParticipantConnection
and also a createParticipantConnection1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
createParticipantConnection1
is from existing implementation and we are keeping it for reference purpose. Once we completely migrate example to leverage SDK, we will remove it
app/src/main/java/com/amazon/connect/chat/androidchatexample/MainActivity.kt
Outdated
Show resolved
Hide resolved
@@ -100,15 +96,18 @@ class ChatViewModel @Inject constructor( | |||
private fun setupChatHandlers(chatSession: ChatSession) { | |||
chatSession.onConnectionEstablished = { | |||
Log.d("ChatViewModel", "Connection established.") | |||
_isChatActive.value = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we be tracking this in our SDK's ChatSession
object instead of in the UI example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This flag is for UI purpose to show the chat view and is unrelated to SDK chatsesion active
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be extra effort to just implement it on the SDK side or is it just simpler to do in the UI app for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can find a workaround for that. Its just that we cant have customer relying completely on our flag, they might wanna show/hide view as they want. But we can introduce a callback on session active.
handleWebSocketClosed(code, reason) | ||
} | ||
override fun onClosing(ws: WebSocket, code: Int, reason: String) { | ||
Log.i("WebSocket", "WebSocket is closing with code: $code, reason: $reason") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we eventually replace this with some sort of Logger
object or is this how we surface relevant logs to the parent app?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can surface this way as well but we will replace all the logs with Logger at once. Same we did with iOS
Issue #, if available:
Description of changes:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.