Please comment on this proposed API change which we would like to
implement for 4.1 (RingDing).
Problem:
SetVisible currently accepts null|false|true, where null has the
special meaning 'let data control visibility'. This is a poor
interface because it is too easy to accidentally pass a value of
null. The `visible` attribute cannot be used to ask programmatically
if a view is visible or not for the data-bound case.
Proposal:
1. Add a new attribute `visibility` that is a read/write String and
has values 'visible', 'hidden', 'collapse'. This is implemented by a
setter that maps 'visible' -> true, 'hidden' -> false, 'collapse' ->
null in the old mechanism.
2. Deprecate `setVisible`: issue a warning telling how to get the
same effect with `setVisibility`. Make `visible` reflect the actual
state of the view (do not store the value passed to `setVisible`).
3. In the next major release make `setVisible` a no-op so that
`visible` is read-only and reflects the actual state of the view
(i.e., if `visibility` is 'collapse', it will be true when there is
data and false otherwise).
Evaluation:
Pro: 1) Replaces an error-prone interface. 2) Solves the problem of
programmatically query a view's visible state. 3) Uses an interface
that is compatible with CSS.
Con: 1) Programs will have to be updated to use the new API.
