-
Notifications
You must be signed in to change notification settings - Fork 16
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
Exploratory pr for native image picker #509
Exploratory pr for native image picker #509
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking pretty good to me. Main thing is that we need to make sure we're getting exif data natively, rather than through the image picker's JS code.
If we can make the navigation feel a little smoother when closing the modal, that would also be a nice improvement.
import { Platform } from "react-native"; | ||
import ImagePicker from "react-native-image-crop-picker"; | ||
|
||
const handleIosImage = image => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of getting exif data from JavaScript, can we use our native exif reader code?
This exif data should be more reliable and easy to use (per this issue: #144)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, could explain more on the reliable/easy part?
react-native-image-crop-picker
pulls the exif data natively, but there is no normalization layer, so the shape/attributes for ios/android simply come back differently. This js code just normalizes data so the app can use it effectively.
I ask this because native-exif-reader
isn't able to use the files from react-native-image-crop-picker
, not exactly sure why
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kueda, any thoughts on this? I know Yaron spent a while making sure we can get exif data natively, but I'm not 100% certain why we need that or if that's a dealbreaker here for using react-native-image-crop-picker
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@budowski did this work as a part of #144. I believe we wrote our own EXIF library because we were unable to consistently extract GPSHPositioningError
using existing react native libraries. @Chrischuck, this image should have that tag. Are you seeing it getting extracted with your code in this branch on both iOS and Android?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kueda looks like it isn't able to get that tag. If I recall, react-native-image-picker
worked fine w/ exif reader but the resizer didn't like it. Might be easier to go that route and just find a different resizer library
@@ -185,6 +185,7 @@ const PhotoGallery = ( ): Node => { | |||
navToObsEdit( ); | |||
return; | |||
} | |||
|
|||
navigation.navigate( "GroupPhotos", { selectedPhotos } ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure if this is an issue specific to this PR, but I noticed that the number of observations never updates on the GroupPhotos screen when combining, separating, or deleting photos. And number of photos is also incorrect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I noticed that too when I first worked on this. I wasn't exactly sure and didnt look into how they were calculated
), [] ); | ||
|
||
const createObservationFromGalleryPhoto = useCallback( async photo => { | ||
const originalPhotoUri = photo?.image?.uri; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this code should not be removed -- we want to get exif data using these methods.
@@ -32,7 +33,17 @@ const AddObsModal = ( { closeModal }: Props ): React.Node => { | |||
closeModal( ); | |||
}; | |||
|
|||
const navToPhotoGallery = ( ) => navAndCloseModal( "PhotoGallery" ); | |||
const navToPhotoGallery = async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a way to make the navigation experience smoother after closing the image picker? It seems a little glitchy to me that the modal closes and the user sees MyObservations with the AddObsModal still pulled up before navigating to the next screen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really sure on this one unless there's an intermediary page that's behind the image picker when it's up.
Also if AddObsModal
, the call to selectImagesFromGallery
gets destroyed.
currently in inat ios, the behavior is similar but when the image picker closes, there is a loading state
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this isn't ideal, but I think it's fine for now. We could have some empty intermediate as Chris suggested, but I think this is more a question for Abhas when this is ready for him to look at.
3983591
to
e2b4322
Compare
I gave I tried I think if this pr goes in, |
e2b4322
to
29420ad
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One minor requested fix, but the bigger issue is lack of access to the original so we can use our own exif parser and get at GPSHPositioningError
. @Chrischuck do you want to using https://github.com/IceOfSummer/react-native-image-picker as instead of the main repo and seeing if you can get https://github.com/inaturalist/react-native-exif-reader working with the origina file path from that? If that works and that PR never gets merged, maybe it's worth maintaining our own fork.
pickerParams.compressImageMaxHeight = 2048; | ||
} | ||
|
||
const selectedImages = await ImagePicker.openPicker( pickerParams ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this raises an exception that we need to handle if the user backs out of the image picker in Android.
@@ -32,7 +33,17 @@ const AddObsModal = ( { closeModal }: Props ): React.Node => { | |||
closeModal( ); | |||
}; | |||
|
|||
const navToPhotoGallery = ( ) => navAndCloseModal( "PhotoGallery" ); | |||
const navToPhotoGallery = async () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree this isn't ideal, but I think it's fine for now. We could have some empty intermediate as Chris suggested, but I think this is more a question for Abhas when this is ready for him to look at.
@kueda I gave another forked repo a try that was supposed to give the original filepath, I forgot which one... But anyway I can give the one IceOfSummer fixed a shot. I'm also thinking it might be better to fork one of those repos and maintain under inaturalist, unfortunately, all of the maintenance on the photo pickers seems dead. |
Cool.
Maybe. https://github.com/react-native-image-picker/react-native-image-picker seems somewhat alive, though they don't seem to be reviewing PRs. If you can get that IceOfSummer fork to work with our exif parser, I think that's probably worth maintaining a fork for. |
@kueda Will probably open up another pr for this. But I'll get to it saturday or sunday |
@kueda unfortunately, IceOfSummer's fix only works for android. I tried to updating the code to get the original file path for ios, but I don't know enough on that side to get anything going... I ended up having to fork IceOfSummer's repo and publishing to npm. Trying to install directly from github got some build issues because of TS. |
I'm going to close this b/c @budowski is working on a custom fork of that package and will do the work in this repo in a separate branch. Definitely appreciate the work here, though, @Chrischuck. |
#431
android
android-test.mov
ios 14.5
old-ios.mov
ios
ios-test.mov