wird neben mir wohl mal wieder kein Schwein interessieren, aber für mich übertrifft es sogar Zubis Patzer:
XCode kriegt Refactoring-Möglichkeiten !!!

Endlich. Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.

1. Zwischenbemerkung für die Nichtprogrammierer: XCode ist das Programm, in welchem OS X-Programme programmiert werden – eine sogenannte Entwicklungsumgebung oder IDE. Man kann auch ohne IDE programmieren, einfach mit einem simplen Texteditor, aber IDEs helfen einem dabei, den Überblick zu bewahren, alles ein bisschen näher zu haben und bestimmte Dinge per Knopfdruck zu automatisieren. Um die richtige IDE mit den richtigen Einstellungen gibt es zuweilen blutige Glaubenskriege – beim programmieren von OS X-Programmen ist aber XCode haushoch Marktleader, nicht nur weil es gratis ist (IDEs können brutal teuer sein), sondern weil es halt einfach die einzige IDE ist, die speziell auf die Charakteristika und Mechanismen von OS X ausgelegt ist.

2. Zwischenbemerkung für Nichtprogrammierer: Refactoring bedeutet das ändern des Codes, ohne die eigentliche Funktion zu ändern. Beispielsweise hatte ich bei meinem MacAlarm ein Objekt namens iTunesAlarm erstellt, als eine Abstraktion über das losgehen eines Radioweckers, in welchem festgelegt wird, um welche Uhrzeit welche Playlist in welcher Lautstärke abgespielt werden soll. Dann merkte ich aber, dass ich noch einen zweiten Wecker in MacAlarm integrieren will, der blöde nervige Weckertöne vor sich gibt, der aber gewisse Charakteristiken mit dem iTunesAlarm teilt, zB dass er eine Einstellung für die Zeit und eine für die Lautstärke hat. Ich will also das Objekt iTunesAlarm aufteilen: ein Teil der die generellen Charakteristika eines Weckers besitzt, und ein zweiter Teil, der nur für einen iTunesWecker gilt und auf Mechanismen des generellen Weckers zurückgreift (in der Programmierersprache: iTunesAlarm ist eine Subklasse des abstrakten Objekts Alarm und erbt dessen Merkmale (Attribute) und Fähigkeiten (Methoden). Refactoring ist nun die reine Handarbeit dieses aufteilens – beispielsweise, dass überall, wo bisher auf iTunesAlarm verwiesen wurde (und das sind viele Orte in MacAlarm) nun nicht mehr iTunesAlarm im Code steht sondern Alarm. Kleine Sachen, die aber in grosser Menge und absolut zuverlässig gemacht werden müssen, denn programmieren erlaubt keine Schreib- und Flüchtigkeitsfehler, und mit Copy und Paste verliert man auch fast immer. Die Funkionalität wird nicht geändert, aber Struktur und Darstellung des Codes.

Wo war ich? ah ja: Ich habe mich immer gefragt, weshalb Apple da derart hinten drein ist.
XCode ist meines Erachtens die stärkste aller IDEs wenn es um das erstellen eines neuen Programmes geht. Nirgendwo kriegt man in derart kurzer Zeit derart viele Funktionalitäten und erst noch eine brauchbare Oberfläche hin. Aber: Programmieren ist nicht einfach neues erschaffen. Man verbringt deutlich mehr Zeit am abändern von Code (sei es um Bugs auszumerzen oder die Möglichkeit zu haben, neue Features einzuklinken. Und am meisten Zeit braucht man, um den alten Code zu verstehen, den man letzte Woche oder gar letztes Jahr geschrieben hat, noch schlimmer, wenn es nicht mal der eigene Code ist, den man bearbeiten möchte. Peter Hallam’s Artikel ist zu diesem Thema glaube ich immer noch das beste was ja geschrieben wurde – er spricht darin von folgenden Verhältnissen:
New Code: 5%
Modifying Existing Code: 25%
Understanding Code: 70%
Wohlbemerkt: Hier geht es um Zeit-Verhältisse, aber die Hirnschmalz-Verteilung dürfte ähnlich sein.

Refactoring ist der absolut zentrale Schlüssel zu den Punkten zwei und drei: Um Code zu ändern, muss man ihn fast immer neu strukturieren. Und chaotisch durcheinander gewürfelter Code ist fast unmöglich zu verstehen. XCode aber kannte bis dato kaum oder nur winzige Refactoring-Mechanismen. Sogar wenn ich nur den Namen einer Klasse verändern wollte, musste ich a) im Editor ein Search/Replace über alle Files machen (und dann nicht etwa automatisch „Alle ersetzen“, sondern einzeln durch alle Dateien durchgehen, denn vielleicht gab es neben dem zu ändernden iTunesAlarm auch mal ein iTunesAlarmDelegate oder was auch immer, das von der Änderung nicht betroffen sein sollte. Und wenn dann alles ersetzt war, wurde es erst schmerzhaft: Die Bindings in Interface Builder (dem Tool, mit dem man die graphische Oberfläche eines Programms erstellt) reagiert nicht auf solches Search/Replace. Da musste man alle Elemente einzeln durchgehen und manuell abändern, und wehe man vergass es irgendwo – denn dann gibts beim compilieren auch keine Fehlermeldung – sondern einfach einen simplen Absturz im fertiggestellten Programm. Very very nice.

Vor XCode arbeitete ich meist mit Eclipse, einer IDE die umfangreiche Refactoring- Funktionen anbietet. Der Schock, als ich mit XCode anfing war gross: Ich konnte mir kaum vorstellen, dass man heutzutage noch so arbeiten kann und suchte tagelang nach entsprechenden Funktionen. Nix da. XCode 2.0 ist sackstark, wenn es um das erstellen geht, um den ersten Entwurf eines Programm. Die ersten 5%. Der Rest der Arbeit, das verfeinern, abändern, umdenken, die restlichen 95%, die waren bei XCode immer die Hölle.

Und nun gibts mit XCode 3 in OS X Leopard nicht nur Garbage Collection und Block Folding, jetzt hat Apple auch noch Refactoring-Tools:

To allow you to work more rapidly and effectively, Xcode 3.0 offers support for re-factoring your Cocoa applications. This means you can now make structural changes to your source code without accidentally changing its behavior. Instead of performing multiple search and replace operations, you can rename an instance variable and update all of the methods that work with that variable, including indirect access through KVC style methods. This re-factoring support extends beyond your source code and will even update bindings set in your nib files

Läck, freue ich mich auf XCode 3. Und weil mein iBook mit Leopard kaum noch klarkommen wird, freu ich mich auch schon jetzt auf die neue Hardware im 2007. Das wird ein langes warten…

Ah, das wurde ja auch Zeit. Uni vorbei, Pendenzen abgebaut und die WM nimmt auch nicht mehr soviel Zeit in Anspruch wie auch schon. Als Warmup für Cocoa zwei kleinere Projekte:
Mein guter alter iTunes-Wecker Alarm Clock S.E. verweigert seit einiger Zeit den Dienst; Ersatz ist nötig, und gratis soll er auch noch werden. Erhoffte Lerneffekte:

• Applescript von Cocoa aus steuern.
• Umgang mit Schlafmodus
• Core Data und Bindings

Und dann noch ein kleines Ausgaben-/Einnahmen-Überwachungstool, welches ich parallel von iBook und G5 aus benutzen kann. Erhoffte Lerneffekte:

• Core Data und Bindings
• Rendezvous
• .mac SDK
• Vorbereitung für ein saubere Buchhaltungs-Programm für OS X.

Ein erstes ist mal schon erledigt: Abfragen von iTunes aus einer Cocoa-Klasse hinaus. Applescript ist noch nicht so wirklich in der Zeit von Objective-C angekommen, zuviel läuft noch über das C aus dem alten Zeiten. Ich habe nun mal eine Helferklasse erstellt, die simple Befehle und Abfrage in zwei Zeilen ermöglicht. Mehr dazu im Post zu APApplescriptHandler.

Wenn es mit dieser Geschwindigkeit weiter geht, werden das ganz geile Ferien….

So, I wanted to query iTunes from within a Cocoa-App for all of its playlists. Sounds simple, doesn’t it? And telling iTunes to start playing must be even simpler, or not?

Of course, you could do this quit simple:
– Get the path of the iTunes Library
– Parse the iTunes Library.xml for playlist entries
– use osascript(1) to tell iTunes to start playing the playlist.
Simple as that. But heck – somehow this does not really look satisfying. Parsing another app’s Property List and Library? Going to shell to execute Applescript? Pleeeease…

Next Step: Let’s check the API for Apple Events
e Events. Hummm. Stranded in Carbon? Yup: No classes, no easy-understood-easy-used methods – plain obfuscated C. Nonononono.

OK, another way: Using Foundation’s NSAppleScript, a nice wrapper for the API. But wait: Why is it necessary to write 10 or more lines for a simple query? And why do we find ourselves in pure ugly C-Code after Line 5? Nope, not what I was looking for.

What I really want is a handle, which I can connect to an app, and then just posting a Message and retrieve the result. As far as I can see, there is nothing which would provide some simple of use within an OO construct. Sounds like a job for a Student on holiday… Enter APApplescriptHandler

APApplescriptHandler * iTunes = [[APApplescriptHandler alloc] initWithApplicationName:@“iTunes“];
[iTunes performMessage:@“playpause“];
NSString * string = [iTunes getStringForMessage:@“name of current track“];
NSArray * array = [iTunes getArrayOfStringsForMessage:@“

ApplescripHandler; Interface; Implementation
This is one of my first things done in Objective-C – so the Code most probably stinks for any experienced Programmer. I sure hope it will stink for me too in some months. But experienced Coders most propably won’t have any use for this class, and for newbies it will work and look just fine. Just be sure to catch the NSException if you use getArrayOfStringsForMessage: with a Message, which does not return a list. Every other Error I could think of is treated internally and results in a returning nil.
Any feedback is very welcome.

A big booo to Apples Documentation once again. In a very boring Human-Computer-Interaction-Lecture I finally went along with my Hattrick-Viewer-Project, which slept for some months. Todays task look quite simple: Add the possibility to drag a Link onto the Application, so that the URL of the Link gets evaluated and the match behind the Link gets added to the HT-Live-List.

Dropping the Link to the Applications Main-Window is easy and well documented. But I wanted to enable dropping links to the Dock-Icon too, and this was sorta trickier than I expected…

Weiterlesen →