-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Update compose screen UI #7825
Update compose screen UI #7825
Conversation
398cb02
to
f50bc66
Compare
f50bc66
to
da1ed97
Compare
Which version of the design does this implement? |
"Dev handoff May 21 2024" |
|
||
<shape android:shape="rectangle"> | ||
<size android:height="1dp" /> | ||
<solid android:color="?attr/colorSurfaceContainerHighest" /> |
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.
The Material 3 divider color should be colorOutlinedVariant
, see spec
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.
It's not a divider. It simulates the "active indicator" of a text field. But the design team made the conscious choice to use surface-container-highest
instead of on-surface-variant
.
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.
If it's an active indicator then it should be on-surface-variant
, then why deviate from the spec?
<item android:gravity="bottom"> | ||
<shape android:shape="rectangle"> | ||
<size android:height="1dp" /> | ||
<solid android:color="?attr/colorSurfaceContainerHighest" /> |
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.
See above
android:bottom="-8dp" | ||
android:left="-16dp" | ||
android:right="-16dp"> |
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 looks like a hack instead of a solution. Why can't the layout use standard view components and arrangements? It's also a suprising behavior when looking at the xml layout.
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 drawable behaves very similar to the old default background for an EditText
(a 9-patch that includes implicit padding).
There are no standard components to build the current layout. We could create a custom component based on TextInputLayout
. But why invest time in creating custom views (that look more or less exactly like what we have now) when we want to switch to Compose UI anyway?
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 about a standard text field? And since when do we plan to rewrite this screen to compose?
In a meeting with the design team we decided to postpone changes to the compose screen. |
Note: The background drawables are using a feature only available on API 23+. The app still runs on lower API levels, but the input field background is looking off. I'll create a separate PR to increase the
minSdkVersion
to 23.