Image picker - deleting the new photo


#1

I’m trying to build a simple app which uploads a photograph to my server then deletes the copy held on the phone. I thought I’d got it working then realised that although Expo.ImagePicker.launchImageLibraryAsync seems to provide a URI to a file held in an accessible cache directory there’s also a copy stored elsewhere on the phone.

Is there a way to prevent two copies of the photograph being created or if not is there a way to delete the file stored in the Pictures directory (on Android - not tested yet on iOS)?


#2

I noticed the same behavior on my android phone and what also like to know how to prevent this or at least get a path to the image stored on the phone and then delete it with the new file api.


#3

Just tested and it doesn’t appear to be a problem in iOS.


#4

Hey all! Thanks for reporting this.

If you’re interested you can see the Android implementation of the ImagePicker here: https://github.com/expo/expo/blob/20ffb03528de050aac6611a7c4ce39feb8025e02/android/expoview/src/main/java/versioned/host/exp/exponent/modules/api/ImagePickerModule.java#L297

But yeah as you can see it just writes the file out to a place in the Expo FileSystem that is accessible from the app. Do you think it would make sense to expose an option that allows you to specify if you want to delete the original file? Wondering what the default for that should be too.


#5

Created a GitHub issue to track this here: https://github.com/expo/expo/issues/449

It may make more sense to weigh in there because the team will be looking there more often probably.


#6

Thanks for the response Nikki, I’ll keep an eye on the GitHub issue but to me it makes sense for the original to be deleted by default, mostly because that’s the current iOS behaviour.


#7

@nikki any news on this issue?


#8

is it possible to delete where filepath is the name of the picture, for example : file:///storage/emulated/0/Pictures/IMG_20170926_134921.jpg ?

i used Expo.FileSystem.deleteAsync(filepath), but the error shows the file isn’t deletable