View drehen mit Anpassung von Größe und Position

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • View drehen mit Anpassung von Größe und Position

    Schönen guten Morgen,

    ich sitze gerade an einer App für iPad und iPhone. Dabei geht es darum, dass die App im Querformat ein wenig anders dargestellt werden soll als im Hochformat. Die Inhalte bleiben die gleichen, jedoch soll z.B. die Größe des Inhaltsviews vergrößert/verkleinert und an eine andere Stelle verschoben werden. Auch die Schmuckgrafiken (Header, etc.) sollen beim Drehen in der Breite angepasst und ausgetauscht werden.
    Ursprünglich wollte ich in Xcode (interface builder) zwei Views anlegen und beim drehen dann switchen. Nun ist mir aber aufgefallen, dass ich dann die Inhalte auch tauschen muss und dass es viel Arbeit mit sich zieht. Ich kann nämlich nicht einfach zwei Views mit einer Variable verbinden (wäre ja auch unsinnig). Müsste ich dann über tags lösen. Jedenfalls hätte ich so die Elemente beider Ansichten ansprechen und Inhalte tauschen können. Nun habe ich überlegt, ob es nicht - auch aus Performance-Gründen - sinnvoller wäre, die Elemente programmatisch zu verschieben und in ihrer Größe zu ändern. Das hätte dann auch den Vorteil, dass man diese Größen später auslagern könnte und Dynamik reinbringen kann.

    Diese Problematik ist jetzt unabhängig davon, dass ich sowohl für iPad ALS AUCH iPhone entwickle. Die Problematik tritt ja schon auf, wenn ich ein iPad/iPhone habe und dieses drehe.

    Wäre dankbar für euer Feedback, ob zwei Ansichten beim Umpositionieren/Skalieren überhaupt sinnig sind.

    Grüße
    Vivid
  • Hi Vivid,

    also ich habe sowohl schon die eine als auch die andere Lösung gemacht.
    Mitlerweile bevorzuge ich die zwei Views Version. Dann hast Du zwar u.U. mehr IBOUTLET und im IB sieht es weniger übersichtlich aus, dafür muss beim Wechsel der Orientiereung aber eben nur ein View gehided und ein andere gezeigt werden.
    Prinzipiell finde ich diese Lösung auch einfacher zu verwalten. Man kann mal eben in einer Ansicht ein Element verschieben und die andere bleibt davon unbetroffen.
    IBActions starte ich grundsätzlich mit TAGS. Ich habe immer nur eine IBAction für eine Button-Gruppe und ermittele dort über den Tag des Button welche Aktion ausgeführt werden soll. Die Tags mache ich im .h file sauber als define. also z.B.

    #define TAG_ROOTVIEW_MENU_BUTTON_NEW (100)

    damit bleibt der Code auch übersichtlich.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Ich habe mich bisher immer für die Lösung entschieden die Elemente je nach Orientation entsprechend zu positionieren.

    Es ist zwar ein wenig aufwändig, die Positionen und Größen der einzelnen Elemente für die jeweilige Orientation zu ermitteln und in willRotateToInterfaceOrientation:duration: zu setzen, aber ein eigener View für jede Orientation wäre glaube ich von der Programmierlogik erheblich aufwändiger.
  • Hi Claus,

    ich bin jetzt auch nur auf das Problem gestoßen, durch mein anderes Problem letztens. Du erinnerst dich vielleicht an die Sache mit den Buttons und dem selected: Status. Mir ist aufgefallen, dass ich beim Drehen der App immer noch mal den Button selecten muss. Das fand ich persönlich als sehr störend. Und ich habe etwas bedenken, dass ich dann nun auch immer für jede Ansicht auf Aktionen des Users reagieren muss. Angenommen der User klickt im Portrait-View auf einen Link und dreht dann das Device. Dann muss ich wahrscheinlich schauen, dass im Landscape View die Inhalte auch geladen werden. Diese Problematik meinte ich eigentlich. Du verstehst?

    Außerdem ist die Frage, ob ich durch die weiteren IBOUTLETs nicht irgendwann in Performance-Probleme kommen kann. Ich will den Teufel echt nicht an die Wand malen, aber könnte es nicht sein, dass das "neu positionieren" nicht fixer geht? War nur so ein Gedanke.

    Danke und Grüße
    Vivid
  • In solchem Fall bist du mit umpositionieren natuerlich besser bedient. Man sollte es halt abwägen. Wer hindert dich daran es teils/teils zu machen. Den Weg gibt es ja auch noch. Tableview/WebViews etc würde ich auch nicht doppelt machen, aber ImageViews mit Hintergrundbildern oder UIButtons mit CustomIamges etc, die in Portrait halt andere Bilder darstellen müssen als in Landscape weil eben Skalieren schlecht aussieht, die kann man auch gleich doppelt erzeugen und in ein eigenes View packen um dann das ganze View zu ersetzen.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Claus, du hast ja Recht. Mir ist nur aufgefallen, dass ich halt immer nur den View eines ViewControllers mittels viewWithTag: ansprechen kann. D.H. ich müsste die Inhalte beim Drehen der App auch noch mal im anderen View laden.

    Ich hab mal ein Screen beigefügt. In meinen Augen würde ich beim Drehen den gesamten View (Landscape vs. Portrait) wechseln und dann auch noch mal die Inhalte in den Inhaltsview laden müssen. Und das jedes mal, wenn ich die App drehe. Du verstehst was ich meine? :)
  • Vivid schrieb:

    Mir ist nur aufgefallen, dass ich halt immer nur den View eines ViewControllers mittels viewWithTag


    Das verstehe ich jetzt nicht. Wenn Du einen View in einem Controller ansprechen willst, dann mach eine property mit IBOutlet davon. Davon kannst Du so viele anlegen und dann ansprechen wie Du willst.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Ich wollte mit Tags arbeiten um gleich beide Views (innerhalb der beiden Landscape- und Portrait-Views) anzusprechen und den Inhalt dort reinzuballern. Damit ich das nicht immer für jeden View muss.

    So wäre ich beim Laden immer hingegangen und hätte gesagt: "Schiebe den Inhalt in alle Views, die den Tag 1234 haben". Dann müsste ich nicht mehr Anpassungen machen, wenn ich drehe. :)
  • warum machst du nicht einfach einen Inhalt-View welchen Du programmatisch änderst (Also wie DAN vorschlug) und hängst den immer in den entsprechenden Landscape oder Portrait Superview rein, je nachdem was gebraucht wird. Dann must du auch nicht die Inhalte immer zweimal zeichnen.

    Das meinte ich mit Kombination aus beiden Wegen

    Alternativ würde ich eine art "ReloadData" Funktion für meinen Inhaltview schreiben, der im willRotateToInterfaceOrientation aufgerufen wird und immer das aktuelle werdende Inhalt view füllt. Immer beide Views zu füllen halte ich für vollkommen übertrieben.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Wusste halt nicht, ob das:

    "warum machst du nicht einfach einen Inhalt-View welchen Du programmatisch änderst (Also wie DAN vorschlug) und hängst den immer in den entsprechenden Landscape oder Portrait Superview rein, je nachdem was gebraucht wird. Dann must du auch nicht die Inhalte immer zweimal zeichnen."

    so einfach geht.
  • Naja warum nicht.

    z.B. könntest Du einfach einen View inhaltView erstellen (hast du ja anscheinend eh schon) und dann zwei Views ancorViewPortrait und ancorViewLandscape, die jeweils an der Stelle in den Superviews sind wo das InhalteView rein soll. Dann kannst Du ganz einfach mit

    [inhaltView removeFramSuperView];
    [self.ancorViewPortrait addSubView:inhaltView];

    oder

    {self.ancorViewLandscape addSubView inhaltView];

    das Inhalteview genau da platzieren wo es hinsoll.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Hallo,

    stehe derzeit vor der gleichen Frage, daher schliesse ich mich mal hier an...

    Ich würde gerne die Anordnung der Elemente beim drehen ändern. Also werde ich das wohl programmatisch machen.
    Aber ich muss hier ja dann auch noch beachten, ob ich auf dem iPhone bzw, dem iPad unterwegs bin.

    Meine Views mit jeweils den richtigen Elementen liegen in einem Storyboard.

    Hat da jemand einen Tipp?

    Danke,
    Urkman