Support either a "long" or a "short" text appearance about commcare-android HOT 6 CLOSED

@ctsims Wondering why can't we use EditorInfo.IME_ACTION_NEXT even if it's long text entry ? I can see it being useful for both long and short entries as user would want to press next at the end of both short and long text entries to move to the next field.

from commcare-android.

EditorInfo.IME_ACTION_NEXT determines whether there's a soft keyboard button for a "next" button, or whether that same button is instead used for a return key to enter multiple paragraphs.

We don't have a clear way to differentiate user intent there since people use the same text field for both paragraph entry and single line text, so setting EditorInfo.IME_ACTION_NEXT would interfere with their ability to enter newlined data.

from commcare-android.

Makes sense. Sounds like the right behaviour for us here is to introduce couple appearance attributes "short" and "long" for Text entry and have it default to "long" for now (2.51) while giving user ability to shift to "short" and later shift the default to "short' texts (2.52). We will probably need to make a public post supported by some public facing documentation so that users are available of this option.

from commcare-android.

Sounds right overall. I'd actually guess that it might be fine to just insert a 'short" and switch HQ to generate "Short" inputs by default, given that it's mostly a nice-to-have for users (v. something that will cause us problems long term). We also may want to build on top of the "Short" concept even more (which would make setting it to be the default even more challenging). The work you did, for instance, that lets you do side-by-side text and value input would function really well with short inputs but might need even more constraint.

from commcare-android.

it might be fine to just insert a 'short" and switch HQ to generate "Short" inputs by default

Yeah. that sounds right.

We also may want to build on top of the "Short" concept even more (which would make setting it to be the default even more challenging). The work you did, for instance, that lets you do side-by-side text and value input would function really well with short inputs but might need even more constraint.

Interesting. We do have a separate appearance attribute "compact" to achieve side-by-side text and value input for non text entries. We can expand compact for text entries as well and assume underlying text is always of type short when compact is set.

from commcare-android.

I definitely think that making compact treat any Text Entry widgets underneath as short by default would be great. I bet people would love that for a lot of different forms, especially tablet people.

from commcare-android.