gSOAP, Xcode und Linker Probleme die zweite

Ich habe noch mal ein wenig mit den verschiedenen Optionen von gSOAP herumgespielt und dabei folgendes festgestellt: die Probleme die ich beim Linken des Projektes hatte haben scheinbar nichts mit gSOAP zu tun!
Interessanterweise tritt das Problem immer dann auf, wenn man dem Projekt zuerst die von gSOAP erzeugten Dateien, und dann die gsoap Library hinzufügt!
Macht man es umgekehrt, also erst die Libarary hinzufügen und dann die Stub Files, dann compiliert und linkt das Projekt ohne Probleme.
Eine Erklärung konnte ich für dieses Verhalten bislang nicht finden.
|

gSoap, XCode und Cocoa

Da meine Versuche, funktionierende Stubs mit WSMakeStubs zu erzeugen, fehlgeschlagen sind, habe ich mich entschlossen es mit gSOAP zu versuchen.
Also hab ich gSOAP heruntergeladen, mit ./configure -prefix=/installdir - make - make install gSOAP compiliert und installiert.
Mit "wsdl2h -o NameDerHeaderDatei.h http://url_zur_wesdldatei.wsdl" und "soapcpp2 NameDerHeaderDatei.h" hab ich die Stub Files erzeugt und anschließend die erzeugten Dateien + stdsoap2.h und stdsoap2.cpp zu meinem Xcode Projekt hinzugefügt.
Leider hat direkt der erste Versuch das Projekt zum compilieren und zu linken fehlgeschlagen.
Der Linker hat die Meldung

"_namespaces", referenced from:
_namespaces$non_lazy_ptr in stdsoap2.o
symbol(s) not found"


ausgeworfen. Intensive Recherchen bei Google haben mich leider nicht weitergebracht.

Pasted Graphic 1

Was letztendlich geholfen hat, war gSOAP erneut, mit dem Flag "--disable-namespaces" zu compilieren:

/configure --prefix=/installdir --disable-namespaces
make
make install

Die anschließend neu erzeugten Stub Files hab ich erneut in mein Projekt importiert, dann noch die Library libsoap++.a eingebunden (einfach mit der Maus vom Finder in die Dateiliste im XCode ziehen).
Leider gab es immer noch Probleme beim Linken des Projektes. Die Ursache war diesmal jedoch, dass die importierten Quellcodes nicht alle compiliert wurden. Ich hab sie dann von Hand zum Target hinzugefügt (wieder per Drag&Drop in den Abschnitt "Compile Sources"):

Pasted Graphic

Jetzt endlich kann das Projekt erfolgreich compiliert und gelinkt werden. Auch die Verwendung der erzeugten Klassen aus den Stub Files funktioniert ohne Probleme.
|

Objective-C und C++ Code mischen

Ich bin immer noch dabei eine Möglichkeit zu finden, erfolgreich einen Aufruf des Webservices auszuführen. Da meine Versuche mit den von WSMakeStubs erzeugten Stubs keinen Erfolg gebracht haben, habe ich mir nun vorgenommen mit Hilfe von gSOAP C++ Stubs zu erzeugen die ich dann in meiner Cocoa Anwendung verwende.
Dazu habe ich heute erst mal geprüft inwiefern sich Objective-C und C++ - Code miteinander kombinieren lässt. Das erste Ergebnis ist erfreulich positiv!
Die C++ Klasse konnte ich direkt im Projekt anlegen. Um diese aus meiner Objective-C Klasse aus instanzieren zu können, hat es ausgereicht die Objective-C Datei mit der Endung ".mm" statt ".m" zu versehen.
In diesem Fall wird der Objective-C++ Compiler verwendet, der eine gemeinsame Verwendung von Objective-C und C++ zulässt.
In den Projekteinstellungen lässt sich bei den Build Einstellungen allerdings auch generell die verwendete Sprache einstellen:
Pasted Graphic

Ich finde die Standardeinstellungen "According to File Type" für meinen Fall passend.
Der gemischte Code kann dann z.B. so aussehen:

CPPTestClass *cpctc = new CPPTestClass(); // Instanz von C++ Klasse erzeugen
[
textfield setIntValue: cpctc->getValue()]; // Objective-C Nachricht mit Ergebnis von C++-Methodenaufruf als Parameter
delete cpctc; // C++ Objekt löschen

Mein nächster Schritt wird jetzt sein die von gSOAP erstellten Klassen in mein Projekt zu importieren und den Webservice Aufruf darüber auszuführen.
|

SOAP Client mit Cocoa

Aus irgendwelchen Gründen bin ich auf die Schnaps-Idee gekommen, gleich bei einem meiner ersten Testprojekte einen Webservice Aufruf starten zu wollen. Apple liefert mit Xcode ein kleines Tool mit dem Namen 'WSMakeStubs' aus, welches anhand einer WSDL Datei Stub Files für verschiedene Programmiersprachen erzeugt.
Die erzeugten Stub Files hab ich dann per Drag & Drop in Xcode importiert. Soweit war das auch alles kein Problem.
Der Aufruf der Webservice Methode sollte mit Hilfe dieses Code Schnipsels eigentlich kein Problem darstellen:


SoapTestWithLogin *stat = [[SoapTestWithLoginLogin alloc] init];
[stat
setParameters: [NSNumber numberWithLong:100] in_username:@"felix" in_password:@"******"];
NSDictionary *dict = [stat getResultDictionary];

Leider lieferte mit der Aufruf nur folgende Fehlermeldung des Servers (übrigens J2EE):

No WSDL:Port has been found for the SOAP operation {http://anonuri/} ...

Nach längere Recherchen und Vergleichen hab ich dann festgestellt, dass beim HTTP Request folgender Header mitgeschickt wird: Soapaction: SOAPACTION.
Das macht nicht nur wenig Sinn, sondern ist auch falsch. Ich hab mir die von WSMakeStubs erzeugten Stub Files näher angesehen und dabei einen Fehler in der Datei WSGeneratedObj.m gefunden.
Die lokale Variable 'soapAction' überdeckt hier den Parameter mit dem gleichen Namen. Durch einfaches umbenennen der Variablen konnte der Soapaction Header korrigiert werden.
Der neue Codeabschnitt sieht jezt so aus:


NSString
* soapActionHeader = @"SOAPAction";
NSDictionary* headers = [self copyHeaderDictionary:1 extraVals:&soapAction extraKeys:&soapActionHeader];
WSMethodInvocationSetProperty(ref, kWSHTTPExtraHeaders, headers);
[headers
release];

Allerdings funktioniert der Soap Request immer noch nicht. Jetzt beschwert sich der Server über ein unbekanntes Element im XML Code.
Ich werde mich jetzt wohl oder übel direkt mit den Core Services befassen müssen da mich die erzeugten Stub Files nicht weiterbringen.
Allerdings bin ich schon etwas enttäuscht dass dieses Tool ganz offensichtliche Fehler enthält die auch bei Apple längst jemand bemerkt haben dürfte.
Eine Alternative zum Erzeugen von Cocoa Stub Files habe ich übrigens nicht finden können. Ich wäre da für jeden Tipp sehr dankbar.
Einen ganz interessanten Artikel zum Thema Core Web Services habe ich bei
macdevcenter gefunden.
|

Ich vermisse Strg+1 :-(

Meine Lieblingstastenkombination in Eclipse ist Strg+1 ! Genau sowas würde ich mir für Xcode auch wünschen, konnte es aber bislang einfach nicht finden.
Besonders die Möglichkeit darüber automatisch das Ergebnis einer Nachricht (Java: Funktionsaufruf) einer neuen Variablen zuzuweisen fehlt mir etwas.
Falls hier irgend jemand eine ähnliche Zaubertastenkombination in Xcode kennt möge sich doch bitte bei mir melden.
|

Blockweise einrücken in Xcode

Von Eclipse bin ich es gewohnt dass man mit der Tabulator Taste gleich mehrere Zeilen auf einmal einrücken kann.
In Xcode hingegen wird der markierte Text durch ein Tabulator Zeichen ersetzt. Nicht gerade das was ich mir wünsche...
Wenn man etwas in den Optionen von Xcode sucht, findet man die Möglichkeit die Key Bindings zu ändern. Hier musste ich dann auch feststellen dass es bereits eine Tastenkombination dafür gibt, die jedoch eher für amerikanische Tastaturen geeignet ist.
Ich hab es mir auf Ctrl-Alt-rechts bzw. Ctrl-Alt-links geändert. Das ist war nicht ganz so fein wie die Eclipse Variante, ist für mich aber trotzdem brauchbar.
|

Bücher für Ein- und Umsteiger

Die letzten Tage habe ich vor allem damit verbracht Bücher zum Thema Xcode und Cocoa zu lesen.
Dabei hat mir eines ganz besonders zugesagt:
Cocoa Programming For Mac OS X von Aaron Hillegass.
Das Buch ist gut strukturiert und lässt an den entscheidenden Stellen kaum Fragen offen. Außerdem konzentriert es sich sehr auf die Cocoa Programmierung, in anderen Büchern wurde hingegen gerne auch mal für zahlreiche Seiten zum Thema C oder zu allgemeinen Unix-Themen gewechselt.
Eine neue Version dieses Buches scheint in Vorbereitung zu sein, hoffentlich mit vielen neuen Tiger- und Leopard-Themen und für Xcode 3 angepasste Beispielen.

Ein Buch von dem ich ziemlich enttäuscht bin ist
"Objective-C und Cocoa : Programmieren unter Mac OS X -- für Einsteiger und Experten (berücksichtigt Tiger und Xcode 2.0 )" von Klaus M. Rodewig.
Die Erklärungen sind oft unlogisch und wenig nachvollziehbar. Außerdem haben sich zahlreiche Fehler eingeschlichen und es wird meiner Meinung nach viel zu viel Platz für allgemeine C und Unix-Themen verschwendet. Mehr Cocoa Details und dafür weniger allgemeine Unix Themen hätten dem Buch ziemlich gut getan.
Ich werde auf dieses Buch in den nächsten Tagen noch mal etwas genauer eingehen.

|

Von Kaffee zu Kakao - von Eclipse/Java zu Xcode/Objective-C

Seit etwas mehr als einem Jahr bin ich begeisterter Mac-Anwender. Nun bin ich dabei in die Cocoa Entwicklung einzusteigen um eigene Programme für meinen Mac und mein iPhone zu schreiben. Da ich mich bereits beruflich den ganzen Tag mit der Entwicklung von Software beschäftige, sind für mich vor allem der Umstieg von Eclipse zu Xcode, das Framework von Apple und Objective-C neu.
In diesem Blog werde ich daher die Dinge niederschreiben die mir beim Wechseln von Eclipse zu Xcode bzw. beim Wechsel von Java zu Objective-C auf- oder schwergefallen sind.
Einer meiner Entwicklungsschwerpunkte wird sicherlich das iPhone sein. Da sich das SDK von Apple jedoch noch in der Beta Version befindet und die Lizenzbedingungen die Veröffentlichung von Screenshots und Beispielen weitestgehend untersagen (zumindest beurteile ich das so), werden die iPhone spezifischen Einträge anfangs vermutlich eine eher untergeordnete Rolle spielen.
Natürlich würde ich mich über Feedback freuen.

Felix
|