-
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.
| val address = Address.fromSerialized(addressStr) | ||
|
|
||
| // Fetch the current ThreadRecord for this address | ||
| val thread = threadDb.getThreads(listOf(address)).firstOrNull() ?: return |
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.
Doing db access on the main thread should be a massive red flag.
There shouldn't be a need to calculate anything in the activity anyway as the VM should hold all the required information
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.
Will update this to get the ThreadRecord from data in the viewmodel then.
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 is a situation where you need to look at who is using this and ask yourself: Do we really need to pass a threadRecord everywhere?
Most of the places using this are probably only using an address, which you already have from the sheet's arguments
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 the threadRecord is fine here. Most of the methods rely on the Recipient rather than just the address itself. If we get the recipient from the address, wouldn't that require additional repo and suspend calls?
app/src/main/java/org/thoughtcrime/securesms/home/ConversationOptionsBottomSheet.kt
Show resolved
Hide resolved
app/src/main/java/org/thoughtcrime/securesms/webrtc/CallManager.kt
Outdated
Show resolved
Hide resolved
app/src/main/java/org/thoughtcrime/securesms/conversation/v2/ConversationReactionOverlay.kt
Show resolved
Hide resolved
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 wonder if this fragment can be handled in a more intelligent way. Currently it gets destroyed and recreated every time we rotate. Don't we have legitimate ways to handle the rotation internally in the fragment without recreating it? Essentially like the forced portrait was doing, but in a way that works for the new rules of Android 16?
…android into improvements/ses-4433
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:
|
This PR removes portrait lock.
This PR also adds some new composables for different orientations.
TODO: Full end to end testing for landscape.