Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature modification] default save to pictures, enable custom save locations #789

Closed
a1994sc opened this issue Sep 26, 2020 · 13 comments
Closed

Comments

@a1994sc
Copy link

a1994sc commented Sep 26, 2020

With 1.14 it now always prompts where to save pictures and videos, can we set a default folder to save in? And a checkbox to have the prompt to save a different folder? Thank you for your hard work!

@QuantumBadger
Copy link
Owner

To anyone who wants to work on this issue: it looks like this should be possible using the EXTRA_INITIAL_URI parameter, but only on API 26+ (Android 8.0+).

https://developer.android.com/reference/android/provider/DocumentsContract#EXTRA_INITIAL_URI

We could remember the last save location and use that, maybe even on a per-subreddit basis.

@Wyld-One
Copy link

How about just a '1-click image save' menu option? That way it can be a custom menu choice.
Then add another menu item to 'set default/recent location'

@QuantumBadger
Copy link
Owner

QuantumBadger commented Sep 27, 2020

How about just a '1-click image save' menu option? That way it can be a custom menu choice.

This may or may not be possible with the Storage Access Framework APIs. It might be possible to (from the settings) send the user to the SAF UI to chose a download directory, and then save using something like this:

https://stackoverflow.com/questions/45924864/saving-an-image-after-getting-folder-from-storage-access-framework-ui

However we might lose permission to write to that directory after a reboot/app restart.

@railroadeda3
Copy link

The "always save as" change totally destroyed the usability of readreader for me. Now, it downloads large files a second time and after a loooong time pops up a separate app over whatever you might be doing and after hitting save there, the file still takes ages to appear in gallery.

Before that, if you had opened an image or video, save used to save it without delay and it was immediately available.

I came here looking for a way to disable it and go back to the old usable behaviour.

@ghost
Copy link

ghost commented Nov 10, 2020

With 1.14 it now always prompts where to save pictures and videos, can we set a default folder to save in? ...

I came here looking for a way to disable it and go back to the old usable behaviour. ..

Fully agre on if not revert fully old behaviour (as it exists in v1.13), then at least add option "Use old method for saving".

Additionally, RedReader v1.14 saving media issue fully unsolvable on Android 5.1, see related bug report on NewPipe:

... and solution/patch used to solve this issue:

@QuantumBadger
Copy link
Owner

Just to be clear, the v1.13 method of saving files doesn't exist in Android any more, as of Android 10 -- this was the reason I changed the app to use the Storage Access Framework. So it's not as simple as just reverting!

Reading and writing files on Android is now a horrifying maze of poorly documented techniques, but in terms of saving downloads:

  1. On Android 4.4 and above, it's possible to use the SAF to show a prompt, allowing the user to choose a save location. This is what RedReader v1.14 currently does on Android 5.0+.

  2. On Android 10 and above, it's possible to use the ContentResolver to insert files into the MediaStore.Downloads collection, without any special permissions. This isn't possible on Android 9 and below.

  3. On Android 6 to Android 9, it's possible to request runtime write permissions, and use the POSIX file APIs to save files to pretty much anywhere you like.

  4. On older versions of Android, you can write files using the POSIX APIs if you have an install-time write permission.

Version 1.13 did (3). Version 1.14 does (1) on Android 5.0+, and (3) otherwise. As far as I know, the v1.14 technique should work on every device.

I think the most sensible solution here is to have a preference for download location, which can be set to either:

  • Prompt every time (method 1)
  • Save to Downloads (method 2 or 3 depending on OS version)

Setting the preference to "Save to Downloads" would mean there'd be no prompts/user interaction after selecting "Save Image". But you wouldn't be able to select a custom directory, it would just go to your Downloads folder.

If it's set to "Prompt every time", it's theoretically possible to set a default location for the save activity to open at, using the EXTRA_INITIAL_URI parameter I mentioned above.

If anyone's aware of better solutions (or there's a mistake somewhere above) then please let me know.

@ghost
Copy link

ghost commented Nov 14, 2020

Version 1.14 does (1) on Android 5.0+

This not work o Android 5.0+ with MIUI at least, read threads listed in my comment above, especially this comment:

Well it seems to me that this asf filepicker acticity is not available on MIUI, which otherwise is on other android 5.x+ phones. @kapodamy was it complicated to activate that internal filepicker activity again, or did you do this already, and on @Symbian9 it still does show this error? If so we would need to add a manual setting for which IO to use.

So, I may test nightly builds if you would built one with same patch as used in NewPipe.

Otherwise, it would be good to create separate builds of RedReader, one of which would be targeted for older Android and use "legacy" method of saving files (as it appears in 1.13).

@QuantumBadger
Copy link
Owner

@Symbian9 The "Save to Downloads" option I mentioned above would work correctly on non-confirmant MIUI ROMs, because it won't show a prompt. It would use the legacy behaviour if you're using Android 9 or below.

There are some details here which may help you resolve the issue on your phone (by enabling the documents app), which should allow either method to work.

@ghost
Copy link

ghost commented Nov 14, 2020

There are some details here which may help you resolve the issue on your phone (by enabling the "Documents" app)

With previous RedReader versions it works normally without dependency on "Documents" app & that is why I'm requesting old method to be used for Android 5.x as it implemented in NewPipe.

@QuantumBadger
Copy link
Owner

@Symbian9 As I keep saying, the "Save to Downloads" option would use the old v1.13 method on old Android ROMs (4.4 to 9.0).

QuantumBadger added a commit that referenced this issue Nov 14, 2020
@QuantumBadger
Copy link
Owner

QuantumBadger commented Nov 14, 2020

I've added the new preference in Alpha 232:

https://redreader.org/alpha/

There are two options for download location:

  • Ask every time: current v1.14 behaviour
  • System default
    • On Android 10+, saves to the MediaStore.Downloads collection
    • On Android 9 and below, uses the v1.13 behavior (saves to Pictures)

Everyone please feel free to try it out and let me know if it works for you!

I've also fixed the re-download issue mentioned by @railroadeda3, which was caused by viewing and precaching images as the anonymous user, but saving them as the logged-in user (meaning the anon cache wasn't used).

@QuantumBadger
Copy link
Owner

Raised #805 to cover remembering the last save location in the prompt, closing this issue.

@japanesephundroid
Copy link

There are two options for download location:

  • Ask every time: current v1.14 behaviour

  • System default

    • On Android 10+, saves to the MediaStore.Downloads collection
    • On Android 9 and below, uses the v1.13 behavior (saves to Pictures)

Everyone please feel free to try it out and let me know if it works for you!

I've also fixed the re-download issue mentioned by @railroadeda3, which was caused by viewing and precaching images as the anonymous user, but saving them as the logged-in user (meaning the anon cache wasn't used).

The new setting works for me on Android 8, all downloads go to Pictures like before, and they don't redownload so the other fix works as well.

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

No branches or pull requests

5 participants