Xcode 3/1 - Subklassen

Im Tuturoial Absolute Beginners erläutere ich die Ableitung und Instantierung eines custom Controllers im Interface Builder 2. Auch im Buch wird dies angesprochen. In beiden Fällen habe ich mich zu dieser Vorgehensweise entschlossen, weil es für den ersten Schritt einfach geht.

Ging man so vor, so musste beim Erzeugen der Klassen "Add to Project" angeklickt werden, damit Xcode eine Mitteilung bekommt, dass sich eine neue Datei im Projektordner befindet. Im Buch erzeuge ich aber an den meisten Stellen eine Subklasse in Xcode. Auch das ging. Die Sourcen mussten dann in den Interface Builder 2 einglesen werden.

Aber nicht nur die Erzeugung war zweigeteilt, sondern auch die Veränderung, weil der Sourcecode in Xoce verändert werden konnte, aber auch im Interface Builder, Actions und Outlets bearbeitet werden konnten. Wurde ein in Xcode veränderter Sourcetext in den Interface Builder 2 geladen, so hat letzterer ihn einfach analysiert, was nichts anderes als eine Suche nach den IBOutlet- und IBAction-Tags war. Weggefallene Outlets und Actions wurden entfernt, neue hinzugefügt.

Wurden jetzt erneut Outlets oder Actions im Interface Builder 2 hinzugefügt, so war dieser nicht mehr in der Lage, eigenen Code und vom Entwickler in Xcode hinzugefügte Teile sauber zu trennen. Er erzeugte daher wiederum seine Vorlage und startete eine FileMerge-Sitzung mit seiner Version und der alten. Nach einigem Geklicke hatte man dann eine Fusion.

Auf Seite 488 f. nehme ich mal eine Sitzung mit FileMerge vor. Ich bin froh, dies in der nächsten Auflage streichen zu können …

Einigermaßen konnte man sich noch behelfen, indem man den Interface Builder nur die .h erzeugen ließ. Aber auch hier waren etwa in Xcode Instanzvariablen hinzugefügt worden, mit denen Xcode nichts anfangen konnte.

Igitt …