Tutorial: Moving native text input fields/boxes

Tutorial: Moving native text input fields/boxes

One challenge for Corona developers is how to deal with native.newTextField() and native.newTextBox() objects, in particular when they are located in the lower half of the screen where they can be covered by the device’s keyboard. A common solution is to explicitly move native text field/box objects upward by some variable “keyboard height” when the keyboard becomes active, thus keeping them within view/access of the user.

Using display groups

For simplicity, native objects can be moved as one “unit,” specifically as part of a display.newGroup() which may contain supporting objects like a background, images, buttons, etc. Consider this code:

This code creates a simple UI (User Interface) consisting of two text fields named value1 and value2, plus (+) and equal (=) text objects, a title text label, and a label to hold the results of summing the two fields. All of these objects are inserted within the UIGroup display group, including the native text fields. Thus, when we position the group — or transition it upwards or downwards — everything moves in unison.

Of course, this doesn’t mean that you can position native objects in front of normal display objects — native objects will always appear in front of other display objects, but we can still handle the movement and positioning of these objects as one collective group.

Note that when handling the text field inputs, we confirm that a value has been entered into both fields before transitioning the group back down. We also confirm that each value is a number to avoid any potential errors in summing them together. With these two checks in place, the fields will remain accessible above the keyboard while the user interacts with them, and then when both have valid entries, the group can transition back down while the keyboard is simultaneously dismissed/hidden. Of course, depending on your own design, this approach may vary, but you should ensure that the input fields remain accessible for the duration of the required interactivity.

Conclusion

As demonstrated, this method is useful for handling native input objects. It can benefit developers of business/utility apps in particular, since apps in these categories often rely on keyboard-based interaction.


Rob Miracle
rob@coronalabs.com

Rob Miracle creates mobile apps for his own enjoyment and the amusement of others. He serves the Corona Community in the forums, on the blog, and at local events.

7 Comments
  • Fernando Faria
    Posted at 02:56h, 20 November

    When we will have the option to get the height of the native keyboard?

    • joseanquiles
      Posted at 22:37h, 20 November

      Thank you Rob. It clarifies a lot about native text fields.
      I thougth that text fields cannot be inserted in groups.
      Only one doubt: how can I discover the y position in order to text field not being hidden by keyboard?

      • Rob Miracle
        Posted at 14:13h, 22 November

        If you text field is called “myTextField” then you can get it’s Y position using: myTextField.y.

  • RuneW
    Posted at 00:40h, 21 November

    I think maybe group support for textFields is one of the news in the new public release?

    This makes things a bit easier, but I look forward to the glorious day when Corona manages to make a textField WIDGET instead of relying on the native textField!

    Such a widget will be made so that the group in which it was placed, will automatically scroll up to a given position when the widget has focus. It wil work in the Android emulator. And the text inside will actually behave in a predicatable way and not look like the demo above does on my Galaxy S5 phone (with “1” in the first line and “2” in the second line):

    http://www.sub20hz.com/fun/android/android_textField.png

    I’m looking forward to this day!

  • ojnab
    Posted at 13:10h, 22 November

    Didn’t now it was possible to insert native textfields to groups. Does this behaviour apply to other native display objects? Also does it mean that textfields inserted in groups will also be destroyed if i call removeSelf on the group?

  • deniz
    Posted at 04:10h, 23 November

    How would you place a native text field just above the keyboard? On Android devices keyboard height varies from device to device (or its operating system specific), on ios devices it also varies if you are using some alternate keyboards. That Corona limitation makes it impossible to create a WhatsApp like chat UI. Please implement a function like native.keyboardHeight

    • Rob Miracle
      Posted at 10:56h, 23 November

      First, there is no way to get the the keyboard height for Android. Engineering has been experimenting with automatic panning where the screen will scroll it into view for you. It seems to be working on Android, but it only works on iOS is single orientation apps. Because this is an experimental feature, has some pretty major limitations on iOS, we didn’t cover it in the blog. But if you want to play with it, add this key:

      CoronaWindowMovesWhenKeyboardAppears = true,

      into the settings->iphone->plist table for iOS or

      coronaWindowMovesWhenKeyboardAppears = true,

      into the settings->android table for Android in your build.settings. Yes they start with different case letters. The Apple standard is to capitalize the first letter, the Google standard is to lower case it. This will cause the active field, if it’s below the keyboard to pan into view. There are no extra controls to move it anything more than flush with the top of the keyboard.

      Due to the complexity to get this working, it may be a while before Engineering gets back to this. You can use it as long as you understand the limitations.