Warum ändert Android den Wert von EditTexts mit derselben ID?

Ich habe ein Fragment mit einem LinearLayout, wo verschiedene Elemente je nach Geschäftslogik aufgeblasen werden. Eines dieser Elemente enthält einen EditText. Wenn ich mehrere dieser Elemente mit verschiedenen Inhalten habe und ich das Fragment ablöse / anhänge, bekommst alle EditTexts irgendwie den gleichen Text. Dies geschieht nur so lange, wie der EditText eine ID in der Layoutdatei hat.

Warum passiert das? Gibt es eine andere Möglichkeit, dies zu verhindern, außer das Entfernen der ID? Ich möchte findViewById auf meine aufgeblasenen Elemente verwenden, um auf die Ansichten zuzugreifen, anstelle von fehleranfälligem getChildAt .

Ich habe ein minimalistisches Beispiel erstellt, um das Problem unter https://github.com/rodja/EditTextValueProblem zu demonstrieren

  • Kontext in einem PreferenceFragment
  • Warum möchte ich nicht-Standard-Konstruktoren in Fragmenten vermeiden?
  • So legen Sie Google Maps V2 auf ein Fragment mit ViewPager
  • Android Fragment vs. Aktivitätsgruppe
  • Unmöglich, Fragment zu instanziieren
  • Toggle Navigation Schublade 'offen' auf Button / Bild klicken
  • Android: Ist es besser, ein neues Fragment zu erstellen, jedes Mal, wenn ein Navigations-Schubladen-Element angeklickt wird, oder laden Sie zuvor erstellte Fragmente?
  • Wie führe ich RecyclerView Adapter mit Firebase
  • 3 Solutions collect form web for “Warum ändert Android den Wert von EditTexts mit derselben ID?”

    Es kann einfach durch die Einstellung von android:saveEnabled="false" in der EditTexts Layout Definition festgelegt werden. Natürlich müssen Sie sicherstellen, dass der Inhalt gespeichert / wiederhergestellt wird. Das ist also eine nicht intuitive Arbeit – aber es funktioniert für meinen Fall. Trotzdem sieht das ganze Ding wie ein Android-Bug aus:

    Ein nettes Feature des Android-Layout-Systems ist das

    Ein ID muss nicht ganz im ganzen Baum sein […]

    Wie in der Android-Dokumentation angegeben . Dies macht Code und Layout Wiederverwendung viel einfacher und wird stark von den Entwicklern verwendet. Ich denke, die Save / Restore-Instanz-State-Implementierung für Views verwendet die View-ID als Schlüssel, um ihren Zustand zu speichern, daher stützt sie sich auf die Einzigartigkeit im gesamten Baum . WTF?

    Aktualisieren

    Ich habe eine ListView zum Beispiel bei GitHub hinzugefügt, was zeigt, dass die ListView fast sicher eine ähnliche Workaround verwendet, um zu verhindern, dass EditTexts in dieses Problem ausgeführt wird. Wie man sehen kann, wird Text, der in einem EditText in einem ListView eingegeben wird, nicht automatisch wiederhergestellt.

    Es gibt eine andere Möglichkeit, einfach die ID des Edit-Textes ändern, zum Beispiel,

     mEditText.setId((parentView.getId()+editTextPosition+someFinalNumber)); 

    Oder wenn es ein EditText in einem benutzerdefinierten Layout ist:

     mEditText.setId((this.getId()+someFinalNumber)); 

    Auf diese Weise werden alle EditTexts eine andere ID haben und der Text wird korrekt wiederhergestellt.

    Ich denke, das ist, weil der Zustand aller EditTexts mit einer ID automatisch gespeichert wird. Wenn Sie FragmentTransactions durchführen oder die Orientierung ändern, wird die Aktivität neu erstellt und der Zustand der EditTexts wird wiederhergestellt, da sie alle die gleiche ID haben, werden sie alle den gleichen Wert erhalten. Mein erster Vorschlag wäre die Überschreitung der Methoden onRestoreInstanceState und onSaveInstanceState Ihrer Aktivität wie folgt:

     @Override protected void onRestoreInstanceState(Bundle savedInstanceState) { // super.onRestoreInstanceState(savedInstanceState); <-- Make sure this is at least commented out or deleted altogether } @Override protected void onSaveInstanceState(Bundle outState) { // super.onSaveInstanceState(outState); <-- Make sure this is at least commented out or deleted altogether } 

    Wenn die Methoden in der Superklasse nicht aufgerufen werden, sollte sie automatisch das Speichern und Wiederherstellen von Zuständen stoppen. Lassen Sie mich wissen, wenn das funktioniert, ich kann es jetzt nicht testen. Wenn das nicht klappt, bin ich sicher, dass wir eine andere Arbeit finden können.

    Jedenfalls haben Sie ein Problem auf Ihren Händen, die nicht viele zu bewältigen haben, ist mit einem ListView anstelle einer LinearLayout keine Option? Weil ich mir ziemlich sicher bin, dass ein ListView auch das Problem lösen würde.

    Das Android ist ein Google Android Fan-Website, Alles ├╝ber Android Phones, Android Wear, Android Dev und Android Spiele Apps und so weiter.