Show file upload progress and placeholder media message in chat. - #6327
Show file upload progress and placeholder media message in chat.#6327mahibi wants to merge 3 commits into
Conversation
75e9f18 to
9e857a9
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/27197628252/artifacts/7504764435 |
9e857a9 to
43b3d2d
Compare
|
rebased on master and fixed conflicts. Will pick it up whenever time allows |
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/31166324927/artifacts/8989488940 |
Signed-off-by: Jens Zalzala <jens@shakingearthdigital.com> # Conflicts: # gradle/verification-keyring.keys
App compiles but the upload progress is buggy Signed-off-by: Marcel Hibbe <dev@mhibbe.de>
Bundles the fixes and follow-up polish for the upload-progress/placeholder
feature from the recent merge-conflict cleanup:
Correctness fixes:
- UploadAndShareFilesWorker called shareFile() unconditionally after every
successful upload, even though two other paths already share the file
themselves: ChunkedFileUploader still had a leftover
ShareOperationWorker.shareFile() call, so any chunked upload (files >1MB)
without conversation subfolders posted the attachment twice; and
conversation-subfolder uploads already share via postConversationAttachment,
so the extra call tried to share a path the file was never uploaded to,
failed, and incorrectly marked successful uploads as FAILED.
- uploadUsingConversationSubfolders() sent a freshly generated UUID as the
message's referenceId instead of the placeholder's actual referenceId, so
the server echoed back the wrong id and the temp placeholder could never
be matched against the real incoming message, leaving it stuck forever.
- sendUnsentChatMessages() (resend-on-reconnect) picked up FAILED upload
placeholders and reposted their "{file}" sentinel text as a bogus new
message. Placeholders with a file attachment are now excluded from that
resend path.
- The "upload completed" signal that triggers an immediate message refetch
was commented out, so a successfully uploaded video's placeholder could
spin forever until the chat was closed and reopened.
- Coil's AsyncImage never showed a composable-supplied fallback painter when
passed a pre-built ImageRequest with null data, so previews without a
server URL (e.g. video with no server preview) silently fell back to
Coil's own null-data handling instead of our local first-frame image.
Reliability:
- UploadAndShareFilesWorker now retries transient network failures (socket
resets, timeouts) with backoff and a network-connected constraint instead
of failing immediately, up to a bounded number of attempts.
UI/UX:
- Replaced the linear upload progress bar with a WhatsApp-style circular
spinner overlay (with cancel button) centered on the thumbnail, and fixed
a metadata-layout bug that left a padding gap next to the placeholder.
- Removed the persistent Android notifications duplicating in-chat upload/
compression progress; kept the upload-failed notification.
- Stopped treating a file's name as its caption; only real captions are
shown, matching how sent messages already behave.
- Sized the video upload placeholder to the video's real aspect ratio
(16:9 fallback) instead of collapsing to a small generic icon.
- Added a local-first-frame fallback, cached to disk keyed by referenceId,
for videos whose server preview is unavailable, so they don't show a
generic icon indefinitely.
- The play button overlay now shows on all video messages (not just ones
with a server preview) with a WhatsApp-style semi-transparent dark circle
behind it.
Assisted-by: Claude:claude-sonnet-5
43b3d2d to
361a69c
Compare
|
APK file: https://github.com/nextcloud/talk-android/actions/runs/31283341796/artifacts/9029143403 |
| // 3. It is always positive, because getMessagesEqualOrNewerThan expects it to be larger | ||
| // than oldestMessageId | ||
| @Suppress("MagicNumber") | ||
| val placeholderId = (referenceId.hashCode().toLong() and 0x7FFF_FFFFL) |
There was a problem hiding this comment.
uh, this gave me some headace while testing other branches.
I was wondering why enriching notifications always failed for one conversation.
There was always a followup notification with delete=true which removed the notifiaction on server and enriching resulted in 404.
Same symptom as described in #6330
Apparently i tested the current branch a few days ago and my lastReadMessage was set to 1963726147. So all notifications were immediately deleted, of course also when testing other branches.
- This placeholderId must be changed!!
2 participants
resolve #2375
copied the PR #6047 from @anakin78z to the nextcloud repo as he won't find the time to continue.
I will
Thank you @anakin78z for this initial code!
馃弫 Checklist
/backport to stable-xx.x