Status Update
No update yet.
Comments
an...@google.com
Branch: androidx-master-dev
commit 23a7d960caf43390a554700d3c56ada189a9d10e
Author: Louis Pullen-Freilich <lpf@google.com>
Date: Mon Aug 10 15:11:36 2020
IconButton / IconToggleButton API scrub
Test: ./gradlew updateApi
Bug:
Bug:
Relnote: "Adds enabled parameter to IconButton, and reorders parameters in IconToggleButton"
Change-Id: I0a9419b1a631cadad451395302ad87b7f9214f96
M ui/ui-material/api/current.txt
M ui/ui-material/api/public_plus_experimental_current.txt
M ui/ui-material/api/restricted_current.txt
M ui/ui-material/src/commonMain/kotlin/androidx/compose/material/IconButton.kt
js...@google.com
Yeah, point taken, although that might be a matter of semantics. One alternative way of looking at it is that enums and various helper functions are technically all constants, as they aren't values that change over time. IIRC this is partly why FooConstants was chosen over FooDefaults.
I seem to recall that also being mentioned at API Council, and while the name might not be a perfect fit for all circumstances, it is still valuable to be consistent and the new name is better than overloading the same name as the widget which would lead to confusion. If you have an idea for an alternate naming pattern which we haven't considered, I'm sure we'd be happy to re-evaluate.
an...@google.com
js...@google.com
Would IndicatorContainer be used outside a TabRow? If not, perhaps it should be thrown on a receiver scope to make it easy to use from within the proper scope and hard to use from outside a TabRow? The API for IndicatorContainer as it stands today perhaps isn't super discoverable?
I don't have a strong opinion about where the functions live, and there are some judgement calls there, but I don't think that should block the renaming of these objects. Maybe +George or +Adam will have opinions here.
js...@google.com
Interestingly, just looked back at the API Council pod notes, and it makes explicit mention of these caveat:
Scaffold.FabPosition enum conflicts with the above decision about ScaffoldConstants
-> Move FabPosition enum to top-level
Revisit TabRow.Indicator/IndicatorContainer
-> Docs and samples please!
lp...@google.com
One alternative way of looking at it is that enums and various helper functions are technically all constants, as they aren't values that change over time. IIRC this is partly why FooConstants was chosen over FooDefaults.
This seems to be the opposite actually, no? The point is that these numbers are strictly tied to the spec, and so can / will change if the spec updates the internal padding for a Button for example. This allows developers to build their own components, point to these 'defaults', and always be matching the spec. For that reason, Defaults makes more sense to me, as there's no guarantee of stability.
js...@google.com
Constants "won't change over time" as in "are not mutable vars changed by the program during normal execution", as defined by wikipedia:
an...@google.com
ap...@google.com
Branch: androidx-master-dev
commit 7bb5f31e522b202ec7d7eeb1ec468d7795630a75
Author: Andrey Kulikov <andreykulikov@google.com>
Date: Fri Jun 26 12:53:36 2020
Rename Button object to ButtonConstants
Fixes: 159687878
Test: manually
Relnote: Rename Button object (containing the defaults used by Button function) to ButtonConstants
Change-Id: I7c5f7d864984502bc477c3d42896f052b25c1db3
M ui/ui-material/api/0.1.0-dev15.txt
M ui/ui-material/api/current.txt
M ui/ui-material/api/public_plus_experimental_0.1.0-dev15.txt
M ui/ui-material/api/public_plus_experimental_current.txt
M ui/ui-material/api/restricted_0.1.0-dev15.txt
M ui/ui-material/api/restricted_current.txt
M ui/ui-material/samples/src/main/java/androidx/ui/material/samples/ButtonSamples.kt
M ui/ui-material/src/main/java/androidx/ui/material/Button.kt
js...@google.com
What about FilledTextField, and OutlinedTextField?
js...@google.com
What about FilledTextField and OutlinedTextField?
Description
TLDR: The
object Buttonshould be renamedobject ButtonConstants. Similarly we should probably renameScaffold,TabRow,FilledTextField,OutlinedTextField(and are there any others?) to follow the same pattern.As per Compose API Council on April 6, 2020, we decided the public constants for any composable
Fooshould go on an object calledFooConstantsinstead of an object namedFoo. The primary motivation is that there is a naming overload/collision such that when you search for a widget by name in AndroidStudio, you would naturally open the wrong object and then get confused by how it worked, although there were also other similar considerations that pushed us in this direction.