Skip to content

Added option to prompt for file location on save#299

Draft
RyanTheTechMan wants to merge 8 commits intomoffatman:masterfrom
RyanTheTechMan:feature/download_management
Draft

Added option to prompt for file location on save#299
RyanTheTechMan wants to merge 8 commits intomoffatman:masterfrom
RyanTheTechMan:feature/download_management

Conversation

@RyanTheTechMan
Copy link

To speed up the saving workflow, I added two options that appear when Media save directory is set to "Files":

  • Prompt at last directory: Opens save as dialogue when download button is pressed at the location the last file was saved.
  • Prompt at save directory: Opens save as dialogue when download button is pressed at Media save directory.

For changes in the code, I did as little changes as possible to keep the logic as is. However, I noticed that the saveFileAs function did not offer a way to choose what kind of save as is wanted. I have created an enum that can be passed in on function call to call what ever save as is wanted. This currently only affects IOS as Android implementation does not have this feature yet from what I can tell.

SaveAsDestination is an enum that allows you to bypass the prompt asking where do you want to save. This really only affects IOS at the moment, but if saveAs locations get added to other platforms (such as gallery to android), then this would be used.
@RyanTheTechMan
Copy link
Author

I have not tested changes on Android yet. Unless someone gets there before me, I believe I can do it later today or later this week at the latest.

@moffatman
Copy link
Owner

There is no destinationDir arg on saveFileAs native method on either iOS or Android. You will have to implement that in the native code. I think it's UIDocumentPickerViewController.directoryURL on iOS and DocumentsContract.EXTRA_INITIAL_URI on the intent on Android.

Also don't think this should be a GallerySavePathOrganizing and modify behaviour of download(saveAs: false). If you press the batch download button, you will get 100 prompts to save...

This would fit more as an enhancement to download(saveAs: true) with two new bool settings

  1. Whether to start at "organized" path, or at last-used path (null). In fact I think I already had that exact feature in my todo list somewhere. Then if we have the same native changes described above also in pickDirectory, it would work seamlessly with batch download. the destination folder selection would start in either "organized" or last picked.
  2. Whether "Save as..." opens the file dialog immediately instead of asking about gallery

What I mean by "organized" path is not just the root, by all the way into the subfolder calculated by GallerySavePathOrganizing. Then it would be really easy to save an image alongside others in the thread but with a customized name. One quirk is you can't really compose the proper destinationDir in dart. The "dir" given to use by iOS is a base64 blob that needs to be converted via a bookmark at time-of-use into a usable path. Similar caveats apply to Android where the "dir" is a storage-access-framework ContentResolver URI. So both saveFileAs and pickDirectory would need to take both destinationDir and destinationSubfolders so the final path could be assembled in the native side.

Then to complete your usecase, maybe a way to activate the "Save as" function easier? I started work on making all buttons remappable. But no guarantees when that is done... you could certainly add "save as" into the ContextMenus where it's missing now...

Sorry for wall of text lol I do appreciate the contribution

@RyanTheTechMan
Copy link
Author

There is no destinationDir arg on saveFileAs native method on either iOS or Android. You will have to implement that in the native code. I think it's UIDocumentPickerViewController.directoryURL on iOS and DocumentsContract.EXTRA_INITIAL_URI on the intent on Android.

Sorry! And good catch! I did implement it on the iOS side, however I forgot to add it to the commit! saveFileAs supports destinationDir after I commit. The function returns a path in plain text (/private/var/mobile/...). When destinationDir is null, iOS goes back to the last used directory automatically, and when set to the Media save directory base64, it opens at the provided location.

Also don't think this should be a GallerySavePathOrganizing and modify behaviour of download(saveAs: false). If you press the batch download button, you will get 100 prompts to save...

This is a good point, I'll see how it can be worked into download rather than saveAs.

This would fit more as an enhancement to download(saveAs: true) with two new bool settings

  1. Whether to start at "organized" path, or at last-used path (null). In fact I think I already had that exact feature in my todo list somewhere. Then if we have the same native changes described above also in pickDirectory, it would work seamlessly with batch download. the destination folder selection would start in either "organized" or last picked.
  2. Whether "Save as..." opens the file dialog immediately instead of asking about gallery

What I mean by "organized" path is not just the root, by all the way into the subfolder calculated by GallerySavePathOrganizing. Then it would be really easy to save an image alongside others in the thread but with a customized name. One quirk is you can't really compose the proper destinationDir in dart. The "dir" given to use by iOS is a base64 blob that needs to be converted via a bookmark at time-of-use into a usable path. Similar caveats apply to Android where the "dir" is a storage-access-framework ContentResolver URI. So both saveFileAs and pickDirectory would need to take both destinationDir and destinationSubfolders so the final path could be assembled in the native side.

I can migrate the options out of GallerySavePathOrganizing into to their own option(s).

Then to complete your usecase, maybe a way to activate the "Save as" function easier? I started work on making all buttons remappable. But no guarantees when that is done... you could certainly add "save as" into the ContextMenus where it's missing now...

I'd say that's a pretty good idea; though you can currently hold on Download or Download All (batch) or in the context menu, you can use Download To..., both of which open the Choose save location prompt.

The goal of this commit is to allow for changing what the default action the "download" button does (cloud icon and context menu).

Sorry for wall of text lol I do appreciate the contribution

Thanks for such a quick review before I get lost in the sauce.


Final design and change:
I'll add two new options:

  1. Files open location:
  • Last location DEFAULT (let OS handle the last saved location, this appears to work)
  • Media save directory (not clickable unless media save directory is set to FILES and has a path set)
  • Organized Path (Follows Media save directory + media saving folder structure)
  1. Save-as menu customization: Lists all methods of saving (items shown in media save directory) and allow user to check or uncheck options they want shown in save as menu. If only one option is selected, then it will just jump into that action, skipping save as dialogue.

As another possible feature to be added later on, configuration for the navigation bar! Allow users to change what options appear in different areas of the app.


Below is a way that I was coming up with, but I don't quite like it as much as the final design above.

How about this as a possible way...
Allow the user to choose "primary download behavior", this way "Download To" still acts the same.
Options are something like the following:

  • Prompt every time (Shows Save As popup)
  • Save directly to Media Save Directory (shows "Media save directory" and "Media saving folder structure" options)
  • Files picker (last)
  • Files picker (organized)

Also added warning for when "Media save directory" is changed off of File if there is a settings conflict.
@RyanTheTechMan
Copy link
Author

RyanTheTechMan commented Jan 29, 2026

Mostly done on the iOS side, going to be testing and configuring Android soon.

@moffatman
Copy link
Owner

All the new options and stuff are a mess. i will try to finish the button remap thing now so that all the complexity can be handled there instead. so yeah focus on android is a good idea

@RyanTheTechMan
Copy link
Author

Android and iOS are now working as intended. Once you’ve finished your changes, let me know and I’ll work to resolve the conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants