tuskyapp / Tusky

An Android client for the microblogging server Mastodon
https://tusky.app
GNU General Public License v3.0
2.46k stars 387 forks source link

[Feature Request] Notify user that uploaded media will be lost on saving to drafts #1133

Open MasterGroosha opened 5 years ago

MasterGroosha commented 5 years ago

A minor issue, but anyway:

  1. Start composing a new toot.
  2. Add some mediafiles (photo, video)
  3. Press back and save toot as draft.

In this case, mediafiles will be lost (by the way, do they keep being stored on servers as loose objects?), and after restoring draft to post, you have to upload media again.

Even though I think this is pretty obvious, I also think that "Save draft" dialog box should also state "Note: you'll have to re-uploaded mediafiles" or "Note: all uploaded media files will be lost!".


connyduck commented 5 years ago

Saving drafts is a complete mess and needs to be rewritten from scratch 😓

by the way, do they keep being stored on servers as loose objects?

server will clean them up after a while, no idea how long it takes

LukeLR commented 5 years ago

I think, they are stored as loose objects on the instance server, since I seem to have hit my daily upload limit on chaos.social when debugging issue #1367 without having posted a single photo.

TheOtherDoctor commented 4 years ago

So drafts are actually a server-side feature?!? This came as a surprise for me, as I am accessing the same instance account with different devices, but the drafts (as shown in tusky) are completely different ones on the devices (running tusky 10). When they are on the server, I expect them to be same...

Having to worry that drafts might be deleted by the server at some random time would be a rather bad thing - if we knew the server timeout, it would be nice to give the user a notifier on that in the drafts list.

connyduck commented 4 years ago

No drafts are completely client side. But when you compose a toot, the media is uploaded immediately. When you continue on a draft, it reuploads the media, which might not be necessary.

jsoref commented 1 year ago

While it might make sense to rewrite drafts, for the time being, a simple warning would be a good start. Ideally it would cover the content in the pending item that will be lost (so if there's media, mention the media, I'd there's alt text, mention that as well).

In my case, I started an item with a picture and added some alt text. That alt text also appeared to be lost when I went to continue my draft. Note that drafting alt text can easily be a longer process than drafting the main content.

One approach that could help me would be if each attachment was converted into its own draft with the object reference and Alt text serialized as the draft content.

connyduck commented 1 year ago

(Drafts have been rewritten a while ago already)

How about simply extending the "save draft?" dialog message with something like "if you cancel now, media will have to be uploaded again" when media is attached?

nikclayton commented 1 year ago

Perhaps the app should save a copy of the attachments to app storage when a status is saved as a draft, and only upload when it's actually posted?

I appreciate starting uploads immediately makes things faster for the user, but the upload-only-to-save-as-draft approach puts more resource load on servers, and leads to the current situation where the app can lose user data.

vaschw commented 1 year ago

Saving the attachments locally with the draft is also useful if there is no network access. E.g. if the phone is in Airplane Mode during travel, or while hiking in remote areas. The user may wish to use available time to compose a post even though there is no network access. Until photos can be added to offline drafts, these use cases are impossible.