Status Update
No update yet.
Comments
ma...@google.com
We could add an API to make the weighted distance customizable, aosp/3271691 has more info.
lp...@google.com
Is there a reason we wouldn't want to have an overload with required parameters for both?
ma...@google.com
Consider that this pair of parameters will be added to 10+ component as an optional/supplimentary functionality. this will double the api surface while bringing little value
lp...@google.com
I wonder if that's just indicative of a problematic API story / layering in the first place. The other option would be to have a lint check specifically for wear components, without needing the annotation - since this is really more specifically a longClick / a11y label issue. Would be fairly trivial to add a lint check for that
le...@google.com
I think it is an indication of the unfortunate cost of overloads. There are tradeoffs here but this seems like a somewhat reasonable way to describe the desired usage without a combinatorial explosion of APIs.
To me it seems like this issue is in no way wear specific, it just so happens that we are talking about wear APIs here.
That said, adding a generic lint rule capability for this is in a way an endorsement of the pattern itself, so it is probably worth a deeper discussion to make sure we are okay with the tradeoffs
lp...@google.com
Right, I'm a bit worried about the cost of adding an annotation / corresponding lint rule here, as it then means there's a contract we have to maintain for more uses than just this, including those defined by external developers.
Description
```
fun Button(
onClick :() -> Unit,
onLongClick: () -> Unit? = null,
longClickLabel: String = null
)
```
It would be desired to force developers to provide both callback + label or nothing, e.g.
```
fun Foo(
onClick :() -> Unit,
@RequiresSpecifiedParam("longClickLabel")
onLongClick: () -> Unit? = null,
@RequiresSpecifiedParam("onLongClick")
longClickLabel: String = null
)
```
so that it is hard to miss label when you set the callback.
This will spare us the need to create a separate class that holds both callback and label, simplifying the API.