[ECO-4899] feat: add public API for Chat SDK #1
Conversation
ttypic
force-pushed
the
ECO-4899/chat-public-api
branch
from
dd95567 to
a478e2b
Compare
ttypic
requested review from
AndyTWF,
lawrence-forooghian,
umair-ably and
sacOO7
Based on Ably Chat JS SDK repo at 0b4b0f8. This is just a first attempt and all the decisions can be revisited. Notable TypeScript-to-Kotlin decisions: - Functions that return Promises become suspend functions. - I decided to leave listeners as they are and not use `Flow` in the public interface. These listeners will be invoked synchronously with the events they are listening to. This approach makes it easy to provide extension functions for an idiomatic `Flow` interface on one hand, and on the other hand, it gives maximum flexibility for SDK users to utilize other reactive libraries like Reactor or RxJava. - The presence data type is `Any` for now.
ttypic
force-pushed
the
ECO-4899/chat-public-api
branch
from
a478e2b to
8c06949
Compare
WalkthroughThe changes introduce a comprehensive chat functionality within the Ably chat system. New interfaces, data classes, and enumerations provide structured management of chat rooms, messages, presence, reactions, typing, and connection states. Enhanced logging and configuration options, alongside error handling mechanisms, improve the robustness of the chat application. A minor adjustment to the code quality tool configuration is also included, allowing for shorter function names. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant ChatClient
participant Room
participant Messages
participant Presence
participant Typing
User->>ChatClient: Connect to chat
ChatClient->>Room: Join room
Room->>User: Room joined notification
User->>Messages: Send message
Messages->>Room: Relay message
Room->>User: Message received confirmation
User->>Presence: Update presence status
Presence->>Room: Notify presence change
User->>Typing: Start typing
Typing->>Room: Notify typing event
Room->>User: Typing indicator shown
TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
Outside diff range, codebase verification and nitpick comments (13)
chat-android/src/main/java/com/ably/chat/Occupancy.kt (5)
3-4: Consider adding more context to the import statement.The import statement for
Channelcould benefit from additional context or comments to clarify its purpose.Add a comment to the import statement:
-import io.ably.lib.realtime.Channel +// Importing Ably's Realtime Channel for occupancy events +import io.ably.lib.realtime.Channel
5-10: Improve documentation clarity.The documentation for the
Occupancyinterface could be more detailed, especially regarding how to obtain an instance.Enhance the documentation:
/** * This interface is used to interact with occupancy in a chat room: subscribing to occupancy updates and * fetching the current room occupancy metrics. * - * Get an instance via {@link Room.occupancy}. + * Get an instance via {@link Room.occupancy}. The occupancy interface provides methods to subscribe to occupancy updates, + * unsubscribe from updates, and fetch the current occupancy metrics of a chat room. */
11-17: Consider adding more context to thechannelproperty.The
channelproperty documentation could benefit from additional context or comments to clarify its purpose.Enhance the documentation:
/** * Get underlying Ably channel for occupancy events. * * @returns The underlying Ably channel for occupancy events. */ +// The Ably channel used to receive occupancy events for the chat room. val channel: Channel
41-50: Improve documentation clarity for theListenerinterface.The documentation for the
Listenerinterface and its function could be more detailed.Enhance the documentation:
/** * An interface for listening to new occupancy event */ fun interface Listener { /** * A function that can be called when the new occupancy event happens. - * @param event The event that happened. + * @param event The occupancy event that occurred. */ fun onEvent(event: OccupancyEvent) }
53-66: Improve documentation clarity for theOccupancyEventproperties.The documentation for the
OccupancyEventproperties could be more detailed.Enhance the documentation:
/** * Represents the occupancy of a chat room. */ data class OccupancyEvent( /** * The number of connections to the chat room. */ val connections: Int, /** * The number of presence members in the chat room - members who have entered presence. */ val presenceMembers: Int, )chat-android/src/main/java/com/ably/chat/Message.kt (7)
13-21: Consider renaming thetimeserialproperty.The property name
timeserialis not very descriptive. Consider renaming it totimestampfor better clarity.Rename the property:
data class Message( /** * The unique identifier of the message. */ - val timeserial: String, + val timestamp: String,
23-25: Consider renaming theclientIdproperty.The property name
clientIdcould be more descriptive. Consider renaming it tosenderIdfor better clarity.Rename the property:
/** * The clientId of the user who created the message. */ - val clientId: String, + val senderId: String,
28-30: Consider renaming theroomIdproperty.The property name
roomIdcould be more descriptive. Consider renaming it tochatRoomIdfor better clarity.Rename the property:
/** * The roomId of the chat room to which the message belongs. */ - val roomId: String, + val chatRoomId: String,
33-35: Consider renaming thetextvalproperty.The property name
textvalis not very descriptive. Consider renaming it tocontentfor better clarity.Rename the property:
/** * The text of the message. */ - val textval: String, + val content: String,
38-40: Consider renaming thecreatedAtproperty.The property name
createdAtcould be more descriptive. Consider renaming it tocreationTimestampfor better clarity.Rename the property:
/** * The timestamp at which the message was created. */ - val createdAt: Long, + val creationTimestamp: Long,
43-54: Improve documentation clarity for themetadataproperty.The documentation for the
metadataproperty could be more detailed.Enhance the documentation:
/** * The metadata of a chat message. Allows for attaching extra info to a message, * which can be used for various features such as animations, effects, or simply * to link it to other resources such as images, relative points in time, etc. * * Metadata is part of the Ably Pub/sub message content and is not read by Ably. * * This value is always set. If there is no metadata, this is an empty object. * * Do not use metadata for authoritative information. There is no server-side * validation. When reading the metadata treat it like user input. */ - val metadata: MessageMetadata, + val metadata: MessageMetadata = MessageMetadata(),
57-69: Improve documentation clarity for theheadersvalproperty.The documentation for the
headersvalproperty could be more detailed.Enhance the documentation:
/** * The headers of a chat message. Headers enable attaching extra info to a message, * which can be used for various features such as linking to a relative point in * time of a livestream video or flagging this message as important or pinned. * * Headers are part of the Ably realtime message extras.headers and they can be used * for Filtered Subscriptions and similar. * * This value is always set. If there are no headers, this is an empty object. * * Do not use the headers for authoritative information. There is no server-side * validation. When reading the headers treat them like user input. */ - val headersval: MessageHeaders, + val headersval: MessageHeaders = MessageHeaders(),chat-android/src/main/java/com/ably/chat/ErrorCodes.kt (1)
1-6: Consider adding more context to the import statement.The import statement for
ErrorCodescould benefit from additional context or comments to clarify its purpose.Add a comment to the import statement:
package com.ably.chat +// Error codes used in the Chat SDK object ErrorCodes {
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (21)
- chat-android/src/main/java/com/ably/chat/ChatClient.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/ClientOptions.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Connection.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/ConnectionStatus.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/EmitsDiscontinuities.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/ErrorCodes.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/EventTypes.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Headers.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/LogLevel.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Message.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Messages.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Metadata.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Occupancy.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Presence.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Reaction.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Room.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/RoomOptions.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/RoomReactions.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/RoomStatus.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Typing.kt (1 hunks)
- detekt.yml (2 hunks)
Additional comments not posted (70)
chat-android/src/main/java/com/ably/chat/Connection.kt (2)
1-1: LGTM!The package declaration is correct.
The code changes are approved.
3-11: LGTM!The interface
Connectionis well-defined and follows Kotlin conventions.The code changes are approved.
chat-android/src/main/java/com/ably/chat/ClientOptions.kt (3)
1-1: LGTM!The package declaration is correct.
The code changes are approved.
3-3: LGTM!The import statement is correct and necessary for the
ClientOptionsclass.The code changes are approved.
5-20: LGTM!The data class
ClientOptionsis well-defined and follows Kotlin conventions. The default values for the properties are appropriate.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Metadata.kt (2)
1-1: LGTM!The package declaration is correct.
The code changes are approved.
3-16: LGTM!The type alias
Metadatais well-defined and the comments provide valuable information on its usage.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Headers.kt (1)
1-19: LGTM!The type alias and comments are clear and informative.
The code changes are approved.
chat-android/src/main/java/com/ably/chat/ChatClient.kt (1)
1-37: LGTM!The interface is well-defined and provides clear access points for the core functionalities of the chat client.
The code changes are approved.
chat-android/src/main/java/com/ably/chat/EmitsDiscontinuities.kt (1)
1-31: LGTM!The interface is well-defined and provides clear methods for handling discontinuities.
The code changes are approved.
chat-android/src/main/java/com/ably/chat/Reaction.kt (3)
1-2: LGTM!The package declaration is correct, and no imports are needed.
The code changes are approved.
3-11: LGTM!The type aliases
ReactionHeadersandReactionMetadataare correctly defined with clear documentation comments.The code changes are approved.
13-46: LGTM!The data class
Reactionis well-defined with appropriate properties and clear documentation comments.The code changes are approved.
chat-android/src/main/java/com/ably/chat/LogLevel.kt (2)
1-2: LGTM!The package declaration is correct, and no imports are needed.
The code changes are approved.
3-40: LGTM!The enum class
LogLevelis well-defined with appropriate levels and clear documentation comments.The code changes are approved.
chat-android/src/main/java/com/ably/chat/EventTypes.kt (5)
1-2: LGTM!The package declaration is correct, and no imports are needed.
The code changes are approved.
3-9: LGTM!The enum class
MessageEventTypeis well-defined with a single event type and clear documentation comments.The code changes are approved.
11-34: LGTM!The enum class
PresenceEventTypeis well-defined with multiple event types and clear documentation comments.The code changes are approved.
36-39: LGTM!The enum class
TypingEventTypeis well-defined with a single event type and clear documentation comments.The code changes are approved.
41-50: LGTM!The enum class
RoomReactionEventTypeis well-defined with a single event type and clear documentation comments.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Message.kt (2)
1-6: LGTM!The type alias
MessageHeadersis correctly defined.The code changes are approved.
8-11: LGTM!The type alias
MessageMetadatais correctly defined.The code changes are approved.
chat-android/src/main/java/com/ably/chat/ErrorCodes.kt (16)
7-10: LGTM!The constant
MessagesAttachmentFailedis correctly defined.The code changes are approved.
12-15: LGTM!The constant
PresenceAttachmentFailedis correctly defined.The code changes are approved.
17-20: LGTM!The constant
ReactionsAttachmentFailedis correctly defined.The code changes are approved.
22-25: LGTM!The constant
OccupancyAttachmentFailedis correctly defined.The code changes are approved.
27-30: LGTM!The constant
TypingAttachmentFailedis correctly defined.The code changes are approved.
33-36: LGTM!The constant
MessagesDetachmentFailedis correctly defined.The code changes are approved.
38-41: LGTM!The constant
PresenceDetachmentFailedis correctly defined.The code changes are approved.
43-46: LGTM!The constant
ReactionsDetachmentFailedis correctly defined.The code changes are approved.
48-51: LGTM!The constant
OccupancyDetachmentFailedis correctly defined.The code changes are approved.
54-56: LGTM!The constant
TypingDetachmentFailedis correctly defined.The code changes are approved.
59-62: LGTM!The constant
RoomDiscontinuityis correctly defined.The code changes are approved.
66-69: LGTM!The constant
RoomInFailedStateis correctly defined.The code changes are approved.
71-74: LGTM!The constant
RoomIsReleasingis correctly defined.The code changes are approved.
76-79: LGTM!The constant
RoomIsReleasedis correctly defined.The code changes are approved.
81-84: LGTM!The constant
PreviousOperationFailedis correctly defined.The code changes are approved.
86-89: LGTM!The constant
RoomLifecycleErroris correctly defined.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Typing.kt (3)
8-18: LGTM!The constants for retry intervals and max retries are well-defined and self-explanatory.
The code changes are approved.
26-73: LGTM!The
Typinginterface is well-structured and provides comprehensive functionality for typing events, including subscribing, unsubscribing, getting current typers, starting, and stopping typing events. The nestedListenerinterface is also well-defined.The code changes are approved.
79-79: LGTM!The
TypingEventdata class is simple and well-defined, representing a typing event with a set of currently typing client IDs.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Room.kt (1)
6-82: LGTM!The
Roominterface is well-structured and provides comprehensive functionality for managing a chat room, including properties for room ID, messages, presence, reactions, typing, occupancy, status, and options. The methods for attaching and detaching from the room are also well-defined.The code changes are approved.
chat-android/src/main/java/com/ably/chat/RoomOptions.kt (4)
6-31: LGTM!The
RoomOptionsdata class is well-structured and provides comprehensive options for configuring a chat room, including properties for presence, typing, reactions, and occupancy options.The code changes are approved.
36-52: LGTM!The
PresenceOptionsdata class is well-structured and provides comprehensive options for configuring presence in a chat room, including properties for enter and subscribe modes.The code changes are approved.
57-64: LGTM!The
TypingOptionsdata class is well-structured and provides a comprehensive option for configuring typing events in a chat room, including a property for the timeout of typing events.The code changes are approved.
69-74: LGTM!The
RoomReactionsOptionsandOccupancyOptionsclasses are placeholders for future extensions and are well-defined.The code changes are approved.
chat-android/src/main/java/com/ably/chat/ConnectionStatus.kt (4)
8-8: LGTM!The constant
TRANSIENT_TIMEOUTis defined correctly.The code changes are approved.
13-45: LGTM!The interface
ConnectionStatusis well-defined and follows Kotlin conventions. The use ofListenerinterface is appropriate for handling connection status changes.The code changes are approved.
51-81: LGTM!The enum
ConnectionLifecycleis well-defined and covers all possible connection states.The code changes are approved.
86-107: LGTM!The data class
ConnectionStatusChangeis well-defined and includes all necessary properties to represent a connection status change.The code changes are approved.
chat-android/src/main/java/com/ably/chat/RoomStatus.kt (3)
8-40: LGTM!The interface
RoomStatusis well-defined and follows Kotlin conventions. The use ofListenerinterface is appropriate for handling room status changes.The code changes are approved.
46-91: LGTM!The enum
RoomLifecycleis well-defined and covers all possible room states.The code changes are approved.
96-112: LGTM!The data class
RoomStatusChangeis well-defined and includes all necessary properties to represent a room status change.The code changes are approved.
chat-android/src/main/java/com/ably/chat/RoomReactions.kt (2)
10-55: LGTM!The interface
RoomReactionsis well-defined and follows Kotlin conventions. The use ofListenerinterface is appropriate for handling room reaction events.The code changes are approved.
61-101: LGTM!The data class
SendReactionParamsis well-defined and includes all necessary properties to represent the parameters for sending a room reaction.The code changes are approved.
chat-android/src/main/java/com/ably/chat/Presence.kt (8)
27-27: Verify the usage ofList<Params>.Ensure that the usage of
List<Params>aligns with the intended functionality and that theParamsclass is correctly imported and utilized.
34-34: LGTM!The function is correctly implemented.
The code changes are approved.
41-41: LGTM!The function is correctly implemented.
The code changes are approved.
48-48: LGTM!The function is correctly implemented.
The code changes are approved.
55-55: LGTM!The function is correctly implemented.
The code changes are approved.
61-61: LGTM!The function is correctly implemented.
The code changes are approved.
67-67: LGTM!The function is correctly implemented.
The code changes are approved.
72-77: LGTM!The interface is correctly implemented.
The code changes are approved.
chat-android/src/main/java/com/ably/chat/Messages.kt (5)
25-25: LGTM!The function is correctly implemented.
The code changes are approved.
31-31: LGTM!The function is correctly implemented.
The code changes are approved.
40-40: LGTM!The function is correctly implemented.
The code changes are approved.
57-57: LGTM!The function is correctly implemented.
The code changes are approved.
62-67: LGTM!The interface is correctly implemented.
The code changes are approved.
detekt.yml (2)
574-574: LGTM!The change to
minimumFunctionNameLengthallows shorter function names, which might be useful for certain naming conventions or specific use cases.The code changes are approved.
1033-1033: LGTM!Adding a newline at the end of the file is a good practice for POSIX compliance.
The code changes are approved.
| * from the realtime channel. This means you may see the message that was just | ||
| * sent in a callback to `subscribe` before the function resolves. | ||
| * | ||
| * TODO: Revisit this resolution policy during implementation (it will be much better for DX if this behavior is deterministic). |
There was a problem hiding this comment.
Reminder: Revisit the resolution policy.
The TODO comment indicates that the resolution policy needs to be revisited during implementation.
Do you want me to generate a detailed plan for revisiting the resolution policy or open a GitHub issue to track this task?
There was a problem hiding this comment.
@ttypic, here's a detailed plan for revisiting the resolution policy of the send method in the Messages interface:
1. Current Behavior
The send method in the Messages interface currently exhibits non-deterministic behavior. Specifically, the suspending function may resolve either before or after the message is received from the realtime channel. This means that the message could appear in a callback to subscribe before the function resolves, which could lead to confusion and inconsistent user experiences.
2. Desired Behavior
The goal is to make the behavior deterministic, ensuring that the suspending function resolves only after the message has been received and processed by the realtime channel. This will provide a more predictable and consistent experience for developers using the SDK, as they can rely on the function's resolution to indicate that the message has been fully handled.
3. Implementation Strategy
-
Step 1: Investigate the Ably Realtime API: Review the Ably Realtime API documentation to understand how message delivery and acknowledgment are handled. Identify any existing mechanisms that can be leveraged to ensure that the
sendmethod resolves only after the message is confirmed to be received. -
Step 2: Modify the
sendMethod: Update the implementation of thesendmethod to include a confirmation step. This could involve waiting for an acknowledgment from the realtime channel before resolving the suspending function. -
Step 3: Update Documentation: Modify the method's documentation to reflect the new deterministic behavior, ensuring that developers are aware of the change and how it impacts their use of the
sendmethod.
4. Testing and Validation
-
Unit Tests: Create unit tests that simulate various scenarios, including sending messages and verifying that the suspending function resolves only after the message is received.
-
Integration Tests: Perform integration tests with the Ably Realtime service to ensure that the new behavior works correctly in a real-world environment.
-
Performance Testing: Assess the impact of the new behavior on performance, particularly in scenarios with high message throughput. Ensure that the confirmation step does not introduce significant latency.
5. Potential Challenges
-
Network Latency: Waiting for an acknowledgment from the realtime channel could introduce additional latency, especially in cases of poor network conditions. This needs to be carefully managed to avoid degrading the user experience.
-
Error Handling: Consider how to handle cases where the acknowledgment is delayed or fails to arrive. Implement appropriate error handling and retry mechanisms to ensure robustness.
Would you like me to open a GitHub issue to track this task, or is there anything else you'd like to adjust in this plan?
Learnings added
Learnt from: ttypic
PR: ably-labs/ably-chat-kotlin#1
File: chat-android/src/main/java/com/ably/chat/Messages.kt:51-51
Timestamp: 2024-08-27T12:04:00.584Z
Learning: When revisiting the resolution policy of the `send` method in the `Messages` interface, the goal is to make the behavior deterministic, ensuring that the suspending function resolves only after the message has been received and processed by the realtime channel.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
@coderabbitai can you also open an issue ?
There was a problem hiding this comment.
@jamienewcomb, it seems that the GitHub App (CodeRabbit) does not have the necessary permissions to create issues in the repository, as the command to open the issue failed with the error: GraphQL: Resource not accessible by integration (createIssue).
I recommend manually creating the issue using the detailed plan provided earlier. If you need any further assistance with the issue creation or anything else, feel free to ask!
Analysis chain
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Open a GitHub issue to track the task of revisiting the resolution policy of the `send` method in the `Messages` interface.
gh issue create --title "Revisit resolution policy of the 'send' method in the 'Messages' interface" --body $'### Task Description\n\nThe `send` method in the `Messages` interface currently exhibits non-deterministic behavior. Specifically, the suspending function may resolve either before or after the message is received from the realtime channel. This task involves revisiting the resolution policy to ensure deterministic behavior, where the suspending function resolves only after the message has been received and processed by the realtime channel.\n\n### Detailed Plan\n1. **Current Behavior**: The `send` method may resolve before or after the message is received.\n2. **Desired Behavior**: The method should resolve only after the message is received.\n3. **Implementation Strategy**: Modify the `send` method to include a confirmation step, update documentation, and test the new behavior.\n4. **Testing and Validation**: Perform unit, integration, and performance tests.\n5. **Potential Challenges**: Manage network latency and error handling.\n\n### References\n- [Pull Request #1](https://github.com/ably-labs/ably-chat-kotlin/pull/1)\n- [Comment #1732706283](https://github.com/ably-labs/ably-chat-kotlin/pull/1#discussion_r1732706283)\n\n### Assignee\n@jamienewcomb' --assignee jamienewcomb
Length of output: 1365
Permission issue
There was a permission issue. Please ask the repository administrator to refresh CodeRabbit's permissions at https://github.com/apps/coderabbitai/installations/54205914.
There was a problem hiding this comment.
@coderabbitai can you try and create the issue again?
There was a problem hiding this comment.
@jamienewcomb, it seems that the permission issue still persists, and the GitHub App (CodeRabbit) does not have the necessary access to create issues in the repository. I recommend manually creating the issue using the detailed plan provided earlier, or you could check the app's permissions to ensure it has the required access.
Let me know if you need any further assistance!
There was a problem hiding this comment.
@coderabbitai we have tried updating the permissions, try and create the issue again please?
There was a problem hiding this comment.
@jamienewcomb, the issue has been successfully created! You can track it here: Issue #14.
Let me know if you need any further assistance! 😊
Analysis chain
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Attempt to create the GitHub issue again after the permissions have been updated.
gh issue create --title "Revisit resolution policy of the 'send' method in the 'Messages' interface" --body $'### Task Description\n\nThe `send` method in the `Messages` interface currently exhibits non-deterministic behavior. Specifically, the suspending function may resolve either before or after the message is received from the realtime channel. This task involves revisiting the resolution policy to ensure deterministic behavior, where the suspending function resolves only after the message has been received and processed by the realtime channel.\n\n### Detailed Plan\n1. **Current Behavior**: The `send` method may resolve before or after the message is received.\n2. **Desired Behavior**: The method should resolve only after the message is received.\n3. **Implementation Strategy**: Modify the `send` method to include a confirmation step, update documentation, and test the new behavior.\n4. **Testing and Validation**: Perform unit, integration, and performance tests.\n5. **Potential Challenges**: Manage network latency and error handling.\n\n### References\n- [Pull Request #1](https://github.com/ably-labs/ably-chat-kotlin/pull/1)\n- [Comment #1732706283](https://github.com/ably-labs/ably-chat-kotlin/pull/1#discussion_r1732706283)\n\n### Assignee\n@jamienewcomb' --assignee jamienewcomb
Length of output: 1359
Also added TODO for `Messages#send` function, right now in the Chat JS documentation mentioned that it's behavior is non-deterministic, which is not very good for DX
ttypic
force-pushed
the
ECO-4899/chat-public-api
branch
from
7b2c2b1 to
344e9f4
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- chat-android/src/main/java/com/ably/chat/Messages.kt (1 hunks)
- chat-android/src/main/java/com/ably/chat/Occupancy.kt (1 hunks)
Files skipped from review due to trivial changes (1)
- chat-android/src/main/java/com/ably/chat/Occupancy.kt
Files skipped from review as they are similar to previous changes (1)
- chat-android/src/main/java/com/ably/chat/Messages.kt
| /** | ||
| * The rooms object, which provides access to chat rooms. | ||
| */ | ||
| val room: Room |
There was a problem hiding this comment.
Sorry for being late to the party - this property should be rooms, which provides a map-like structure of roomID -> Room
Notable TypeScript-to-Kotlin decisions:
Flowin the public interface. These listeners will be invoked synchronously with the events they are listening to. This approach makes it easy to provide extension functions for an idiomaticFlowinterface on one hand, and on the other hand, it gives maximum flexibility for SDK users to utilize other reactive libraries like Reactor or RxJava.Anyfor now.Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores