nach dem Konfigurationswechselfragment von Backstack teilt nun das FrameLayout?

8

Probleme mit der App:

Wenn sich die Ausrichtung ändert, treten bei der App folgende Probleme auf:

  • Sowohl FragmentA als auch FragmentC belegen jetzt den FrameLayout-Container.

Was funktioniert: Alles funktioniert so, wie ich es möchte ... vor dem Drehen des Bildschirms.

Beschreibung der Aktivität in Kürze:

EditActivity Zweck: Sammlungs- und Elementfelder bearbeiten.

Fragmente, die diese Aktivität programmgesteuert erstellt:

  • FragmentA - Fragment zum Bearbeiten von Sammlungsfeldern
  • FragmentB - ListFragment von Objekten in der Sammlung
  • FragmentC - Fragment zum Bearbeiten von Elementfeldern.

Anfangslayout: FragmentA befindet sich auf FragmentB, jeweils in einem eigenen FrameLayout.

Wenn der Benutzer auf das Listenansichtselement von FragmentB klickt: Ersetzen Sie FragmentA durch FragmentC, damit der Benutzer die Felder dieses Elements bearbeiten kann. Jetzt steht FragmentC auf FragmentB.

Dies scheint ein sehr einfacher Begriff zu sein: Der obere Teil der Aktivität dient zum Bearbeiten von Eigenschaften der Sammlung als Ganzes oder eines einzelnen Objekts aus der Sammlung. Ich habe nicht das Gefühl, dass ich irgendetwas Wunderbares mit dem Layout gemacht habe, daher bin ich ein wenig perplex, dass eine einfache Drehung des Telefons (Emulator) diese Probleme verursacht, die ich so eine heimtückische Zeit versuche zu beheben.

Warum das Beispiel Anleitung für Android Fragment Guide für mich nicht funktioniert: Ihr Beispiel ist ähnlich wie was Ich mache, aber ihr Detailfragment wird entweder in einer neuen Aktivität oder in einem eigenen Frame innerhalb der aktuellen Aktivität geöffnet, sie tauschen keine Fragmente aus, so dass ich nicht herausfinden kann, wie sie den onSaveIstanceState verwenden würden, um die Fragmente zu erhalten sichtbar und dann diese Informationen in onCreate verwenden, um die Benutzeroberfläche neu zu erstellen, die vor der Änderung der Ausrichtung vorhanden war.

BEARBEITEN: Ein Problem wurde gelöst, indem man das Listfragment in den XML-Code umwandelte und löste. Das Problem, das sich immer wieder drehte, löste sich.

    
ross studtman 24.05.2013, 17:41
quelle

1 Antwort

26

Gelöst. Oh, die Kaninchenlöcher, die ich bereist habe ... Auf jeden Fall, wenn Sie auf solche Probleme stoßen, sollten Sie ein paar Dinge beachten:

  • letztendlich musste ich in onSaveInstanceState(Bundle outState) keinen Code schreiben.
  • Letztendlich musste ich keine Überlegungen bezüglich der Handhabung des Backstacks in onSaveInstanceState anstellen oder mit dem onCreate der Aktivität umgehen.
  • Wenn Sie Fragmente zuerst programmatisch zur FrameLayout hinzufügen, verwenden Sie replace anstelle von 'add' - das war wahrscheinlich einer der Wurzeln meiner Probleme.
  • in onCreate überprüfen, ob das Paket von savedInstanceState null ist, if(savedInstanceState == null) , und wenn es dann ist, weiß ich, dass die Aktivität nicht zuvor durch eine Konfigurationsänderung abgebrochen wurde, also hier ich Fragmente erstellen, die direkt bei Aktivität angezeigt werden sollen Anfang. Andere Fragmente, die programmatisch an anderer Stelle zum Leben erweckt werden (dh später als die onCreate() der Aktivität), gehören nicht in if , sie gehören in else :
  • else onSaveInstanceState != null und ich weiß, es gibt nur einen Grund, warum dieses Ding nicht null ist, weil das System ein Bündel mit dem Namen outState in onSaveInstanceState(Bundle outState) erstellt und es an der Methode onCreate der Aktivität gehackt hat, wo ich jetzt meine Grubbies dazu bekommen kann. So kenne ich hier ein paar Dinge:
    1. sicher sind die Fragmente, die ich im onCreate der Aktivität erstellt habe, immer noch ein Teil der Aktivität (ich habe sie nicht gelöst oder zerstört), aber kann ich nicht den gleichen Anspruch für die Fragmente, die durch die Aktionen eines Benutzers zum Leben erweckt wurden, diese Fragmente können oder können derzeit (zum Zeitpunkt der Orientierung aka Konfigurationsänderung) nicht an die Aktivität angehängt sein.
    2. Dies ist ein guter Platz für eine if-this-thing-is-attached -Klausel. Eines der Dinge, die ich anfänglich vermasselt habe, war, dass ich ALLEN meinen programmatisch hinzugefügten Fragmenten kein Tag gegeben habe; gebe alle programmatisch hinzugefügten Fragmente Tags. Ich kann dann herausfinden, ob das savedInstanceState-Paket den Schlüssel mit savedInstanceState.containsKey(MY_FRAG_TAG) und mit getFragmentManager().findFragmentByTag(MY_FRAG_TAG) enthält

Hier ist also die Aktivität onCreate (vereinfacht):

%Vor%

Und der Listener der Aktivität für das Listenfragment, wobei FragmentC für FragmentA getauscht wird:

%Vor%

Und onSaveInstanceState ist nackt wie ein Eichelvogel:

%Vor%

Zusammenfassung: Die Aktivität funktioniert genau so, wie ich es möchte.

Nun, wenn ich einen Haufen von hinzugefügten Fragmenten hätte, dann würde ich sie vielleicht eher programmatisch behandeln als durch hartes Codieren von if(savedInstanceState.contains(*hard coded key*) . Dies habe ich ein wenig getestet, kann aber seine Wirksamkeit nicht bestätigen, aber für jemanden da draußen könnte dies eine Idee dessen auslösen, was Sie tun können:

  1. Erstellen Sie eine private Gruppe von hinzugefügten Fragmenten:

    %Vor%
  2. In onAttachFragment machen Sie etwas wie:

    %Vor%
  3. Dann in den onCreate und in savedInstanceState -Klauseln der Aktivität:

    %Vor%

... aber das ist ungeprüft und wird nur präsentiert, um Ideen hervorzubringen; Bei dem Versuch, herauszufinden, was mit dem Umgang meiner Konfiguration mit Konfigurationsänderungen nicht stimmte, stolperte und tappte ich in diese Richtung und dachte, dass es für die richtige Person Früchte tragen könnte; Aber letztendlich fand ich offensichtlich einen einfacheren Weg, meine Probleme dieses Mal zu beheben.

    
ross studtman 25.05.2013, 16:18
quelle