Changes for comments for ccct-1060 #3224
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📝 WalkthroughWalkthroughThis set of changes updates the chat messaging feature in several ways. The Sequence Diagram(s)sequenceDiagram
participant User
participant ConnectMessageFragment
participant ConnectMessageAdapter
participant ConnectMessageChatData
participant RecyclerView
User->>ConnectMessageFragment: Press Send Button
ConnectMessageFragment->>ConnectMessageChatData: Create new message data (fromMessage)
ConnectMessageFragment->>ConnectMessageAdapter: addMessage(new ChatData)
ConnectMessageAdapter->>RecyclerView: Notify item inserted
ConnectMessageFragment->>RecyclerView: Scroll to latest message
sequenceDiagram
participant MessageManager
participant ConnectMessagingChannelRecord
participant ChannelAdapter
MessageManager->>ConnectMessagingChannelRecord: Retrieve channel data
ChannelAdapter->>ConnectMessagingChannelRecord: getLastMessageDate()
ChannelAdapter->>ConnectMessagingChannelRecord: getUnreadCount()
ChannelAdapter->>UI: Display last message date and unread count
Possibly related PRs
Suggested reviewers
✨ Finishing Touches
🧪 Generate Unit Tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 using PR comments)
Other keywords and placeholders
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: 1
🧹 Nitpick comments (3)
app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java (2)
169-171: Add JavaDoc documentation for the new public method.The method logic is correct and provides a clean way to get the last message timestamp. However, public methods should include proper JavaDoc documentation.
+ /** + * Returns the timestamp of the most recent message in this channel. + * @return Date of the last message, or null if no messages exist + */ public Date getLastMessageDate() {
173-185: Add JavaDoc documentation and consider performance optimization.The unread count logic is correct - it counts backwards from the latest message until it finds a viewed message. However, consider adding documentation and potentially optimizing for large message lists.
+ /** + * Calculates the number of unread messages in this channel. + * Counts backward from the most recent message until a viewed message is found. + * @return Number of unread messages + */ public int getUnreadCount() {For channels with many messages, consider caching this value or using a more efficient approach if performance becomes an issue.
app/src/org/commcare/adapters/ConnectMessageAdapter.java (1)
42-52: Optimize the message status update method.While the logic is correct, using
notifyDataSetChanged()refreshes the entire list. Consider usingnotifyItemChanged()for better performance.public void updateMessageReadStatus(ConnectMessageChatData modifiedChat) { if (messages.size() > 0) { - for (ConnectMessageChatData chat : messages) { + for (int i = 0; i < messages.size(); i++) { + ConnectMessageChatData chat = messages.get(i); if (chat.getMessageId().equals(modifiedChat.getMessageId())) { chat.setMessageRead(modifiedChat.isMessageRead()); - notifyDataSetChanged(); + notifyItemChanged(i); return; } } } }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
app/res/layout/item_chat_left_view.xml(2 hunks)app/res/layout/item_chat_right_view.xml(3 hunks)app/src/org/commcare/adapters/ChannelAdapter.java(3 hunks)app/src/org/commcare/adapters/ConnectMessageAdapter.java(3 hunks)app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java(2 hunks)app/src/org/commcare/connect/MessageManager.java(7 hunks)app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java(4 hunks)app/src/org/commcare/fragments/connectMessaging/ConnectMessageChatData.java(3 hunks)app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java(6 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#3113
File: app/src/org/commcare/utils/OTPVerificationCallback.java:1-9
Timestamp: 2025-05-16T15:00:47.041Z
Learning: Public interfaces, classes, and methods in the CommCare Android codebase should include proper JavaDoc comments that describe their purpose, parameters, return values, and exceptions where applicable.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
app/src/org/commcare/connect/MessageManager.java (10)
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#3113
File: app/src/org/commcare/utils/OTPVerificationCallback.java:1-9
Timestamp: 2025-05-16T15:00:47.041Z
Learning: Public interfaces, classes, and methods in the CommCare Android codebase should include proper JavaDoc comments that describe their purpose, parameters, return values, and exceptions where applicable.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingMessageRecord.java:0-0
Timestamp: 2025-04-22T17:05:39.842Z
Learning: In ConnectMessagingMessageRecord, decryption failures are expected in some scenarios and are handled by logging the exception with Logger.exception() but continuing execution by returning null, allowing the application to gracefully handle the failure.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/fragments/SelectInstallModeFragment.java:201-205
Timestamp: 2025-05-22T14:26:41.341Z
Learning: In the Connect error handling flow of CommCare Android, error messages are shown once and then automatically cleared because the underlying error record gets deleted after being displayed. This is why there's no need for explicit methods to hide these messages.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:86-99
Timestamp: 2025-04-22T16:44:26.867Z
Learning: In ConnectMessagingChannelRecord, fields like META_CHANNEL_ID, META_CONSENT, META_CHANNEL_NAME, and META_KEY_URL are required fields, and the code is intentionally designed to crash if they're missing to raise awareness of data integrity issues rather than handling them silently.
app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java (15)
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/activities/CommCareSetupActivity.java:360-364
Timestamp: 2025-05-22T14:28:35.959Z
Learning: In CommCareSetupActivity.java, the call to installFragment.showConnectErrorMessage() after fragment transactions is intentionally unguarded with null checks. This follows the app's design pattern where critical error paths prefer immediate crashes over silent failures, making potential issues immediately visible during development rather than hiding them with defensive programming.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/fragments/SelectInstallModeFragment.java:201-205
Timestamp: 2025-05-22T14:26:41.341Z
Learning: In SelectInstallModeFragment.java, the showConnectErrorMessage method intentionally omits null checks because it's called at a specific point in the startup flow where UI is guaranteed to be loaded. It's designed to crash if activity or view is null to make potential issues immediately visible rather than hiding them with defensive programming.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3108
File: app/src/org/commcare/fragments/connect/ConnectUnlockFragment.java:62-64
Timestamp: 2025-06-04T19:17:21.213Z
Learning: In ConnectUnlockFragment.java, the user prefers to let getArguments() potentially throw NullPointerException rather than adding null checks, as the arguments are required for proper navigation flow and their absence indicates a programming error that should fail fast.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/fragments/SelectInstallModeFragment.java:201-205
Timestamp: 2025-05-22T14:26:41.341Z
Learning: In the Connect error handling flow of CommCare Android, error messages are shown once and then automatically cleared because the underlying error record gets deleted after being displayed. This is why there's no need for explicit methods to hide these messages.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3108
File: app/src/org/commcare/models/connect/ConnectLoginJobListModel.java:79-92
Timestamp: 2025-06-20T15:51:14.157Z
Learning: The ConnectLoginJobListModel class in app/src/org/commcare/models/connect/ConnectLoginJobListModel.java does not need to implement Parcelable interface as it is not passed between Android activities or fragments.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3108
File: app/src/org/commcare/fragments/connect/ConnectDownloadingFragment.java:74-78
Timestamp: 2025-06-06T19:54:26.428Z
Learning: In ConnectDownloadingFragment.java and similar Connect-related code, the team prefers to let "should never happen" scenarios like null app records crash rather than add defensive null checks, following a fail-fast philosophy to catch programming errors during development.
Learnt from: shubham1g5
PR: dimagi/commcare-android#2949
File: app/src/org/commcare/fragments/connectId/ConnectIDSecondaryPhoneNumber.java:58-59
Timestamp: 2025-03-10T08:16:59.436Z
Learning: All fragments using view binding should implement proper cleanup in onDestroyView() by setting binding to null to prevent memory leaks.
Learnt from: shubham1g5
PR: dimagi/commcare-android#2949
File: app/src/org/commcare/fragments/connectId/ConnectIDSecondaryPhoneNumber.java:58-59
Timestamp: 2025-03-10T08:16:59.436Z
Learning: All fragments using view binding should implement proper cleanup in onDestroyView() by setting binding to null to prevent memory leaks.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:86-99
Timestamp: 2025-04-22T16:44:26.867Z
Learning: In ConnectMessagingChannelRecord, fields like META_CHANNEL_ID, META_CONSENT, META_CHANNEL_NAME, and META_KEY_URL are required fields, and the code is intentionally designed to crash if they're missing to raise awareness of data integrity issues rather than handling them silently.
app/res/layout/item_chat_left_view.xml (4)
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/activity_connect_messaging.xml:0-0
Timestamp: 2025-05-09T13:45:18.661Z
Learning: In Android layouts, use `layout_constraintStart_toStartOf` and `layout_constraintEnd_toEndOf` instead of the deprecated `layout_constraintLeft_toLeftOf` and `layout_constraintRight_toRightOf` to ensure proper RTL (Right-to-Left) layout support.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/activity_connect_messaging.xml:0-0
Timestamp: 2025-05-09T13:45:18.661Z
Learning: In Android ConstraintLayout, use `layout_constraintStart_toStartOf` and `layout_constraintEnd_toEndOf` instead of the deprecated `layout_constraintLeft_toLeftOf` and `layout_constraintRight_toRightOf` to ensure proper RTL (Right-to-Left) layout support for languages like Arabic, Hebrew, and Persian.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/dialog_payment_confirmation.xml:57-65
Timestamp: 2025-05-09T07:05:19.320Z
Learning: In a ConstraintLayout, a view with width set to wrap_content only needs a single horizontal constraint (either start or end) for proper positioning, as opposed to views with match_constraint (0dp) width which require both horizontal constraints to determine their size.
app/res/layout/item_chat_right_view.xml (5)
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/activity_connect_messaging.xml:0-0
Timestamp: 2025-05-09T13:45:18.661Z
Learning: In Android layouts, use `layout_constraintStart_toStartOf` and `layout_constraintEnd_toEndOf` instead of the deprecated `layout_constraintLeft_toLeftOf` and `layout_constraintRight_toRightOf` to ensure proper RTL (Right-to-Left) layout support.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/activity_connect_messaging.xml:0-0
Timestamp: 2025-05-09T13:45:18.661Z
Learning: In Android ConstraintLayout, use `layout_constraintStart_toStartOf` and `layout_constraintEnd_toEndOf` instead of the deprecated `layout_constraintLeft_toLeftOf` and `layout_constraintRight_toRightOf` to ensure proper RTL (Right-to-Left) layout support for languages like Arabic, Hebrew, and Persian.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/layout/dialog_payment_confirmation.xml:57-65
Timestamp: 2025-05-09T07:05:19.320Z
Learning: In a ConstraintLayout, a view with width set to wrap_content only needs a single horizontal constraint (either start or end) for proper positioning, as opposed to views with match_constraint (0dp) width which require both horizontal constraints to determine their size.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
app/src/org/commcare/adapters/ChannelAdapter.java (4)
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
app/src/org/commcare/fragments/connectMessaging/ConnectMessageChatData.java (7)
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#2912
File: app/src/org/commcare/android/database/connect/models/ConnectUserRecord.java:66-71
Timestamp: 2025-01-21T17:28:09.007Z
Learning: The ConnectUserRecord class in CommCare Android uses @Persisting annotations with sequential indices for field persistence, and @MetaField annotations for fields that have corresponding META constants. Fields should be documented with Javadoc comments explaining their purpose, format requirements, and relationships with other fields.
app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java (9)
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:86-99
Timestamp: 2025-04-22T16:44:26.867Z
Learning: In ConnectMessagingChannelRecord, fields like META_CHANNEL_ID, META_CONSENT, META_CHANNEL_NAME, and META_KEY_URL are required fields, and the code is intentionally designed to crash if they're missing to raise awareness of data integrity issues rather than handling them silently.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2847
File: app/src/org/commcare/android/database/connect/models/ConnectLearnModuleSummaryRecord.java:51-52
Timestamp: 2025-01-27T09:51:02.754Z
Learning: The `lastUpdate` field in `ConnectLearnModuleSummaryRecord` does not need to be initialized in the `fromJson` method.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#2912
File: app/src/org/commcare/android/database/connect/models/ConnectUserRecord.java:66-71
Timestamp: 2025-01-21T17:28:09.007Z
Learning: The ConnectUserRecord class in CommCare Android uses @Persisting annotations with sequential indices for field persistence, and @MetaField annotations for fields that have corresponding META constants. Fields should be documented with Javadoc comments explaining their purpose, format requirements, and relationships with other fields.
app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java (12)
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/activities/CommCareSetupActivity.java:360-364
Timestamp: 2025-05-22T14:28:35.959Z
Learning: In CommCareSetupActivity.java, the call to installFragment.showConnectErrorMessage() after fragment transactions is intentionally unguarded with null checks. This follows the app's design pattern where critical error paths prefer immediate crashes over silent failures, making potential issues immediately visible during development rather than hiding them with defensive programming.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3040
File: app/src/org/commcare/android/database/connect/models/ConnectJobDeliveryFlagRecord.java:39-55
Timestamp: 2025-04-18T20:13:29.655Z
Learning: In the CommCare Android Connect feature, the JSON object passed to `ConnectJobDeliveryFlagRecord.fromJson()` method should never be null based on the implementation design.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3108
File: app/src/org/commcare/fragments/connect/ConnectDownloadingFragment.java:74-78
Timestamp: 2025-06-06T19:54:26.428Z
Learning: In ConnectDownloadingFragment.java and similar Connect-related code, the team prefers to let "should never happen" scenarios like null app records crash rather than add defensive null checks, following a fail-fast philosophy to catch programming errors during development.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:0-0
Timestamp: 2025-04-22T17:04:26.780Z
Learning: In the Connect API contract, the server doesn't include the fields `created`, `answered_consent`, and `key` in JSON responses for messaging channels, which is why the `fromJson` method in `ConnectMessagingChannelRecord` explicitly initializes these values rather than parsing them from JSON.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3121
File: app/src/org/commcare/fragments/SelectInstallModeFragment.java:201-205
Timestamp: 2025-05-22T14:26:41.341Z
Learning: In the Connect error handling flow of CommCare Android, error messages are shown once and then automatically cleared because the underlying error record gets deleted after being displayed. This is why there's no need for explicit methods to hide these messages.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java:86-99
Timestamp: 2025-04-22T16:44:26.867Z
Learning: In ConnectMessagingChannelRecord, fields like META_CHANNEL_ID, META_CONSENT, META_CHANNEL_NAME, and META_KEY_URL are required fields, and the code is intentionally designed to crash if they're missing to raise awareness of data integrity issues rather than handling them silently.
Learnt from: OrangeAndGreen
PR: dimagi/commcare-android#3043
File: app/src/org/commcare/android/database/connect/models/ConnectMessagingMessageRecord.java:0-0
Timestamp: 2025-04-22T17:05:39.842Z
Learning: In ConnectMessagingMessageRecord, decryption failures are expected in some scenarios and are handled by logging the exception with Logger.exception() but continuing execution by returning null, allowing the application to gracefully handle the failure.
app/src/org/commcare/adapters/ConnectMessageAdapter.java (6)
Learnt from: shubham1g5
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T11:08:18.530Z
Learning: PR #3048 "Phase 4 Connect PR" introduces a substantial feature called "Connect" to the CommCare Android app, which includes messaging, job management, delivery tracking, payment processing, authentication flows, and learning modules. It follows a modern architecture using Navigation Components with three navigation graphs, segregated business logic in Manager classes, and proper database persistence.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#0
File: :0-0
Timestamp: 2025-05-08T13:40:19.645Z
Learning: PR #3048 introduces a comprehensive messaging system in the Connect feature, implementing secure encryption using AES-GCM for message content, proper channel management with consent flows, and a well-designed UI separation between sent and received messages with real-time notification integration.
Learnt from: pm-dimagi
PR: dimagi/commcare-android#2956
File: app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java:58-60
Timestamp: 2025-02-19T15:15:01.935Z
Learning: Error handling for message retrieval in ConnectMessageChannelListFragment's retrieveMessages callback is not required as per user preference.
Learnt from: Jignesh-dimagi
PR: dimagi/commcare-android#3093
File: app/res/navigation/nav_graph_connect_messaging.xml:41-45
Timestamp: 2025-05-09T10:57:41.073Z
Learning: In the CommCare Android codebase, the navigation graph for Connect messaging (`nav_graph_connect_messaging.xml`) intentionally uses `channel_id` as the argument name in the connectMessageFragment, despite using `channelId` in other parts of the same navigation graph. This naming difference is by design in the refactored code.
Learnt from: shubham1g5
PR: dimagi/commcare-android#2949
File: app/src/org/commcare/fragments/connectId/ConnectIDSecondaryPhoneNumber.java:58-59
Timestamp: 2025-03-10T08:16:59.436Z
Learning: All fragments using view binding should implement proper cleanup in onDestroyView() by setting binding to null to prevent memory leaks.
Learnt from: shubham1g5
PR: dimagi/commcare-android#2949
File: app/src/org/commcare/fragments/connectId/ConnectIDSecondaryPhoneNumber.java:58-59
Timestamp: 2025-03-10T08:16:59.436Z
Learning: All fragments using view binding should implement proper cleanup in onDestroyView() by setting binding to null to prevent memory leaks.
🧬 Code Graph Analysis (1)
app/src/org/commcare/adapters/ConnectMessageAdapter.java (1)
app/src/org/commcare/connect/ConnectDateUtils.kt (1)
formatDateTime(25-27)
🔇 Additional comments (21)
app/res/layout/item_chat_left_view.xml (3)
6-6: LGTM! Tools namespace added for design-time preview.Good addition of the tools namespace to support design-time attributes.
35-41: LGTM! Improved TextView implementation.The change to
AppCompatTextViewprovides better styling consistency and compatibility. Usingtools:textinstead ofandroid:textcorrectly restricts the sample text to design-time preview only.
43-51: LGTM! Semantic ID correction and improved TextView.Excellent changes:
- ID change from
tvUserNametotvChatDatecorrectly represents the element's purpose- Consistent use of
AppCompatTextViewandtools:text- This aligns with the adapter refactoring mentioned in the summary
app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java (1)
157-159: LGTM! Method formatting improved.Good formatting improvement for better readability.
app/src/org/commcare/fragments/connectMessaging/ConnectMessageChannelListFragment.java (3)
74-74: LGTM! Improved formatting consistency.Good addition of space after
ifkeyword for better readability.
93-93: LGTM! Enhanced readability with proper spacing.Good formatting improvement with proper spacing around logical operators.
114-114: LGTM! Consistent formatting improvements.Excellent formatting improvements throughout the file with proper spacing around operators and method parameters. These changes enhance code readability and maintain consistency.
Also applies to: 117-117, 122-122, 136-136
app/src/org/commcare/connect/MessageManager.java (1)
41-41: LGTM! Comprehensive formatting improvements.Excellent formatting enhancements throughout the file including:
- Consistent spacing around operators and parentheses
- Proper indentation and method parameter alignment
- Enhanced readability without changing functionality
- Improved logging message clarity
These changes maintain the existing logic while significantly improving code readability and consistency.
Also applies to: 46-46, 50-50, 57-58, 66-66, 68-68, 77-77, 84-84, 123-123, 130-130, 135-135, 183-183, 189-189, 234-234, 235-235, 241-241, 246-246, 283-283, 284-284, 297-297
app/src/org/commcare/adapters/ChannelAdapter.java (4)
29-29: LGTM! Constructor formatting improved.Good formatting improvement with proper spacing in parameter list.
67-68: LGTM! Excellent encapsulation improvement.Great refactoring to use the new
getLastMessageDate()andgetUnreadCount()methods fromConnectMessagingChannelRecord. This centralizes the logic in the model class and simplifies the adapter code, following good object-oriented design principles.
74-74: LGTM! Consistent formatting improvements.Good formatting enhancements with proper spacing around
ifstatements and operators for better readability.Also applies to: 76-76, 88-88
93-93: OnChannelClickListener is guaranteed non-null
TheChannelAdapterconstructor requires and stores a non-nullOnChannelClickListener(declaredfinal), and the only instantiation is inConnectMessageChannelListFragment.javawiththis::selectChannel. A null listener can’t be passed—no defensive null check is needed.app/res/layout/item_chat_right_view.xml (1)
6-6: Excellent semantic improvements and best practices.The changes improve the layout in several ways:
- Adding the
toolsnamespace enables proper design-time previews- Using
tools:textinstead ofandroid:textcorrectly separates preview content from runtime behavior- Renaming the ID from
tvUserNametotvChatDateaccurately reflects its purpose as a timestamp displayThese changes align perfectly with the adapter refactoring that references
tvChatDate.Also applies to: 40-40, 52-52, 55-55
app/src/org/commcare/fragments/connectMessaging/ConnectMessageChatData.java (2)
6-6: Well-structured data model enhancement.The addition of
messageIdfield with corresponding constructor parameter and getter method enables unique message identification, which is essential for the new adapter methods likeupdateMessageReadStatus(). The implementation follows standard Java conventions.Also applies to: 15-16, 25-27
37-39: Minor formatting improvement.The multi-line formatting of the
getTimestamp()method improves readability without changing functionality.app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java (3)
158-160: Excellent performance optimization.Replacing the full
refreshUi()call with direct message addition to the adapter is a significant performance improvement. The use of the newfromMessage()helper method ensures consistent data conversion.
185-185: Good defensive programming practices.The null check for context and the message size check before scrolling prevent potential crashes and improve robustness.
Also applies to: 200-202
207-214: Excellent code reuse with the helper method.The
fromMessage()helper method centralizes the conversion logic fromConnectMessagingMessageRecordtoConnectMessageChatData, promoting consistency and reducing code duplication. The logic correctly maps all required fields including the newmessageId.app/src/org/commcare/adapters/ConnectMessageAdapter.java (3)
37-40: Efficient message addition method.The
addMessage()method correctly appends the new message and usesnotifyItemInserted()for optimal performance, updating only the newly added item rather than the entire dataset.
67-98: Excellent architecture with the base view holder.The
BaseMessageViewHolderclass successfully unifies the binding logic for both left and right message views. The use ofinstanceofto determine binding type is appropriate given the limited number of view types. The binding logic correctly:
- Applies markdown formatting to message text
- Formats timestamps using
DateUtils.FORMAT_HUMAN_READABLE_SHORT- Updates read status icons for outgoing messages
This refactoring significantly reduces code duplication and centralizes message binding logic.
102-102: Consistent return type change.Updating the return type to
BaseMessageViewHoldermaintains consistency with the new architecture and enables polymorphic usage of the view holders.
Comment on lines
163
to
169
| if (!success) { | ||
| Toast.makeText(requireContext(), getString(R.string.connect_messaging_send_message_fail_msg), Toast.LENGTH_SHORT).show(); | ||
| // Update UI to show send failure state | ||
| message.setConfirmed(false); | ||
| ConnectMessagingDatabaseHelper.storeMessagingMessage(requireContext(), message); | ||
| } else { | ||
| chat.setMessageRead(success); | ||
| adapter.updateMessageReadStatus(chat); | ||
| binding.rvChat.scrollToPosition(adapter.getItemCount() - 1); | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Review the message send callback logic.
The success callback updates the chat data's read status and calls updateMessageReadStatus(), but there's a potential issue: the local chat object is modified and passed to the adapter, but this doesn't update the actual database record's confirmation status.
Consider updating the database record's confirmation status as well, or ensure the adapter method handles the database update internally.
} else {
chat.setMessageRead(success);
+ message.setConfirmed(success);
+ ConnectMessagingDatabaseHelper.storeMessagingMessage(requireContext(), message);
adapter.updateMessageReadStatus(chat);
binding.rvChat.scrollToPosition(adapter.getItemCount() - 1);
}Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java
around lines 163 to 169, the success callback updates the local chat object's
read status and calls adapter.updateMessageReadStatus(chat), but this does not
update the confirmation status in the database. To fix this, ensure that the
database record corresponding to the chat message is updated with the new
confirmation status before or within the adapter update call, so the change
persists beyond the local object modification.
shubham1g5
requested changes
Jul 2, 2025
app/src/org/commcare/android/database/connect/models/ConnectMessagingChannelRecord.java
Outdated
Show resolved
Hide resolved
app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java
Outdated
Show resolved
Hide resolved
app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java
Outdated
Show resolved
Hide resolved
app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java
Outdated
Show resolved
Hide resolved
app/src/org/commcare/fragments/connectMessaging/ConnectMessageFragment.java
Outdated
Show resolved
Hide resolved
shubham1g5
requested changes
Jul 15, 2025
| } | ||
| } catch (IOException e) { | ||
| Logger.log(LogTypes.TYPE_EXCEPTION, "Exception occurred while handling received encryption key"); | ||
| Logger.exception(LogTypes.TYPE_EXCEPTION, new Throwable("Exception occurred while handling received encryption key")); |
Contributor
There was a problem hiding this comment.
This is how we generally log exceptions to retain the whole stacktrace of the original exception - Logger.exception("Exception occurred while handling received encryption key", e );
Comment on lines
147
to
152
| RecyclerView.Adapter<?> adapter = binding.rvChat.getAdapter(); | ||
| if (adapter != null) { | ||
| int numItems = adapter.getItemCount(); | ||
| if (numItems > 0) { | ||
| scrollToLatestMessage(); | ||
| } |
Contributor
There was a problem hiding this comment.
we can simply just call scrollToLatestMessage directly as it does the same checks as done here on adapter count.
app/res/values/strings.xml
Outdated
Comment on lines
389
to
390
| <string name="you">You</string> | ||
| <string name="them">Them</string> |
Contributor
There was a problem hiding this comment.
will need to be added in all languages.
shubham1g5
reviewed
Jul 15, 2025
Contributor
shubham1g5
left a comment
shubham1g5
left a comment
There was a problem hiding this comment.
one final request, rest seems good
| int viewType = message.getIsOutgoing() ? ConnectMessageAdapter.RIGHTVIEW : ConnectMessageAdapter.LEFTVIEW; | ||
| return new ConnectMessageChatData(message.getMessageId(), viewType, | ||
| message.getMessage(), | ||
| message.getIsOutgoing() ? getString(R.string.you) : getString(R.string.them), |
Contributor
There was a problem hiding this comment.
we should name the keys as connect_message_you and connect_message_them instead.
Contributor
Author
There was a problem hiding this comment.
Yeah thinking for that but not done purposefully as same string can be used at other places also.
Contributor
There was a problem hiding this comment.
We want to maintain one to one mapping between string resources and UI elements in order to allow for different translations per UI element even if they say similar things. That is one might want to replace "You" with 2 different interpretations of you in that particular languagge based on the Ui context there.
shubham1g5
approved these changes
Jul 15, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Technical Summary
https://dimagi.atlassian.net/browse/CCCT-1060
Labels and Review