Erweitertes (manuelles) Real-World Beispiel
In diesem Beispiel wird die POP-Bibliothek von Facebook verwendet.
In diesem Abschnitt wird ein komplexerer Ansatz für die Bindung behandelt, bei dem wir zuerst das Tool von xcodebuild Apple verwenden, um das POP-Projekt zu erstellen und dann manuell eingaben für Objective Sharpie abzuleiten. Dies deckt im Wesentlichen ab, was Objective Sharpie im vorherigen Abschnitt unter der Haube macht.
$ git clone https://github.com/facebook/pop.git
Cloning into 'pop'...
_(more git clone output)_
$ cd pop
Da die POP-Bibliothek über ein Xcode-Projekt (pop.xcodeproj) verfügt, können wir einfach zum Erstellen von POP verwenden xcodebuild . Dieser Prozess kann wiederum Headerdateien generieren, die Objective Sharpie möglicherweise analysieren muss. Aus diesem Grund ist das Erstellen vor der Bindung wichtig. Stellen Sie beim Erstellen über xcodebuild sicher, dass Sie denselben SDK-Bezeichner und dieselbe Architektur übergeben, die Sie an Objective Sharpie übergeben möchten (und denken Sie daran, dass Objective Sharpie 3.0 dies normalerweise für Sie tun kann!):
$ xcodebuild -sdk iphoneos9.0 -arch arm64
Build settings from command line:
ARCHS = arm64
SDKROOT = iphoneos8.1
=== BUILD TARGET pop OF PROJECT pop WITH THE DEFAULT CONFIGURATION (Release) ===
...
CpHeader pop/POPAnimationTracer.h build/Headers/POP/POPAnimationTracer.h
cd /Users/aaron/src/sharpie/pop
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/Users/aaron/bin::/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/git/bin:/Users/aaron/.rvm/bin"
builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -strip-debug-symbols -strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -resolve-src-symlinks /Users/aaron/src/sharpie/pop/pop/POPAnimationTracer.h /Users/aaron/src/sharpie/pop/build/Headers/POP
...
** BUILD SUCCEEDED **
Es werden viele Buildinformationen in der Konsole als Teil von xcodebuildausgegeben. Wie oben gezeigt, können wir sehen, dass ein "CpHeader"-Ziel ausgeführt wurde, bei dem Headerdateien in ein Buildausgabeverzeichnis kopiert wurden. Dies ist häufig der Fall und erleichtert die Bindung: Als Teil des Builds der nativen Bibliothek werden Headerdateien häufig an einen "öffentlich" nutzbaren Speicherort kopiert, was die Analyse für die Bindung erleichtern kann. In diesem Fall wissen wir, dass sich die Headerdateien von POP im build/Headers Verzeichnis befinden.
Wir sind jetzt bereit, POP zu binden. Wir wissen, dass wir für das SDK iphoneos8.1 mit der arm64 Architektur erstellen möchten und dass sich die Headerdateien, die uns wichtig sind, unter build/Headers der POP-Git-Auscheckung befinden. Wenn wir im build/Headers Verzeichnis nachsehen, werden eine Reihe von Headerdateien angezeigt:
$ ls build/Headers/POP/
POP.h POPAnimationTracer.h POPDefines.h
POPAnimatableProperty.h POPAnimator.h POPGeometry.h
POPAnimation.h POPAnimatorPrivate.h POPLayerExtras.h
POPAnimationEvent.h POPBasicAnimation.h POPPropertyAnimation.h
POPAnimationExtras.h POPCustomAnimation.h POPSpringAnimation.h
POPAnimationPrivate.h POPDecayAnimation.h
Wenn wir uns ansehenPOP.h, sehen wir, dass #importes sich bei der Standard Headerdatei der obersten Ebene um andere Dateien handelt. Aus diesem Grund müssen wir nur an Objective Sharpie übergeben POP.h , und clang übernimmt den Rest im Hintergrund:
$ sharpie bind -output Binding -sdk iphoneos8.1 \
-scope build/Headers build/Headers/POP/POP.h \
-c -Ibuild/Headers -arch arm64
Parsing Native Code...
Binding...
[write] ApiDefinitions.cs
[write] StructsAndEnums.cs
Binding Analysis:
Automated binding is complete, but there are a few APIs which have
been flagged with [Verify] attributes. While the entire binding
should be audited for best API design practices, look more closely
at APIs with the following Verify attribute hints:
ConstantsInterfaceAssociation (1 instance):
There's no fool-proof way to determine with which Objective-C
interface an extern variable declaration may be associated.
Instances of these are bound as [Field] properties in a partial
interface into a near-by concrete interface to produce a more
intuitive API, possibly eliminating the 'Constants' interface
altogether.
StronglyTypedNSArray (4 instances):
A native NSArray* was bound as NSObject[]. It might be possible
to more strongly type the array in the binding based on
expectations set through API documentation (e.g. comments in the
header file) or by examining the array contents through testing.
For example, an NSArray* containing only NSNumber* instances can
be bound as NSNumber[] instead of NSObject[].
MethodToProperty (2 instances):
An Objective-C method was bound as a C# property due to
convention such as taking no parameters and returning a value (
non-void return). Often methods like these should be bound as
properties to surface a nicer API, but sometimes false-positives
can occur and the binding should actually be a method.
Once you have verified a Verify attribute, you should remove it
from the binding source code. The presence of Verify attributes
intentionally cause build failures.
For more information about the Verify attribute hints above,
consult the Objective Sharpie documentation by running 'sharpie
docs' or visiting the following URL:
http://xmn.io/sharpie-docs
Submitting usage data to Xamarin...
Submitted - thank you for helping to improve Objective Sharpie!
Done.
Sie werden feststellen, dass wir ein -scope build/Headers Argument an Objective Sharpie übergeben haben. Da C und Objective-C Bibliotheken #import oder #include andere Headerdateien benötigen, die Implementierungsdetails der Bibliothek und nicht der API sind, die Sie binden möchten, weist das -scope Argument Objective Sharpie an, jede API zu ignorieren, die nicht in einer Datei innerhalb des -scope Verzeichnisses definiert ist.
Sie werden feststellen, dass das -scope Argument für sauber implementierte Bibliotheken häufig optional ist, aber es ist kein Schaden, es explizit bereitzustellen.
Tipp
Wenn die Header der Bibliothek iOS SDK-Header importieren, z. B. #import <Foundation.h>, müssen Sie den Bereich festlegen, andernfalls generiert Objective Sharpie Bindungsdefinitionen für den importierten iOS SDK-Header, was zu einer großen Bindung führt, die wahrscheinlich Fehler beim Kompilieren des Bindungsprojekts verursacht.
Darüber hinaus haben wir angegeben -c -Ibuild/headers. Erstens weist das -c Argument Objective Sharpie an, die Interpretation von Befehlszeilenargumenten zu beenden und alle nachfolgenden Argumente direkt an den clang-Compiler zu übergeben. Daher ist ein clang-Compilerargument, das clang anweist, -Ibuild/Headers nach includes unter build/Headerszu suchen, wo sich die POP-Header befinden. Ohne dieses Argument würde clang nicht wissen, wo die Dateien zu finden sind, die POP.h ing sind #import. Fast alle "Probleme" mit der Verwendung von Objective Sharpie laufen darauf hinaus, herauszufinden, was an clang übergeben werden soll.
Abschließen der Bindung
Objective Sharpie hat jetzt Dateien und Binding/StructsAndEnums.cs generiertBinding/ApiDefinitions.cs.
Dies sind der grundlegende erste Schritt von Objective Sharpie an der Bindung, und in einigen Fällen ist es möglicherweise alles, was Sie benötigen. Wie bereits erwähnt, muss der Entwickler die generierten Dateien jedoch in der Regel manuell ändern, nachdem Objective Sharpie abgeschlossen ist, um Alle Probleme zu beheben , die nicht automatisch vom Tool behandelt werden konnten.
Sobald die Updates abgeschlossen sind, können diese beiden Dateien nun einem Bindungsprojekt in Visual Studio für Mac hinzugefügt oder direkt an die btouch Tools oder bmac übergeben werden, um die endgültige Bindung zu erstellen.
Eine ausführliche Beschreibung des Bindungsprozesses finden Sie in unseren Anweisungen zur vollständigen exemplarischen Vorgehensweise.