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

[expo-media-library] [Android] Flip dimensions based on media rotation data #7980

Merged
merged 3 commits into from May 8, 2020

Conversation

Ashoat
Copy link
Contributor

@Ashoat Ashoat commented Apr 24, 2020

Why

Right now, the dimensions returned by MediaLibrary.getAssetsAsync on Android do not consider rotation data. In contrast, the iOS version of the module flips the dimensions. In my case, I rely on these dimension values to render appropriately sized containers for media while it is loading. <Image> and <Video> both consider rotation data when rendering media.

How

It basically fetches EXIF data for photos and uses MediaMetadataRetriever for videos.

Test Plan

I am using this patch on my app in production. I've tried it on an old Android 4.4 device as well as newer emulators. I've tried it with photos and video.

I hesitated a bit in putting up this PR because I haven't been able to do it full diligence. I haven't analyzed its performance impacts across the spectrum of older devices and I'm missing tests. I don't think I'll be able to get those things done soon, but I wanted to share this patch to at least get a conversation started.

@@ -56,8 +56,8 @@
put(SORT_BY_CREATION_TIME, MediaStore.Images.Media.DATE_TAKEN);
put(SORT_BY_MODIFICATION_TIME, MediaStore.Images.Media.DATE_MODIFIED);
put(SORT_BY_MEDIA_TYPE, MediaStore.Files.FileColumns.MEDIA_TYPE);
put(SORT_BY_WIDTH, MediaStore.Images.Media.WIDTH);
put(SORT_BY_HEIGHT, MediaStore.Images.Media.HEIGHT);
put(SORT_BY_WIDTH, MediaStore.MediaColumns.WIDTH);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't exactly recall if this change was necessary. I think my intention was to use a media-type-agnostic identifier here, with the hope that it would help for videos

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into this a bit more. These two constants are exactly the same.

I think I prefer MediaStore.MediaColumns.WIDTH since the name doesn't appear to be image-specific, but I can revert these changes in the interest of preserving git blame. Let me know!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, if there are the same and we also use them when we deal with videos, MediaColumns is better ;)

Thank for investigating this 🥇

Copy link
Contributor

@lukmccall lukmccall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, left some comments though 😄

Comment on lines -223 to -225
if ((cursor.getType(widthIndex) == Cursor.FIELD_TYPE_NULL ||
cursor.getType(heightIndex) == Cursor.FIELD_TYPE_NULL) &&
mediaType == Files.FileColumns.MEDIA_TYPE_IMAGE) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it safe to omit these conditions?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, good catch. The getType checks shouldn't be necessary, but we should keep the mediaType check, if only to avoid the perf hit of a useless check

Copy link
Contributor Author

@Ashoat Ashoat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks so much for the prompt review!

@@ -56,8 +56,8 @@
put(SORT_BY_CREATION_TIME, MediaStore.Images.Media.DATE_TAKEN);
put(SORT_BY_MODIFICATION_TIME, MediaStore.Images.Media.DATE_MODIFIED);
put(SORT_BY_MEDIA_TYPE, MediaStore.Files.FileColumns.MEDIA_TYPE);
put(SORT_BY_WIDTH, MediaStore.Images.Media.WIDTH);
put(SORT_BY_HEIGHT, MediaStore.Images.Media.HEIGHT);
put(SORT_BY_WIDTH, MediaStore.MediaColumns.WIDTH);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into this a bit more. These two constants are exactly the same.

I think I prefer MediaStore.MediaColumns.WIDTH since the name doesn't appear to be image-specific, but I can revert these changes in the interest of preserving git blame. Let me know!

Comment on lines -223 to -225
if ((cursor.getType(widthIndex) == Cursor.FIELD_TYPE_NULL ||
cursor.getType(heightIndex) == Cursor.FIELD_TYPE_NULL) &&
mediaType == Files.FileColumns.MEDIA_TYPE_IMAGE) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, good catch. The getType checks shouldn't be necessary, but we should keep the mediaType check, if only to avoid the perf hit of a useless check

@Ashoat
Copy link
Contributor Author

Ashoat commented May 6, 2020

Ping! :)

@lukmccall
Copy link
Contributor

@Ashoat, sorry for the late response 🙇‍♂️Please, add a changelog entry. To do it, edit packages/expo-image-picker/CHANGELOG.md. It'll be nice if you rebase your branch once more, cause the CI failed. If this doesn't help, don't bother. I'll check it ;)

@Ashoat
Copy link
Contributor Author

Ashoat commented May 7, 2020

Rebased and added the CHANGELOG.md entry!

@lukmccall
Copy link
Contributor

Thanks 🥇I'll wait for the CI. If everything will be green, I will merge it. Great job 🎉

Copy link
Contributor

@lukmccall lukmccall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🏅

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.

None yet

2 participants