Skip to content
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

run SendRelayedMessageUtil.sendMultipleMsgs() in background #3506

Merged
merged 1 commit into from
Dec 18, 2024

Conversation

adbenitez
Copy link
Member

close #3502

@adbenitez adbenitez requested review from r10s and Hocuri December 18, 2024 15:26
@adbenitez adbenitez self-assigned this Dec 18, 2024
@adbenitez adbenitez added the bug label Dec 18, 2024
Copy link

To test the changes in this pull request, install this apk:
📦 app-preview.apk

@@ -362,7 +362,7 @@ public void onActivityResult(final int reqCode, int resultCode, Intent data) {
for (int i = 0; i < uriCount; i++) {
uriList.add(multipleUris.getItemAt(i).getUri());
}
askSendingFiles(uriList, () -> SendRelayedMessageUtil.sendMultipleMsgs(this, chatId, uriList, null));
askSendingFiles(uriList, () -> SendRelayedMessageUtil.sendMultipleMsgs(this, chatId, uriList));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think, it would have been easier, to leave the existing function as is and dispatch to background from the caller:

            askSendingFiles(uriList, () -> {
                Util.runOnAnyBackgroundThread(() -> {
                    SendRelayedMessageUtil.sendMultipleMsgs(this, chatId, uriList, null));
                }
            }

the thing with the newly added function is that it adds to the mess of not knowing if caller or implementation dispatch to background (as a rule of thumb, to separate concerns, i would go for caller if in doubt: the function remains simple and synchronous, it easier to understand, testable (no issue here) and flexible. the caller handles the complexity of concurrency)

also, we would have two function with nearly the same functionality but totally different names

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is what I did, they are two different functions now, one is synchronous and private, and the public one is async, it is only used in a single place at the moment, so I could do as suggested and call it in background from caller, that doesn't protect against making the same mistake again, but that is just precautions for hypothetical futures, so I will go with the simpler suggested solution for now

Copy link
Member

@r10s r10s left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as discussed above, i would rethink who dispatches.

however, if there are good reasons to go the existing way, i am also fine with that, the suggestion is no blocker :)

@adbenitez adbenitez merged commit 37886cf into main Dec 18, 2024
2 checks passed
@adbenitez adbenitez deleted the adb/issue-3502 branch December 18, 2024 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ANR in SendRelayedMessageUtil.sendMultipleMsgs
2 participants