ME & IT

XCode, iOS-Retina-Resourcen und das Problem mit Subversion

XCode tut sich manchmal etwas schwer mit Subversion. Man merkt eindeutig, dass GIT die von Apple favorisierte Versionsverwaltungs-Lösung ist. Viele Programmierer nutzen darum Subversion einfach über das Terminal statt aus XCode heraus. Probleme macht iOS-Programmieren oft dabei das Hinzufügen von Retina-Resourcen zu Subversion.

Ein Beispiel: Wir haben ein Bild namens MeinBild.png und die zugehörige Retina-Variante [email protected] . Das Kommando zum Hinzufügen der Retina-Version wäre

svn add [email protected]

Subversion wird jedoch durch das @ gestört. Für SVN signalisiert das letzte @ einer Zeile die Angabe einer Revision.

Die Lösung für dieses Problem ist bei Subversion-Kommandos einfach ein weiteres @ ans Ende des Dateinamens anzuhängen:

svn add [email protected]@

Die genannte Lösung ist detaillierter als hier auf StackOverflow diskutiert worden.

Falls SQLServer ReportingServices (SSRS) mal Leerzeichen verschluckt

Heute ist uns im Projekt aufgefallen, dass SSRS-Tabellenfelder und Textboxen gerne mal Leerzeichen verschlucken. Ärgerlich ist das bei fest formatierten Textbausteinen, wie sie bei Labeltexten häufiger auftreten. Das Problem liegt daran, dass Tabelleninhalte im Report als HTML gerendert werden. Darunter leiden Zeilenumbrüche zwar nicht, aber Spaces am Zeilenanfang oder Folgen von mehreren Spaces werden dabei einfach verschluckt.

Die Lösung ist es wie bei HTML üblich Non-Breaking-Spaces in den Report zu streuen. Diese kann man mit Tastencode ALT-0160 in Windows erzeugen.

Natürlich sind diese wieder alles andere als schön in der Datenbank mit den Labeltexten und unpraktisch beim Einpflegen der Texte.

Besser ist es also die Spaces im Report zu wandeln. Dies kann in der Expression der entsprechenden Control passieren mittels

=REPLACE(Feld.Value," ", " ")

Das zweite Space in der Expression wird dabei natürlich als ALT-0160 via Ziffernblock eingegeben.

Windows XP: 32 oder 64bit?

Heute stand die Installation von Eclipse auf einem Firmenlaptop an. Auf der Download-Seite galt es dabei direkt eine Entscheidung zu treffen: Will ich die 32 oder 64bit Version von Eclipse?

Das Betriebssystem des Rechners zu ermitteln ist ja noch trivial, wie aber erkennt man bei Windows XP welche Variante man fährt? Die nötigen Antworten liefert der Systemeinstellungs-Dialog (auch wenn das auf den ersten Blick nicht so scheint):

 

Findet sich hier unter System: kein Hinweis auf 64bit (a la "Windows XP Professional x64") handelt es sich noch um die 32bit Variante des Betriebssystems.

 

BBEdit Killerfeature: Copy as Styled HTML

Ich gebe es zu: Eigentlich habe ich BBEdit nur aus purer Neugier und wegen des stark reduzierten Preises gekauft. Ich hatte im Vorfeld schon viel Gutes über den Editor gehört, hatte die kostenfreie Lite-Variante Textwrangler schon lange im Einsatz, und wollte nun einfach mal spielerisch entdecken, was alles mit der Hilti unter den Programmier-Editoren möglich ist.

Eines der Features das ich dabei entdeckt und sofort favorisiert habe ist die Möglichkeit, Quellcode in der Art und Weise wie ich ihn optisch in BBEdit aufbereitet habe als HTML zu kopieren. Das ist wie geschaffen für Code-Passagen, die ich in meinem Blog zeigen will. Hier einmal ein Beispiel, dass ich unüberarbeitet eingefügt habe:

- (void) viewWillAppear:(BOOL)animated {
    self.searchlabel.text = self.searchterm;
    self.xmltextview.text = @"";
    [super viewWillAppear:animated];
}

Da BBEdit eine ganze Menge an Programmiersprachen und Markup-Typen erkennt, ist das eine ziemlich praktische Sache für mich. Ich bin ja mal gespannt, was ich noch so alles über die Zeit entdecke.

Ein Hinweis noch: Der Kauf über die Webseite scheint mir in diesem Fall eine bessere Wahl als der Kauf via AppStore zu sein: BBEdit hat in der Mac AppStore Variante nicht alle externen Tools mit an Bord und man muss sie so umständlich Nachinstallieren. Außerdem erhält man auf der Webseite bereits die Version 10, die aber im Mac AppStore noch nachgeliefert wird (hier ist derzeit noch Version 9.6.3 eingestellt).

Image Cache Probleme von XCode 4 in den Griff kriegen

Gestern hatte ich schon darüber berichtet, dass XCode 4 und sein integrierter Interface-Builder manchmal Probleme mit dem Anzeigen von Images in der IDE haben. Das Problem war temporär durch Verschieben oder Umbenennen des Projektverzeichnisses zu lösen, so daß ich fehlerhafte Cache-Strukturen vermutet.

Heute habe ich herausgekriegt wie das Problem entsteht und wie man es lösen kann. Zunächst einmal liegt es weder an korrupten Projektdateien noch an einem ausstehenden CLEAN auf das Projekt oder Target. Das ist sicher schon mal beruhigend: Es ist nichts kaputtgegangen.

Den wahren Übeltäter habe ich gefunden als ich in die Xcode Preferences geschaut und dort das Locations-Menü inspiziert habe. Hier gibt es Einträge für "derived data", also "abgeleitete Daten" wie Builds, Logs und Indexes.

Und diese "Derived-Data"-Ordnerstrukur ist die Problemquelle. Hier werden Resourcen, die im XCode-Quellverzeichnis liegen, für die IDE in gewandelter Form temporär gecached. Der Interface-Builder zieht in der IDE seine Images aus diesem Ordner, nicht direkt aus dem Quellverzeichnis.

Manchmal wenn man nun Bilddateien verschiebt oder neu in XCode in Gruppen anordnet verliert XCode den Zusammenhang zwischen Cache und Quelle. Genau das ist der Zeitpunkt ab dem Bilder im Interface-Builder nicht mehr angezeigt werden.

Ein CLEAN löst das Problem nicht da es nur die Compiler-Caches leert.

Ein Kopieren des Projekts in einen neuen Ordner legt auch einen neuen Derived-Data-Ordner an. Jedoch bleibt auch der alte Derived-Data-Ordner bestehen, so daß beim Zurückkopieren in den alten Originalordner das Problem wieder auftaucht.

Mit dem Organizer kann man die Derived-Data-Ordner einer Anwendung anzeigen:

Und exakt hier kann man diese Caches auch gefahrlos löschen. Danach sind alle Probleme mit dem Interfacebuilder beseitigt und die Bilder werden wieder korrekt angezeigt. Alternativ können die zugehörigen Ordner auch mittels Finder oder Terminal aus den angegebenen Pfaden gelöscht werden.

 

Falls InterfaceBuilder mal Images verschluckt

Sollte XCode mal Eure Images nicht mehr anzeigen in NIBs (obwohl sie im laufenden Programm oder im Simulator normal zu sehen sind):

• Einfach Xcode schliessen,
• den Projekt-Ordner auf den Desktop kopieren,
• das Projekt aus dem kopierten Ordner öffnen.

Mysteriöserweise funktionieren die NIBs dann auch im Interfacebuilder wieder.

Das ganze scheint mir ein internes Caching-Problem des Interfacebuilders zu sein, und das egal ob in Version 3 oder 4. Ich denke das Problem tritt verstärkt dann auf wenn man das Projekt auf mehreren Rechnern in verschiedenen Ordnern bearbeitet und zwischen den beiden Maschinen ab und an hin- und herkopiert.

Das große UITextView-Rätsel

Eben durfte ich bei meiner Cocoa-Einarbeitung das große UITextView-Rätsel lösen.

Die Fragestellung dabei: Wie setzt man den Font einer UITextView-Control via InterfaceBuilder?

Hintergrund des Problems: Jedes andere Control-Element zeigt ein Fontfeld im Inspector. Der UITextView nicht. Klar ginge es programmatisch, aber das wäre ja geschummelt. Es sollte schon beim interaktivem Editieren des Nibs möglich sein.

Die Lösung ist so einfach, dass man kaum darauf kommen kann: Man betätigt einfach CMD-T sobald das TextView-Element selektiert ist. So wie fast überall in OSX.

Warum aber ausgerechnet diese Control das Font-Attribut nicht auch im Inspector anbietet bleibt weiterhin ein Rätsel.

Von Word-Vorlage nach SSRS-Report

Derzeit erstelle ich für einen Kunden mehrere neue Reports mittels SQLServer Reporting Services (SSRS). Die Vorgaben dafür sind mehrere Beispiel-Word-Dokumente, die möglichst genau umzusetzen sind. Ein Szenario, das vermutlich ziemlich häufig auftritt, das sich was Zeilenabstände angeht aber garnicht mal so leicht gestaltet: Das Demodokument beinhaltet mehrere Textboxen, in jeder sind die Fontgrößen leicht anders eingestellt, und Word kümmerte sich ja selbstständig um die Abstände beim Umbruch. Wie simuliert man so etwas aber in SSRS ohne viel Rechnen und Herumschieben von Textboxen? Ich habe mir dabei wie im folgenden beschrieben geholfen.

jqGrid hat echt was

In den letzten Wochen konnte ich mich etwas ausgiebiger mit jqGrid beschäftigen, und ich muss sagen: Diese AJAX-Tabellen-Komponente hat was. Es gibt kaum etwas, was ich als Feature in anderen Tabellenkomponenten kennengelernt habe, das hier fehlen würde. Die zugehörige Demoseite beweist das denke ich eindrucksvoll. Allerdings ist der Einstieg nicht ganz leicht, der Technologiebaum dahinter ist schon recht tief.

jqGrid baut auf JQuery UI auf, das dann widerum auf JQuery. Letzteres setzt obwohl es JavaScript stark vereinfacht doch hier und da detailliertere JavaScript-Kenntnisse voraus (der ideale Einstieg hierfür ist immer noch der O'Reilly JavaScript Definitive Guide und online die JavaScript-W3School).

Für das Backend, das für die Komponente Daten heranschafft, kommt nochmal die eine oder andere Technologie hinzu. Hier ist die Wahl aber frei, solange das Framework jqGrid mit JSON oder XML-Daten befeuern kann. Das Format kann relativ weiträumig angepasst werden: jqGrid offeriert Default-XML/JSON-Formate, erlaubt aber die Konfiguration seines XML-Readers, falls man das Quellformat nicht anpassen kann. Einschränkung dabei: jqGrid kann derzeit nur XML-Tags, nicht aber XML-Attribute als Datenquelle heranziehen.

Hat man ein erstes jqGrid-Skript vor sich, ist oft nicht ganz klar, welches Feature aus welchem Paket kommt. Ich bin wirklich froh Firebug als Firefox-Extension mit an Bord zu haben, sonst würde ich wohl heute noch nicht verstehen wie das Ganze zusammengreift.

Was wirklich hilft bei der optischen Gestaltung des Grids ist, dass diese mittels JQuery UI Themeroller erfolgen kann. Im Projekt hat unsere Designerin hiermit relativ schnell ein passendes Theme erstellen können, das mit meiner Grid-Software-Demo auch sofort reibungslos zusammengespielt hat.

Fallstricke bei jqGrid: Das eine oder andere JQuery Plugin muss hinzugefügt werden, damit alle Features funktionieren. Will man beispielsweise mit einem komfortablen Editor Tabellenspalten des Grids sortieren oder filtern, wird die Multiselect Komponente nötig. Achtung dabei: Von dieser gibt es mehrere Quellcode-Varianten im Internet, die nicht alle mit jqGrid zusammenspielen. Der richtige Ort für die Komponente ist Github, das ich so als Social Coding Dienst auch mal kennenlernen durfte.

Fazit: jqGrid ist eine sehr starke Client-Tabellenkomponente für Webanwendungen, man darf die Einarbeitungszeit allerdings nicht unterschätzen. Grob 2-3 Tage sind nötig bis man damit produktiv ist. Danach hat man aber auch JQuery und JQuery UI deutlich besser im Griff. Die Dokumentation ist noch etwas schwach, wäre diese besser, wäre auch sicher der Einstieg reibungsloser. Auch sollte man beachten, dass Javascript recht viel Last auf den Clientbrowser legt. Manchmal ist es sicher sinnvoller seine Tabellen im Backend aufzubauen und via reinem HTML in den Browser zu bringen. Für ein solches Szenario hat sich bei mir Displaytag sehr bewährt.

JSON oder XML?

Derzeit habe ich in einem Kunden-Projekt das erste mal die Chance, mir die JavaScript Framworks JQuery, JQuery UI sowie die Gridkomponente jqGrid etwas näher anzuschauen. Im Zusammenhang mit letzterem muss ich von einem Backend Listen mit Produktdaten abholen, die auf dem Host im XML-Format vorliegen.

Weil jqGrid nicht zu 100% an das bestehende XML-Format anzupassen ist (es kann beispielsweise keine Attribute als Zellinhalten nutzen) bin ich gezwungen, das XML-Dokument umzuwandeln. Diese Aufgabe erledige ich mit einem kleinen Servlet, das auch gleich die Aufteilung der Daten in Seiten vornimmt.

Da ich das XML ohnehin umschreiben muss dachte ich ich werfe auch mal einen Blick auf JSON als Austauschformat. Meine Kollegen gaben mir den Tipp dass es einfacher zu generieren sei und deutlich kompakter ist. Und tatsächlich: Das Format ist eindeutig schlanker. Es könnte damit für AJAX-Aufgaben mein neues Protokoll der Wahl werden.