[ASEditableTextNode] Support wrapping UITextField (instead of just UITextView). Required for secureTextEntry.

[garrettmoon]

From @huyle90 on March 26, 2016 0:52

Hi, I am just starting to use AsyncDisplayKit recently and I want to implement ASEditableNode as a password text field. But I have a problem with setting securedTextEntry of ASEditableNode ( .textView) Does anyone know why the text view of ASEditableNode does not support UITextInputTraits protocol in this case?

Copied from original issue: facebookarchive/AsyncDisplayKit#1434

[garrettmoon]

From @hannahmbanana on March 26, 2016 17:42

@huyle90 - Thanks for your question! This should already be supported by accessing the textView property because the ASEditableTextNode internally contains a regular UITextView.

In what way does it not work? Is the textView nil? could you provide the code you are using or a sample project?

[garrettmoon]

From @appleguy on March 26, 2016 19:18

@huyle90 it would be pretty easy to add the text input traits protocol to the editable text node. However this would simply forward those properties to the internal text view, and it should be easy for you to apply those properties to that text view directly.

If you can give us any further information on the symptoms you're seeing and what you have tried, that would be useful. By far the best thing would be a small test project that can reproduce the issue, and with that we would be able to fix it quite quickly. It is definitely intended to be supported.

[garrettmoon]

From @huyle90 on March 28, 2016 13:49

@appleguy @hannahmbanana textView is not nil since I have instantiated the ASEditableTextNode. I set all properties needed and they are fine except secureTextEntry doesnt show password char (•). This somehow didnt work for UITextView I guess. passwordTextFieldNode.textView.secureTextEntry = true

[garrettmoon]

From @wpK on March 28, 2016 22:0

I'm having the same issue. Here is a code sample: https://gist.github.com/wpK/40551dbde865b277cc88 with the following result:

[garrettmoon]

From @appleguy on March 30, 2016 5:56

@huyle90 making sure I understand your comment - are you saying you also tried UITextView and that didn't work either?

It is certainly possible that secure text is only supported by UITextField, not UITextView, as the rendering engines are completely different. But I simply don't know for sure if this limitation is true, even though it seems plausible from what I remember about their implementation back when I worked on that code for iOS 1.0-4.3.

If one of you could try it, that would be great to check (that it hopefully DOES work in UITextView). Either way, it would be great if we supported using UITextField as the internal object for ASEditableTextNode, controlled by a BOOL flag. This is actually a good deal more efficient than a UITextView and we'd even benefit from that at Pinterest, if anyone wants to make a PR and effectively resolve this issue.

[garrettmoon]

From @wpK on March 30, 2016 16:54

@appleguy I haven't checked but that could actually be the case.

Personally I prefer your approach of supporting ASTextField. Supporting "proper" single line form fields is a bit of a hassle right now (forcing 1 line, disabling newlines from keyboard, replacing pasted newline characters, etc) which is all provided for free by UITextField.

If I have time and no one else has tackled it by then, I'll give it a go as my project needs it as well.

[garrettmoon]

From @appleguy on March 30, 2016 17:33

Very cool! If you are interested in joining our Slack or bug tracker Ship, send me an email.

Sent from my iPhone

On Mar 30, 2016, at 9:54 AM, William Key notifications@github.com wrote:

@appleguy I haven't checked but that could actually be the case.

Personally I prefer your approach of supporting ASTextField. Supporting "proper" single line form fields is a bit of a hassle right now (forcing 1 line, disabling newlines from keyboard, replacing pasted newline characters, etc) which is all provided for free by UITextField.

If I have time and no one else has tackled it by then, I'll give it a go as my project needs it as well.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub

[garrettmoon]

From @appleguy on June 6, 2016 5:41

The community is planning an exciting long term road map for the project and getting organized around how to deliver these feature requests. We are moving to a new issue tracker with more sophisticated planning capabilities (check out www.realArtists.com and their new product: Ship!).

If you are interested in helping contribute to this component or any other, don’t hesitate to send us an email at AsyncDisplayKit@gmail.com or ping us on ASDK's Slack (#1582). If you would like to contribute for a few weeks, I can also add you to our Ship bug tracker so that you can see what everyone is working on and actively coordinate with us.

As always, keep filing issues and submitting pull requests here on Github and we will only move things to the new tracker if they require long term coordination.

[garrettmoon]

From @hannahmbanana on June 24, 2016 23:38

@huyle90 @wpK: PR #1809 adds UITextInputTraits support to ASEditableTextNode. Try it out and let us know if it works for you!

[garrettmoon]

From @cbreed28 on July 8, 2016 18:21

I've just pulled down the PR merge on master to try out the UITextInputTraits, but, I'm still not seeing the secureTextEntry property take hold on the underlying UITextView. Per @appleguy's previous comment, it looks like the UITextView rendering code is not respecting the secureTextEntry property. +1 for using UITextField as the underlying view for ASEditableTextNode.

[garrettmoon]

From @appleguy on December 25, 2016 23:44

The way we should implement this is providing a simple enum / type (or a +initializer for editableTextField vs editableTextView). Because we already have a "pending state" object for the UITextInputTraits, and the API is almost identical between Field and View, this should be relatively straightforward to implement.

This is definitely one of our most commonly requested features by the community; it's in the top 5, possibly top 3, in terms of requests that are explicitly asked for. Perhaps there are more important things that folks don't know they want :), although I'd suggest we make sure to do this one in 2.1.

It's an ideal task to ask an external volunteer to do.

[garrettmoon]

I'm not sure this is a P1 but it would be great to prioritize for 2.1

[garrettmoon]

From @maicki on January 3, 2017 20:3

Some idea from an Slack conversation with @appleguy today:

[appleguy]

Adding a comment that @hashemp206 made on the older AsyncDisplayKit issue:

https://medium.com/pocket-labs/astextfieldnode-a-text-field-component-for-asyncdisplaykit-7b67f1cb6e43

[haashem]

I use this ASTextFieldNode yesterday and I had some issue with that: NSString properties not bridged correctly to Swift, complains about you can't pass String to type NSString when assigning text!

you can't set attributedPlaceholder directly, even it has that property, instead you have to access the textField property and set TextFieldView attributedPlaceholder directly.

@appleguy why still there is no built in ASTextFieldNode in Texture? even though it is one of most wanted component?

[wpK]

@hashemp206 The NSString issue is an easy enough fix. Recreating the Pocket Labs implementation is rather trivial if you're already using Texture in your project.

If you compare the Texture.ASEditableTextNode class with the ASTextFieldNode version by Pocket Labs you'll see that Texture does not simply wrap the UIKit version like the Pocket Labs implementation.

You can read more about view wrapping in the official docs here.

[haashem]

@wpK how would you solve that? can you send a pull request?