Home > Blockchain >  Android studio layouts howto make prompt/hint before EdiText
Android studio layouts howto make prompt/hint before EdiText

Time:09-27

I am working in a kotlin project, and have been searching for some documentation about the screen layout.

What i want to do is very rudimentairy i guess. I want is to put a label/prompt/text before a EditText.

In html i would program something like this:

<form>
  <label for="fname">First name:</label>
  <input type="text" id="fname" name="fname"><br><br>
</form>

And get the a result like this:

First name: ___________

All i can find is a "android:hint=". But it only fills the View if there is nothing in it.

Should one add extra (plainText) elements for each label ? and how should one contstrain it to the EditText ? or is there some kind of grouping ?

CodePudding user response:

Yes, you have to add one more textview before adding edit text. The hint is used for displaying messages in edittext.

CodePudding user response:

Android EditText (now often used as a combination of TextInputLayout containing one (and only one) TextInputEditText) can display a Hint, but only while the view has no focus/content.

If you want to provide a better description on what a particular EditText is for, for many reasons (accessibility, often neglected, is not the only one), you may want to provide an extra TextView positioned anywhere you consider it ok to add the extra information needed to better describe the EditText.

The main thing to keep in mind, is to provide this TextView with the labelFor attribute, as described in the Android documentation.

If you're reading this and wondering but why do I have to provide an extra Textview to describe, why not just use the hint, android is horrible!!!, keep in mind that the Hint is good for different reasons, but not for describing what the field is about.

E.g.: Imagine you're asking for a Date of Birth. You may be tempted to write this: (note this is a simplified version obviously):

 <com.google.android.material.textfield.TextInputLayout
    android:id="@ id/dobInputLayout"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" >

    <com.google.android.material.textfield.TextInputEditText
        android:id="@ id/dobInputText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Date of Birth" />
</com.google.android.material.textfield.TextInputLayout>

And you'd be mostly ok, but then your designer comes in and says, well, we also want to show the Format that we accept, for e.g.: DAY/MONTH/YEAR...

Now you're going to change the hint to be:

android:hint="Date of Birth (DD/MM/YYYY)

And you'd again, be ok, but for accessibility users... this doesn't read very efficiently nor is very clear. You also get back from your designer who says: "but I don't want the (DD/MM/YYYY) part to be visible after the user focuses or types something..."

And so on and so forth.

The correct (according to Google, Material Design, and who knows what), is to provide an extra TextView that accompanies the TextInput combos: (again, keep in mind this is pseudo-code, when in doubt, read the documentation)

 <TextView 
    android:id="@ id/dobLabel"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Date of Birth"
    android:labelFor="@id/dobInputText />
    
 <com.google.android.material.textfield.TextInputLayout
    android:id="@ id/dobInputLayout"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content" >

    <com.google.android.material.textfield.TextInputEditText
        android:id="@ id/dobInputText"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="Day/Month/Year" />
</com.google.android.material.textfield.TextInputLayout>

Do not provide contentDescription on those views because they will likely interfere with TalkBack/Accessibility. These are the conventions that Android set in place, you may or may not like them, but this is how it's expected to be done.

Do I think EditText should be a better widget and handle this better for you? Yes. Does it matter what I think? Nope.

  • Related