-
Notifications
You must be signed in to change notification settings - Fork 46
SES-4433 : Handle landscape mode #1527
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
base: dev
Are you sure you want to change the base?
SES-4433 : Handle landscape mode #1527
Conversation
This reverts commit 20a5fa9.
This reverts commit 8c9891d.
| modifier: Modifier = Modifier | ||
| ) { | ||
| Column( | ||
| modifier = modifier.widthIn(max = 420.dp), |
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.
You can use your smallMaximumImgClamp which maybe can be renamed to something more meaningful since it doesn't apply only to images, but to content. maxContentSizeSmall ? Which means the other ones would need to be renamed as well
|
Some issues from the latest changes:
|
| typeMask: Int = WindowInsetsCompat.Type.systemBars() or WindowInsetsCompat.Type.ime(), | ||
| additionalInsets : Insets = Insets.NONE // for additional offsets | ||
| additionalInsets : Insets = Insets.NONE, // for additional offsets | ||
| applyTop: Boolean = true, |
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 feel like this is a bit applying a band aid on top of a band aid.
We already have a method for setting up insets but now we're adding flags to cancel the act we are setting ourselves.
I think the logic is breaking at a higher level.
Is the issue that we are applying a bottom padding to the FAB which then gets sets on the side? If so which should fix that logic rather than adding more patches to the existing function.
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.
Makes sense. The issue is that insets are applied to the sides as well which was intended for this method. For this case, maybe adding a new helper is better?
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.
But there are legitimate side insets to apply. They are used for back gestures, etc..
So we can't ask the system to help us with the displaycutout and then ignore it.
I think the issue is how this is built and how the values are taken into account in landscape vs in portrait.
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.
Yup, I can revert this method. Maybe forcing this method for this Fab is not the right approach since it only ever wants the bottom inset. That was the reason I added such flags in the first place. I can then add a new helper to use for the case of this FAB, wdyt?
| handleCameraImageCaptured(uri, size, width, height) | ||
| } | ||
| }else{ | ||
| if(supportFragmentManager.backStackEntryCount == 0){ |
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.
What is this case covering? Why are we finishing the activity here?
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 will avoid a black screen in the MediaSendActivity finish it for when we press back to "undo" a photo, and then pressing cancelling the CameraActivity.
This PR removes portrait lock.
This PR also adds some new composables for different orientations.
TODO: Full end to end testing for landscape.