Fix/external upload limit

[Kota-Jagadeesh]

What changes did you make and why?

This PR addresses an issue where sharing more files than the allowed limit (currently 20) via an external application (like a gallery) caused an unnecessary delay and poor user experience before blocking the upload.

Changes Made

1. Centralized Constant: Added the upload limit (MAX_UPLOAD_COUNT = 20) in CustomSelectorActivity.kt to a shared companion object constant for reuse across the app.
2. Early Limit Check (UploadActivity.kt): Implemented an immediate file count check within receiveExternalSharedItems(). This check accesses the file count directly from the incoming Intent's URI list, allowing the app to:
   • Show the "Upload Limit Exceeded" dialog immediately without any delay, if the limit is breached.
   • Skip the time-consuming file reading/processing (contributionController.handleExternalImagesPicked) for oversized selections, eliminating the previous "white screen" delay.

Testing Instructions

1. Open an external gallery app (e.g., Google Photos).
2. Select 21 or more images.
3. Tap Share and choose Wikimedia Commons.
4. Expected Result: The "Upload Limit Exceeded" dialog appears immediately without a long white screen delay. Tapping "OK" closes the activity and returns back to the app.
5. Select 20 or fewer images.
6. Expected Result: Upload activity proceeds normally.

Tests performed (required)

• Tested {ProdDebug} on Redmi note 13 5g with API level 35.

Screenshots:

[nicolas-raoul]

Would it be possible to just truncate the list, letting the user upload 20 of the files?
From the user's point of view, selecting the files may have taken time, maybe they selected 21 instead of 20, in which case just removing 1 would be nicer.
What do you think? :-)

[Kota-Jagadeesh]

That's a fantastic suggestion! acc to me : )

I agree that truncating the list to 20 files is significantly more user-friendly than forcing them to go back and reselect, especially after they've taken the time to choose their media.

I can certainly adjust the logic. The key is to keep the early check to avoid the initial "white screen" delay, but instead of calling the dialog, we'll simply pass a sliced list of the first 20 URIs to the file handling function.

Solution for thes : Truncate and Notify

1. In receiveExternalSharedItems(), we'll still check the fileCount early.
2. If fileCount > MAX_UPLOAD_COUNT (20), we truncate the list of URIs to the first 20 items.
3. We then proceed with the heavy file processing, but only for the first 20 files.
4. After the upload activity fully loads, we'll show a non-blocking toast/snackbar notification to the user, informing them that only the first 20 files were loaded. This provides feedback without stopping their workflow.

I will implement this truncation logic now and update the PR. Thanks for the review!

[Kota-Jagadeesh]

Made the required chanegs and updated the branch

[nicolas-raoul]

(first step of review: I just confirmed that currently the non-custom picker lets users upload more than 20 pictures at once)

[RitikaPahwa4444]

I'm not sure how feasible it is but is it possible to batch load instead of truncating the list? Minor comment, otherwise :)

[RitikaPahwa4444]

Should this be a part of the custom selector activity if we're extending this logic to other activities as well?

[Kota-Jagadeesh]

Should this be a part of the custom selector activity if we're extending this logic to other activities as well?

I feel centralizing the the upload limit constant by placing it in the constants.kt would be better

[github-actions]

✅ Generated APK variants!

• 🤖 Download betaDebugAPK
• 🤖 Download prodDebugAPK

[Kota-Jagadeesh]

I'm not sure how feasible it is but is it possible to batch load instead of truncating the list? Minor comment, otherwise :)

what i feel is that, implementing batch loading for the file URIs would be ideal for very large selections (e.g: 50+ files or smtg) to avoid memory issues during the initial load.

For this issue, the truncation approach is the safest, least intrusive, and most immediate fix to address the usability issue, as it keeps the existing API intact. I recommend sticking with truncation : )

[RitikaPahwa4444]

For this issue, the truncation approach is the safest, least intrusive, and most immediate fix to address the usability issue, as it keeps the existing API intact. I recommend sticking with truncation : )

Which issue? Could you please link it in the PR description? Let's raise another one to explore that possibility.

[nicolas-raoul]

Batch upload would be really complex to implement and maintain. My opinion is that truncating is good enough for now.

I would make sure to show a popup explaining to the user that there it a 20 limit for performance reasons and that their selection is being truncated to 20, though.

In the future, rather than a batch of multi-uploads, I would recommend storing all of the multi-upload's data (images and metadata) in database. That would solve the root problem (large multiuploads being unreliable because they take too much memory).

[RitikaPahwa4444]

@Kota-Jagadeesh why are we closing the PRs?

[Kota-Jagadeesh]

@Kota-Jagadeesh why are we closing the PRs?

There are some merge conflicts. So, I just reverted the changes, the PR will be opened within an hour.