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

"Take picture" should allow saving the picture when the user tries to cancel uploading #812

Closed
whym opened this issue Jul 24, 2017 · 10 comments

Comments

@whym
Copy link
Collaborator

whym commented Jul 24, 2017

When you take a picture from the "Take a picture" action, the file will be stored in cache. You will not be able to retrieve it later from there. If you interrupt or cancel the upload procedure (by pressing the back button or killing the app) and fail to complete, the file will be lost.

(This was different before #727 - the file was to be stored in external storage immediately. However I don't think it's wise to simply go back to using external storage unconditionally.)

Here is how I think it should work:

  • Warn that the file is being lost before letting it happen.
  • Show an option to save it (and to do so, request for external storage permission if not given yet).

I think at least the warning should be added before the next release.

@whym whym added the bug label Jul 24, 2017
@whym whym changed the title "Take a picture" screen should allow saving the picture when the user tries to cancel uploading "Take picture" should allow saving the picture when the user tries to cancel uploading Jul 24, 2017
@misaochan
Copy link
Member

I agree, a warning and the opportunity to save the file in external storage would be good.

@janpio
Copy link
Contributor

janpio commented Jul 28, 2017

I kind of expected the picture to appear in my gallery after I took it, no matter what happens with it in the app. (But I am an iOS user mainly...) Is this done differently in Android by default?

@whym
Copy link
Collaborator Author

whym commented Jul 28, 2017

@janpio Thanks for the suggestion. I went back to the official documentation and it said:

https://developer.android.com/training/camera/photobasics.html#TaskPath

Generally, any photos that the user captures with the device camera should be saved on the device in the public external storage so they are accessible by all apps.

So I think you are right.

In light of this, I'm happy to make it (almost) always save the picture. I'm thinking of two approaches.

Approach A:

  • App checks the ability to save (and requests permission to use external storage as needed).
  • If successful, user takes a picture using this app.
    • App moves to the upload screen (and ask the title and license etc).
    • User cancels uploading.
    • (App asks nothing - the file has already been already saved.)
  • If not successful (mostly because permission has not been given), the picture is not taken and upload fails.

Approach B:

  • User takes a picture using this app.
  • App asks whether you want to save it locally (+permission to use external storage) or skip doing so to upload it.
  • Either way, app moves to the upload screen (and ask the title and license etc).
  • User cancels uploading.
  • If already saved, app asks nothing.
  • If not already saved, app asks whether to save the picture or let it be lost.

Approach A is simpler and close to the way it was. Also, because prompts are used less often in Approach A, it may be more simpler to use. Approach B is more flexible (the user can choose not to save), but may be more complicated to implement and to use.

I'm inclined to go with Approach A because of its simplicity, but still, personally it feels a bit strange to be required to give permission to use external storage to take a picture for an online repository. I don't use other camera-based apps, so it may be just that I'm not familiar with the expected behavior.

@misaochan
Copy link
Member

misaochan commented Jul 28, 2017

What about Approach A with an option (perhaps in Settings) to not use external storage (and thus not save the picture) if a picture is taken with the in-app camera? I can think of a few use cases where users might prefer not to save the file automatically (people with very limited external storage space, perhaps?). However, those use cases might be too few to justify the additional complexity needed for that, so I'm okay with just doing Approach A.

I would be a bit concerned with Approach B because that is one extra popup every single upload for camera users, which makes things more cumbersome. If the user's preference is remembered, then perhaps that would be OK (though in that case, again they would need the ability to modify the preference when they want to, hence the need for a Settings item for this anyway).

ftsalamp added a commit to ftsalamp/apps-android-commons that referenced this issue Aug 10, 2017
ftsalamp added a commit to ftsalamp/apps-android-commons that referenced this issue Aug 10, 2017
@nicolas-raoul
Copy link
Member

Sorry if I missed the point, but what's bad with this approach C?

  1. User takes a picture using the camera button this app.
  2. App saves the pictures locally if it has the permission to.
  3. App then proceeds like currently (metadata, upload, categories). If the app had no storage permission and the user cancels before upload is complete, the apps asks for storage permission and saves if given, or loses the picture if not.

@whym
Copy link
Collaborator Author

whym commented Sep 5, 2017

That's an option, too.

Generally, any photos that the user captures with the device camera should be saved on the device in the public external storage so they are accessible by all apps.

I took this as 'it must be saved as soon as possible', but it might be fine if the file is eventually saved.

C actually sounds preferable to B to me - the idea is the same but the process is simpler.

@sivaraam
Copy link
Member

sivaraam commented Sep 5, 2017

So, is this task assigned to @ftsalamp ?

@nicolas-raoul
Copy link
Member

I can't assign to @ftsalamp strangely... maybe Github limits assignment to only people who have commented on the issue or are part of the organization :-/ @ftsalamp could you please try to leave a comment? :-)

@misaochan
Copy link
Member

misaochan commented Nov 8, 2017

Have we already implemented this? I see @ftsalamp 's PR is closed, but @neslihanturan you have made the necessary fixes, right?

@neslihanturan
Copy link
Collaborator

Yes, closing this then.

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

6 participants