Add Groups to Conversations #160
Conversation
This reverts commit 8998d13.
| @@ -99,13 +124,16 @@ sealed class Conversation { | |||
| .setKeyMaterial(conversationV2.keyMaterial.toByteString()), | |||
| ), | |||
| ).build() | |||
|
|
|||
| is Group -> throw XMTPException("Groups do not support topics") | |||
There was a problem hiding this comment.
Why is TopicData and keyMaterial exposed in v2? What will integrators do with it?
There was a problem hiding this comment.
I believe TopicData and keyMaterial is used for push notifications. That way they can export from react native or javascript and import into iOS or android and not need to reload the entire costly conversation.list() method to decrypt a push notification.
library/src/main/java/org/xmtp/android/library/Conversations.kt
Outdated
Show resolved
Hide resolved
| @@ -552,6 +559,13 @@ class Client() { | |||
| return runBlocking { query(Topic.contact(peerAddress)).envelopesList.size > 0 } | |||
| } | |||
|
|
|||
| fun canMessage(addresses: List<String>): Boolean { | |||
| return runBlocking { | |||
| libXMTPClient != null && !libXMTPClient!!.canMessage(addresses.map { it.lowercase() }) | |||
There was a problem hiding this comment.
@richardhuaaa my tests failed after I implemented this. I think this is another scenario where lowercase should be handled on the rust side.
| @@ -127,6 +155,8 @@ sealed class Conversation { | |||
| is V2 -> { | |||
| conversationV2.prepareMessage(content = content, options = options) | |||
| } | |||
|
|
|||
| is Group -> throw XMTPException("Groups do not support prepared messages") // We return a encoded content not a preparedmessage which requires a envelope | |||
There was a problem hiding this comment.
I'm not a kotlin expert and am not familiar with sealed classes. Are these methods being exposed directly to implementors, and are they required to know which methods they can/can't call on groups?
If so, can we find a way to use strong typing (for example, separate types for group and 1:1) where only the methods they can call are exposed?
There was a problem hiding this comment.
Ya I definitely have thought about this and maybe it can be spike/refactor. Since groups aren't being created users shouldn't experience this for now. But agree it almost feels like we need to return a type of either Conversation or Group instead of making Groups conform to conversations but it would be a little extra work. My hope is when we get rid of V2 this won't be a problem because most all the same functions should exist for both groups and 1to1 in that world.
Part of #157
This adds a new class called Group that behaves similar to a Conversation and allows listing and sending of messages.