Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Android TextInputLayouts losing text/content when coming back in fragment transaction

I've been searching for a while now but I think most of the reported bugs (and there are quite a few) in android.support.design.widget.TextInputLayout differ a little from this one. At least, I have solved most of the other bugs, but struggle with this one. I currently have a Fragment in my activity with a couple of TextInputLayout like this

<android.support.design.widget.TextInputLayout
    android:id="@+id/input1"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <EditText
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="@string/hint1"
        android:inputType="numberSigned" />
</android.support.design.widget.TextInputLayout>

<android.support.design.widget.TextInputLayout
    android:id="@+id/input2
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <EditText
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="@string/hint2"
        android:inputType="numberSigned"/>
</android.support.design.widget.TextInputLayout>

<android.support.design.widget.TextInputLayout
    android:id="@+id/input3"
    android:layout_width="match_parent"
    android:layout_height="wrap_content">

    <EditText
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:hint="@string/hint3"
        android:inputType="numberSigned">
</android.support.design.widget.TextInputLayout>

And, after meeting some external condition (not important) I open and show another fragment (100% screen) which hides the aforementioned fragment. In case you wonder this new fragment asks for some extra fields that I need in that particular case. This is the code that handles the creation of the new Fragment:

Fragment2 fragment2 = new Fragment2();
FragmentTransaction transaction = getActivity().getSupportFragmentManager().beginTransaction()
                                .replace(((ViewGroup) getView().getParent()).getId(), fragment2);
transaction.addToBackStack(Fragment1.class.getSimpleName());
transaction.commit();

BUT the problem is that, when going back (back button press, toolbar/action bar home button, etc..) to the first fragment. All of my TextInputLayouts lose the text that was inserted on them. This is really annoying and didn't happened when working exclusively with EditText, like we did previous our Material Design transition.

Moreover, this does not happen if instead of replacing fragments using a FragmentTransaction, I start a new Activity. Unfortunately, this is not what we really want. And we shouldn't need to do this kind of workaround.

Any ideas? Has this happened to anyone?

like image 885
acrespo Avatar asked Jul 16 '15 00:07

acrespo


People also ask

How do I remove TextInputLayout error?

Now you can simply do input. setError(..) for new error and input. setErrorEnabled(false) to remove it.

How do I get TextInputLayout from text?

Just use: TextInputLayout textInputLayout = findViewById(R. id. custom_end_icon); String text = textInputLayout.

How do I disable TextInputLayout padding?

You can just set the start and end padding on the inner EditText to 0dp. Here's a screenshot with Show Layout Bounds turned on so you can see that the hints go all the way to the edge of the view.

What is the use of TextInputLayout in Android?

The primary use of a TextInputLayout is to act as a wrapper for EditText(or its descendant) and enable floating hint animations. Rule of Thumb : TextInputLayout should wrap TextInputEditText instead of the normal EditText.


1 Answers

Posting my "answer", which is really a workaround and may not prove useful or satisfactory to everybody but at least it served me well.

This is clearly a bug with the new TextInputLayout, which does not handle very well the savedInstanceState when doing a replacement or removal in a FragmentTransaction. EditText did a really good job previously.

What I ended up doing is not using FragmentTransaction#replace() (because I traced the problem to the removal of the fragment), but instead using a combination of FragmentTransaction#hide() and FragmentTransaction#add(). This offers exactly the same visual effect and behaviour and does not has the problem of the mentioned bug. It only has the inherent drawback of, obviously, not removing the fragment: the fragment resources cannot be released/use for other purposes. This may cause trouble if memory is short or your fragment is a monstrosity. But at least in my case it didn't cause any trouble.

To sum up, this is what I finally use as my fragment transaction:

Fragment2 fragment2 = new Fragment2();
FragmentTransaction transaction = getActivity().getSupportFragmentManager().beginTransaction();
transaction.add(((ViewGroup) getView().getParent()).getId(), fragment2);
transaction.hide(Fragment1.this);
transaction.addToBackStack(Fragment1.class.getSimpleName());
transaction.commit();

Hope it can help some of you!

like image 164
acrespo Avatar answered Oct 20 '22 10:10

acrespo