iPhone größen

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

  • macmoonshine schrieb:

    Warum man den Interface-Bilder nicht benutzt, konnte ich noch nie so richtig verstehen


    zum Glück ist man da ja frei und kann es machen wie man möchte

    macmoonshine schrieb:

    Wo ist der Mehrwert von dem Framework?


    hatte ich ja schon geschrieben, da ich den IB nicht benutze und das dann im Code mache empfinde ich es angenehmer weil es deutlich weniger code ist, zusätzlich gefällt mir die Visual Format Language optisch nicht so wirklich

    muss aber zugeben das ich da bisher noch nicht konsequent war und das noch nicht komplett in Projekten genutzt habe , bisher eher zum Framework gegriffen habe
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • nussratte schrieb:

    hatte ich ja schon geschrieben, da ich den IB nicht benutze

    Hatte ich schon so verstanden; aber aus welchem Grund?

    nussratte schrieb:

    und das dann im Code mache empfinde ich es angenehmer weil es deutlich weniger code ist,

    Dafür ist dann ja gerade die Visual Format Language gut. Da setzt du beispielsweise mit einer Anweisung alle horizontalen Restriktionen mehrerer Views auf einmal. Und gemessen an der Komplexität der Aufgabe ist sie noch recht intuitiv. Das Kurzer-Code-Argument trifft bei dem Framework jedenfalls nicht zu.

    nussratte schrieb:

    zusätzlich gefällt mir die Visual Format Language optisch nicht so wirklich

    Naja, zur Zeit scheint Syntactic Sugar schwer in Mode zu sein. ;)
    „Meine Komplikation hatte eine Komplikation.“
  • macmoonshine schrieb:

    aber aus welchem Grund?


    das mag an Xcode und nicht am IB/Storyboard selbst liegen

    - mit storyboards deutlich mehr merge Conflicte als ohne
    - wenn man ein storyboard nur auf macht ohne was zu ändern wird es in git trotzdem als Änderung erkannt
    - wenn man sich die ganzen ViewController alle schön optisch hingelegt hat, es schließt und wieder aufmacht sind die VC etc alles wieder durch die gegend geschoben
    - wenn man es nicht immer wieder neu sortiert nach dem neuen wieder aufmachen ist es einfach nur unübersichtlich
    Ich weiß nicht immer wovon ich rede aber ich weiß das ich Recht habe. :saint:
  • Ah, die Punkte kommen mir bekannt vor. Damals™ war das noch die gute alte 'To .nib Or Not To .nib' Diskussion…

    Dazu mal meine Erfahrungen:

    • Merge Konflikte entstehen, wann immer zwei oder mehr Leute an ein und derselben Datei aus demselben Commit arbeiten und Änderungen einpflegen, die sich nicht auflösen lassen.
      Beispielsweise eine hart codierte IP, die im Ursprungscommit auf die Loopback zeigt und von beiden dann auf die lokale IP umgebogen wird.
      Fingert immer nur einer an der Datei/dem Storyboard/der .xib herum, reduziert das die Merge Konflikte unglaublich.
      Wenn man den GitFlow Workflow nutzt, fingert schon fast per Definition immer nur einer an der Datei/dem Storyboard/der .xib herum.

      Git ist halt kein SVN. In Git wird selten mit Reverts, in SVN wird selten mit Branches gearbeitet.
      Wenn man in Git mit Branches arbeitet, wird man ganz plötzlich eine Menge Probleme los.

    • Xcode haut nicht einfach spontan irgendwas nach dem Öffnen in die .xibs. Ein beispielhafter Diff zeigt, dass hauptsächlich Versionsinformationen und mit der Version des .xib einhergehende Änderungen gespeichert werden. [1]

      Wer also nach jedem Xcode Update einmal alle .xibs öffnet (Branch: feature/xcode-update), speichert, committed, in den develop Branch merged (mit --no-ff zur Übersicht) und den Kram pushed, hat dann mindestens bis zum nächsten Xcode Update keine Probleme mehr. Zumindest wenn alle Entwickler mit derselben Version arbeiten. Was sie auch tun sollten.

      Zu Merge Konflikten kann es hier also nur kommen, wenn beide mit unterschiedlichen Xcode Versionen die Datei öffnen (beide tools- und systemversions haben einen anderen Wert als zuvor) oder wenn beide das Dokument öffnen und abspeichern, wenn sie eine vom Ursprung abweichende Displayauflösung haben.

    • Das mit der Unordnung kann ich nicht bestätigen. Wenn ich die View Controller hinsortiere, speichere, andere Datei wähle, beende, öffne, Storyboard wähle steht alles noch genau so da wie ich es verlassen habe.


    Generell hat sich nach meiner Einschätzung die Integration der Non-Sourcecode Dateien von Xcode in ein SCM seit den .nib Dateien immens gebessert und wird auch immer weiter verbessert.


    1)
    diff --git a/Base.lproj/Document.xib b/Base.lproj/Document.xib
    index 10269e7..4119afe 100644
    --- a/Base.lproj/Document.xib
    +++ b/Base.lproj/Document.xib
    @@ -1,7 +1,8 @@
    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    -<document type="com.apple.InterfaceBuilder3.Cocoa.XIB" version="3.0" toolsVersion="5056" systemVersion="13E28" targetRuntime="MacOSX.Cocoa" propertyAccessControl="none" useAutolayout="YES">
    +<document type="com.apple.InterfaceBuilder3.Cocoa.XIB" version="3.0" toolsVersion="6250" systemVersion="14B25" targetRuntime="MacOSX.Cocoa" propertyAccessControl="none" useAutolayout="YES">
    <dependencies>
    - <plugIn identifier="com.apple.InterfaceBuilder.CocoaPlugin" version="5056"/>
    + <deployment identifier="macosx"/>
    + <plugIn identifier="com.apple.InterfaceBuilder.CocoaPlugin" version="6250"/>
    </dependencies>
    <objects>
    <customObject id="-2" userLabel="File's Owner" customClass="Document">
    @@ -12,12 +13,12 @@
    - <customObject id="-3" userLabel="Application"/>
    + <customObject id="-3" userLabel="Application" customClass="NSObject"/>

    - <rect key="screenRect" x="0.0" y="0.0" width="1920" height="1058"/>
    + <rect key="screenRect" x="0.0" y="0.0" width="1440" height="877"/>
    @@ -31,7 +32,7 @@
    - <rect key="screenRect" x="0.0" y="0.0" width="1920" height="1058"/>
    + <rect key="screenRect" x="0.0" y="0.0" width="1440" height="877"/>

    Was die Sizing - Unterschiede angeht: Ich hatte das Ding auf eine ansprechende Größe am iMac 27" gezogen.
    Geöffnet habe ich das Dokument gerade auf einem MacBook Pro. Xcode ist so freundlich, die Sachen automatisch anzupassen, damit das auf den Screen passt.

    Ich sag mal so: Wenn man im Dokument arbeitet, müssen die Änderungen committed und gepushed werden.
    Wenn man nicht an dem Dokument arbeitet, warum nimmt man es dann nicht wieder aus der Staging Area via Source Control > Discard Changes raus?
    Oder, um noch ein bisschen frecher zu werden: Wenn man nicht an dem Dokument arbeitet, warum öffnet man es dann überhaupt? ;)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P