native.newTexfield question

Other
#1

Is there a way to do the event.phase==“submitted” via code?

If the user taps outside the keyboard screen or taps the move keyboard down button, the name text stays in the field and some users think that they submitted the text.
But since they did not hit the enter key on the onscreen keyboard the text doesn’t get submitted. It just goes to the event.phase==“ended” part.

Can I put something in there that makes the text be “submitted”?

My alternative would be to have a pop up appear on the screen asking them if they hit enter, but that is a bit in your face.

#2

In my opinion, depending on the “submitted” event for text entry/saving is bad UI design.  You should treat a “submitted” event like how the “enter” key works in a desktop setup window… or how it works in a web page.  That is, you should always display an OK/Submit button onscreen and treat the “submitted” event as an equivalent to the end-user pressing the OK/Submit button in the window.  Or in iOS terms, treat it like pressing the Back navigation button that’s displayed in the top title bar.  That’s your opportunity to validate the text fields, display an alert if there is something wrong, or if they’re valid then save/accept the text entries.

Case in point, look at how the Facebook app handles the login window on Android.  Notice that it always displays a login button onscreen… and pressing the Submit button in the virtual keyboard invokes the Login button’s action.  But also notice that tapping the “Submit” button in the virtual keyboard is not required to login either.  This is a good model to follow.

Also, Android apps work more like desktop apps in regards to keyboard input.  That is, you have no control over whether or not the end-user will press the submit/enter key.  The end-user can choose to dismiss the virtual keyboard anytime they want… if it is even display because they might be using a physical keyboard, such as on a Droid.  Or some Android virtual keyboards, like the 1st generation Kindle Fire, do not provide a “Submit” button on the virtual keyboard, even if we tell it to via native code.  Again, you have to pretend that the Android virtual keyboard works more like a physical keyboard on a desktop and you have little control over what keys are available on the keyboard.  That’s just how it is.

And back to your original question, the “ended” phase event will be dispatched when the text field loses focus.  You can always choose to validate the text field when that event occurs, but I do *not* recommend that you display an alert during the “ended” event.  I think UI that *traps* me in a text field and refuses to let me leave it is super annoying.

Anyways, that’s my 2 cents.

#3

I do not want to use a pop up. That would have been the alternative.

What I did now is check if a user entered anything in the textfield by checking if event.target.text=="" if so it does nothing. If it does not I submit the text for them.

#4

In my opinion, depending on the “submitted” event for text entry/saving is bad UI design.  You should treat a “submitted” event like how the “enter” key works in a desktop setup window… or how it works in a web page.  That is, you should always display an OK/Submit button onscreen and treat the “submitted” event as an equivalent to the end-user pressing the OK/Submit button in the window.  Or in iOS terms, treat it like pressing the Back navigation button that’s displayed in the top title bar.  That’s your opportunity to validate the text fields, display an alert if there is something wrong, or if they’re valid then save/accept the text entries.

Case in point, look at how the Facebook app handles the login window on Android.  Notice that it always displays a login button onscreen… and pressing the Submit button in the virtual keyboard invokes the Login button’s action.  But also notice that tapping the “Submit” button in the virtual keyboard is not required to login either.  This is a good model to follow.

Also, Android apps work more like desktop apps in regards to keyboard input.  That is, you have no control over whether or not the end-user will press the submit/enter key.  The end-user can choose to dismiss the virtual keyboard anytime they want… if it is even display because they might be using a physical keyboard, such as on a Droid.  Or some Android virtual keyboards, like the 1st generation Kindle Fire, do not provide a “Submit” button on the virtual keyboard, even if we tell it to via native code.  Again, you have to pretend that the Android virtual keyboard works more like a physical keyboard on a desktop and you have little control over what keys are available on the keyboard.  That’s just how it is.

And back to your original question, the “ended” phase event will be dispatched when the text field loses focus.  You can always choose to validate the text field when that event occurs, but I do *not* recommend that you display an alert during the “ended” event.  I think UI that *traps* me in a text field and refuses to let me leave it is super annoying.

Anyways, that’s my 2 cents.

#5

I do not want to use a pop up. That would have been the alternative.

What I did now is check if a user entered anything in the textfield by checking if event.target.text=="" if so it does nothing. If it does not I submit the text for them.