webentwicklung-frage-antwort-db.com.de

Xcode ändert unverändertes Storyboard und XIB-Dateien

Storyboards sind aus Sicht des Git-Workflows eher ein königlicher Schmerz, wenn mehrere Personen an ihnen zusammenarbeiten. Für das XML in der .storyboard-Datei werden beispielsweise die toolsVersion- und systemVersion-Attribute des Start-Tags <document> Geändert, je nachdem, welche Konfiguration der neueste Dateimanipulator gerade ausführt. Das genaue Synchronisieren der Xcode-Versionen aller scheint bei toolsVersion zu helfen, aber systemVersion ändert sich unabhängig von der jeweiligen Mac- und/oder OS X-Version, die der Entwickler ausführt.

Das ist idiotisch, aber meistens harmlos. Was uns jedoch beunruhigt, ist, dass zu anderen Zeiten einige andere Änderungen automatisch am Storyboard vorgenommen werden, indem sie nach einem git pull Geöffnet werden. Das heißt, Alice nimmt Änderungen an einem Storyboard vor, schreibt sie fest und legt sie im Repository ab. Bob zieht dann Alice Änderungen und öffnet das Storyboard, um weitere Änderungen vorzunehmen. In dem Moment, in dem er das Storyboard öffnet, ändert sich das Dateisymbol sofort in einen geänderten, aber nicht gespeicherten Zustand, und ein git status Zeigt an, dass eine beliebige Anzahl seltsamer Änderungen aufgetreten sind. All dies, ohne dass Bob irgendetwas geändert oder die Datei selbst gespeichert hat.

Die häufigste automatische Änderung ist das Verschwinden oder Wiederauftreten der gesamten <classes> - Tag-Hierarchie am Ende einer Storyboard-Datei. Wir haben nicht herausgefunden, was das verursacht. Möglicherweise befinden sich mehrere lokalisierte Versionen eines Storyboards in verschiedenen .lproj-Verzeichnissen. Wenn Sie diese in Interface Builder öffnen, wird die Klassenhierarchie möglicherweise spontan von einigen entfernt und zu anderen hinzugefügt oder in einigen alleine gelassen. Dies verursacht eine Menge Rauschen in git diff, Beeinträchtigt jedoch nicht die Funktionalität. Wir werden oft selektiv die tatsächlich vorgenommenen Änderungen in den Git-Index einfügen, diese festschreiben und dann einfach die spontanen, unsinnigen <classes> Änderungen verwerfen. Dies soll Commits klein halten und Nizza, wie sie sein sollen. Aber irgendwann wird es einfach zu viel, da Xcode die Änderungen immer wieder wiederholt und jemand sie nur mit ein paar anderen Dingen erneut festschreibt ersichtlichen Grund. (Unsere Commit-Geschichte hat viel Schwur darüber.)

Ist jemand anderes dieses Verhalten zu sehen? Handelt es sich um einen Xcode-Fehler oder ein Konfigurationsproblem auf einem oder mehreren unserer Entwickler-Macs? Wir haben ein ähnliches Verhalten bei der Zusammenarbeit mit XIB-Dateien festgestellt, aber Storyboards scheinen dafür anfälliger zu sein.

128
JK Laiho

Dies ist kein Fehler, sondern eine Folge der Verarbeitung von Storyboard-Dateien durch Xcode. Ich schreibe ein Programm zum Vergleichen und Zusammenführen von Storyboard-Dateien (GitHub-Link) und habe Stunden damit verbracht, die Logik der Storyboard-Dateien und deren Verarbeitung durch Xcode zu analysieren. Folgendes habe ich entdeckt:

  • Warum treten seltsame Änderungen in Storyboard-Dateien auf? Xcode verwendet die NSXML-API, um Storyboard-Dateien in eine NSSet-basierte logische Baumstruktur zu zerlegen. Wenn Xcode Änderungen schreiben muss, erstellt es ein NSXMLDocument basierend auf der logischen Baumstruktur, löscht die Storyboard-Datei und ruft XMLDataWithOptions: Auf, um die Datei erneut zu füllen. Da Sets die Reihenfolge ihrer Elemente nicht beibehalten, kann bereits die kleinste Änderung die gesamte Storyboard-XML-Datei ändern.

  • Warum verschwindet das Klassen-Tag oder erscheint es zufällig wieder? Der Abschnitt <class> Ist nichts weiter als ein interner Xcode-Cache. Mit Xcode werden Informationen zu Klassen zwischengespeichert. Der Cache ändert sich häufig. Elemente werden hinzugefügt, wenn Dateien der Klasse .h/.m Geöffnet und entfernt werden, wenn Xcode den Verdacht hat, dass sie veraltet sind (zumindest ältere Xcodes verhalten sich so). Wenn Sie das Storyboard speichern, wird die aktuelle Version des Caches gespeichert, weshalb sich der Abschnitt <class> Häufig ändert oder sogar verschwindet.

Ich habe Xcode nicht rückentwickelt. Ich habe diese Beobachtungen gemacht, indem ich mit Xcode- und Storyboard-Dateien experimentiert habe. Trotzdem bin ich mir fast zu 100% sicher, dass es so funktioniert.

Schlussfolgerungen :

  • Cache-Bereich ist unwichtig; Sie können jede Änderung ignorieren.
  • Im Gegensatz zu dem, was Sie in allen Foren finden, ist das Zusammenführen von Storyboard-Dateien keine komplizierte Aufgabe. Angenommen, Sie haben den MyController1 - Ansichtscontroller in einem Storyboard-Dokument geändert. Öffne die Storyboard-Datei und finde so etwas wie dieses <viewController id=”ory-XY-OBM” sceneMemberID=”MyController1”>. Sie können sicher nur Änderungen in diesem Abschnitt festschreiben und alles andere ignorieren. Wenn Sie Segmente oder Einschränkungen geändert haben, schreiben Sie auch alles fest, das “ory-XY-OBM” Enthält. Einfach!
78
Marcin Olawski

Dies ist ein Fehler in XCode 4.5+, ich hoffe, dass er behoben wird, und ja, es ist ein PITA.

Hier ist der vollständige Fehler bei Apple

Wie vermeide ich unbeabsichtigte Xcode-Änderungen an Storyboard-Dateien?

17
deleted_user

Dieses Problem kann durch die äußerst umsichtige Verwendung von git add -p Für alle von Xcode generierten Dateien, einschließlich Storyboards, XIBs, Core Data-Modelle und Projektdateien, etwas gemildert werden die tatsächliche Schnittstelle/Modell/Projekt.

Die häufigsten Junk-Änderungen, die ich auf Storyboards gesehen habe, sind die Versionsnummern des Systems (wie Sie bereits erwähnt haben) und das ständige Hinzufügen und Entfernen des Abschnitts <classes>, Dessen Auslassung ich noch nie gesehen habe, was zu Problemen geführt hat. Für XIBs ist es das Hinzufügen und Entfernen von <reference key="NSWindow"/>, Was in Cocoa Touch nicht einmal eine Klasse ist. Einfach wow.

Stellen Sie es sich wie das Meer vor: Es gibt sowohl Ebbe als auch Flut. Lass es dich überfluten.

Ahh. Das war's.

Sie können diese Änderungen ignorieren, wenn Sie Ihre Änderungen speichern, die Junk-Änderungen zurücksetzen und ein sauberes Commit durchführen.

Der einzige technische Vorteil von Storyboards gegenüber XIBs ist, dass Apple noch nicht kastriert hat, dass FileMerge sich weigert, in Konflikt stehende Storyboards zusammenzuführen. (FileMerge war früher in der Lage, XIBs zusammenzuführen, aber neuere versionen haben das kaputt gemacht.

Bitte melden Sie viele Fehler zu all diesen Problemen unter http://bugreporter.Apple.com/ ! Und vergessen Sie nicht, Einträge auf OpenRadar zu erstellen.

11
Phil Calvin

Hier eine andere Antwort geben, weil sich diese Situation stark verbessert hat. Das XML für die XIB-Datei, die das StoryBoard darstellt, wurde stark vereinfacht.

Ich habe auch vor kurzem die Kugel gebissen und begonnen, die Schnittstelle in Xcode zur Quellcodeverwaltung zu verwenden. Ich bin seit Jahren auf der Kommandozeile und dort glücklich, aber die Benutzeroberfläche ist schön und ermöglicht das Teilen von Commits. Dies ist sehr wichtig, wenn Sie ein Ticketing-System verwenden, das mit Commits verknüpft ist.

Wie auch immer, ich habe heute bemerkt, dass es eine Änderung im Storyboard gab und das eingebaute Diff zeigte mir, dass es sich um ein einzelnes Attribut im Dokument-Tag (systemVersion) handelte. Also keine große Sache.

Ich habe Artikel gelesen, in denen Leute sagen, dass SBs in ihren Teams aufgrund von Zusammenführungsproblemen verboten waren. Totaler Wahnsinn. Sie sind so erstaunlich, besonders jetzt, wo sie intelligentes Autolayout eingebaut haben, dass Sie es wirklich verpassen, wenn Sie sie nicht benutzen.

6
Rob

Es ist hilfreich zu wissen warum, dass dieser Wahnsinn passiert, aber für diejenigen, die daran glauben, ihre Projekte frei von Warnungen zu halten, und die nur einen schnellen und schmutzigen Weg suchen, um ihre Projekte wieder in einen gesunden Zustand zu versetzen:

  1. Legen Sie nichts fest, bis Sie ausdrücklich dazu aufgefordert werden.

  2. Öffnen Sie Xcode und erstellen Sie ein neues Storyboard (Befehl + N> iOS> Benutzeroberfläche> Storyboard). Ich nehme an, Sie nennen es den Standardnamen Storyboard.storyboard.

  3. Öffnen Sie das Storyboard, gegen das Xcode verstoßen hat. Ich gehe davon aus, dass dies Base.lproj/Main.storyboard Ist.

  4. Wählen Sie alles im Storyboard aus und kopieren Sie es (Befehl + A, dann Befehl + C).

  5. Öffnen Sie Storyboard.storyboard.

  6. Kopieren Sie alles und fügen Sie es in Storyboard.storyboard Ein.

  7. Schließen Sie Xcode.

  8. Öffnen Sie ein Terminal und wechseln Sie in Ihr Repository.

  9. Ersetzen Sie Main.storyboard Durch Storyboard.storyboard (mv Storyboard.storyboard Base.lproj/Main.storyboard).

  10. git add Base.lproj/Main.storyboard; git commit -m "Fix Xcode's insanity."

  11. Ignorieren Sie die Änderungen an project.pbxproj Über git checkout -- project.pbxproj. Wenn Sie die Datei git diff Haben, werden Sie feststellen, dass gerade Informationen zu unserem temporären Storyboard hinzugefügt wurden (das nicht mehr existiert).

  12. Öffnen Sie Xcode Backup und stellen Sie sicher, dass die Warnungen verschwunden sind.

  13. Atmen.

3
Kayce Basques