Skip to content

✏️ [ FEAT REQ ] scheduled message attachments aren't saved locally and can disappear if deleted externally #295

@gavine99

Description

@gavine99

Is your feature request related to a problem? If so, please describe the problem.
scheduled message attachments go missing (without user being notified) if they're deleted from storage before the message is sent.
there's no reasonable way to notify the user a file attached to a scheduled message is deleted from storage because they are not in the quik app at the time.

Image

Describe the feature you'd like
scheduled message attachments to be saved in local app storage area so they can be deleted from other storage and still be sent ok.

Additional context
brain dump;

  • attachments for scheduled messages should be saved in app storage area when message is scheduled. files or cache dir? contents of files dir stays around until explicitly deleted by the app. cache dir can be cleared by user, user clearing cache would cause the same missing attachment issue without the user being made aware. there is no reasonable way to make the user aware of the consequences of a cache clean because it's done by the os settings app
  • will the sms/mms library work with a file uri without a file provider ?? works with current audio-record local storage space files so guessing yes. it temporarily saves mms parts to cache dir now anyway.
  • if using the files dir, a service will be needed - once a day ?? - that cleans up orphaned scheduled attachments in case of fail to delete when scheduled message deleted
  • same service above could be used to clean potentially orphaned audio record files from cache dir which is currently done in compose activity albeit on a background thread. any other housekeeping a once-a-day service should perform ?? a generic 'housekeeping' service that could be extended for future tasks might be nice. service or alarm-triggered task ?? need to research.
  • attachments should retain their original file name when sent. multiple attachments with the same file name will collide if saved to a single directory. need to devise a way to make file names unique on save, but restore original when scheduled message sent. maybe use dirs to separate each attachment to its own 'namespace' ?? ie /files/scheduled-message-id-dir/attachment-unique-id-dir-maybe-a-uuid/attachment-file.ext ??
  • putting attachments for each scheduled message into its own top level dir - /files/scheduled-message-id-dir - would also make the orphan cleanup more efficient by only having to retrieve scheduled message ids from the db rather than attachment info for each message. not a huge deal either way, but better to be more efficient.
  • to minimise storage space; should dupe attachments be recognised and hard-linked ?? sha256 hash ?? does android support hard-linking files ?? research. is this worth the hassle of additional cpu use when storage space is abundant? cpu use could get high-ish if there's a lot of scheduled messages with lots of attachments. could save hash with each attachment so each only hashed once ?? leave this as a potential future enhancement.
  • attachments should only be deleted when scheduled message is explicitly deleted by user. not at send time.
  • should attachments be pre-resized to fit mms size and save a bit of storage space? user may change to a telecoms provider whose mmsc provides larger mms size some time before message is sent. also, user may change mms size setting some time before message is sent. so... no.
  • should there be a dialog warning if the size of all scheduled attachments gets too large ?? how large is too large ? definitely don't want another setting to set too large value. urgh. methinks just alert the user if the attachment can't be saved and, therefore, that the message can't be scheduled because out of storage space. user can then go clear caches on other apps to reclaim space.
  • what have i not considered?

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions