TextField with a Keyboard.password doesn’t work as...

# compose

[Guy Bieber]

TextField with a Keyboard.password doesn’t work as expected to hide the password as it is typed. Is there something like this for text fields:

//by default
edittext.setTransformationMethod(new PasswordTransformationMethod());
//You can make it custom
edittext.setTransformationMethod(new AsterPasswordTransformationMethod());

[Vinay Gaba]

I have an example of this here - https://github.com/vinaygaba/Learn-Jetpack-Compose-By-Example/blob/a7cba8e6d3c43b288e539323ba6d1ba92c408814/app/src/main/java/com/example/jetpackcompose/text/TextFieldActivity.kt#L252

[Leland Richardson [G]]

cc @Siyamed should this be easier? perhaps visualTransformation should have a default value that is a function of the keyboardType

[Siyamed]

I dont think it would scale

[Siyamed]

The difference of how the outout will look like, what characters keyboard will show, is it a number password, ascii password, what the action would be, visible password, invisible password etc it far too complex

[Siyamed]

Things get too complicated too fast there, and we end up in a state where we cant support the need

[Siyamed]

I am assuming that this is not about the api of visual transformation which i find hard to use; but it is about having to add a visual transformation

[Leland Richardson [G]]

yeah

[Leland Richardson [G]]

you might be totally right, but i’m not sure i see the issue

[Siyamed]

Hmm, even though keyboard type is password, the visual outout might be hidden

[Leland Richardson [G]]

is visual output different from visualTransformation?

[Siyamed]

Or keyboard type is numeric but not password, but still output (visuals) is password

[Siyamed]

Too many combinations

[Siyamed]

Will think how it can be better but adding signal to keyboard type wouldn't scale

[Leland Richardson [G]]

i guess it seems like not a scalability issue to me. it’s taking advantage of the default value, so you can add as few “common cases” as you want

[Leland Richardson [G]]

in this case we have the current common cases = 1

[Leland Richardson [G]]

and only increasing to 2

[Leland Richardson [G]]

no need to increase it further

[Siyamed]

I dont agree with common cases especially when it is about text based on my experience :)

[Leland Richardson [G]]

people could still specify any visual tranformation they wanted

[Siyamed]

I will check it

[Leland Richardson [G]]

(not trying to be pushy here, just trying to understand the scalability argument)

[Siyamed]

I also dont understand the issue :) what is hard to say visual transformatuon is password transformation?

[Siyamed]

Keyboard type is specific to 'keyboard' not textfield

[Leland Richardson [G]]

it doesn’t seem terribly difficult or anything

[Siyamed]

It is possible that when we see that keyboard type is passowrd and visualtranformation is not defined, we attach one

[Leland Richardson [G]]

that was what i was suggesting

[Siyamed]

Sorry, i double checjed after i wrote :) i though you wanted a visual transformation api in keyboard type class

[Siyamed]

Makes sense :)

[Siyamed]

534pm effect :)

[Leland Richardson [G]]

i was thinking something like

visualTransformation: VisualTransformation = VisualTransformation.None

changed to

visualTransformation: VisualTransformation = if (keyboardType == KeyboardType.Password) PasswordVisualTransformation() else VisualTransformation.None

[Siyamed]

Makes sense

[Leland Richardson [G]]

it just makes a common case a little easier to get to

[Leland Richardson [G]]

but i don’t feel strongly 🙂

[Siyamed]

We should guide community about the difference of keyboardtype vs visuals very well though

[Siyamed]

Sounds good

[Leland Richardson [G]]

👍 also, thinking more about this, i can see the argument of trying to keep these separate. I was just thinking that it would be nice to have a common case “password” textfield be only one additional line of code

[Leland Richardson [G]]

i also wish it was easier to not allocate a new PasswordVisualTransformation on each recompose if you pass it in

[Leland Richardson [G]]

wonder if a VisualTransformation.Password makes sense

[Leland Richardson [G]]

assuming its stateless, which i’m guessing it is

[Siyamed]

That also makes sense

[Siyamed]

It is something very common. Password one itself does not have a state

[Siyamed]

Ok so i create two tickets :)

[Guy Bieber]

Smile. Didn’t want to spawn a huge debate! Got it working with the API the way it is.

[Guy Bieber]

all good

[Guy Bieber]

ui.TextFieldStyled(
    text = appModel.session.user.userPass,
    onDone = {
        appModel.session.user.userPass = it
    },
    keyboardType = KeyboardType.Password,
    visualTransformation = PasswordVisualTransformation()
)

[Siyamed]

158247724 for default transformation

[Siyamed]

🤦

[Siyamed]

https://issuetracker.google.com/issues/158247724