Esempio avanzato (manuale) reale
In questo esempio viene usata la libreria POP di Facebook.
Questa sezione illustra un approccio più avanzato all'associazione, in cui useremo lo strumento di xcodebuild Apple per compilare prima il progetto POP e quindi dedurre manualmente l'input per Objective Sharpie. Ciò riguarda essenzialmente ciò che Objective Sharpie sta facendo sotto il cofano nella sezione precedente.
$ git clone https://github.com/facebook/pop.git
Cloning into 'pop'...
_(more git clone output)_
$ cd pop
Poiché la libreria POP ha un progetto Xcode (pop.xcodeproj), è possibile usare xcodebuild solo per compilare POP. Questo processo può a sua volta generare file di intestazione che Objective Sharpie potrebbe dover analizzare. Ecco perché la compilazione prima dell'associazione è importante. Quando si esegue la compilazione tramite xcodebuild assicurarsi di passare lo stesso identificatore SDK e la stessa architettura che si intende passare a Objective Sharpie (e ricordare, Objective Sharpie 3.0 può in genere farlo per voi!):
$ 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 **
Nella console sarà presente un sacco di output delle informazioni di compilazione come parte di xcodebuild. Come illustrato in precedenza, è possibile notare che è stata eseguita una destinazione "CpHeader" in cui i file di intestazione sono stati copiati in una directory di output di compilazione. Questo è spesso il caso e semplifica l'associazione: come parte della compilazione della libreria nativa, i file di intestazione vengono spesso copiati in un percorso di consumo "pubblicamente" che consente di semplificare l'analisi per l'associazione. In questo caso, sappiamo che i file di intestazione pop si trovano nella build/Headers directory .
È ora possibile associare POP. Sappiamo che si vuole creare per SDK iphoneos8.1 con l'architettura arm64 e che i file di intestazione di cui ci si preoccupa si trovano sotto build/Headers il pop git checkout. Se si esamina la build/Headers directory, verranno visualizzati diversi file di intestazione:
$ 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
Se si esamina POP.h, si può vedere che è il file di intestazione principale della libreria che #importè altri file. Per questo motivo, è sufficiente passare POP.h a Objective Sharpie e clang farà il resto dietro le quinte:
$ 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.
Noterai che abbiamo passato un -scope build/Headers argomento a Objective Sharpie. Poiché le librerie e Objective-C C devono #import o #include altri file di intestazione che sono dettagli di implementazione della libreria e non dell'API da associare, l'argomento -scope indica a Objective Sharpie di ignorare qualsiasi API non definita in un file in una posizione all'interno della -scope directory.
L'argomento -scope è spesso facoltativo per le librerie implementate in modo pulito, ma non c'è alcun danno a fornire in modo esplicito.
Suggerimento
Se le intestazioni della libreria importano intestazioni iOS SDK, ad esempio #import <Foundation.h>, sarà necessario impostare l'ambito; in caso contrario, Objective Sharpie genererà definizioni di associazione per l'intestazione dell'SDK iOS importata, generando un'associazione enorme che genererà probabilmente errori durante la compilazione del progetto di associazione.
Inoltre, è stato specificato -c -Ibuild/headers. In primo luogo, l'argomento indica a Objective Sharpie di interrompere l'interpretazione -c degli argomenti della riga di comando e passare gli argomenti successivi direttamente al compilatore clang. Di conseguenza, -Ibuild/Headers è un argomento del compilatore clang che indica a clang di cercare include in build/Headers, dove si trovano le intestazioni POP. Senza questo argomento, clang non saprebbe dove individuare i file in POP.h #importcorso. Quasi tutti i "problemi" con l'uso di Objective Sharpie si riducono per capire cosa passare a clang.
Completamento dell'associazione
Objective Sharpie ha ora generato Binding/ApiDefinitions.cs file e Binding/StructsAndEnums.cs .
Questi sono il primo passaggio di base di Objective Sharpie all'associazione e in alcuni casi potrebbe essere tutto ciò che serve. Come indicato in precedenza, tuttavia, lo sviluppatore dovrà in genere modificare manualmente i file generati al termine di Objective Sharpie per risolvere eventuali problemi che non possono essere gestiti automaticamente dallo strumento.
Una volta completati gli aggiornamenti, questi due file possono ora essere aggiunti a un progetto di associazione in Visual Studio per Mac o essere passati direttamente agli btouch strumenti o bmac per produrre l'associazione finale.
Per una descrizione completa del processo di associazione, vedere le istruzioni complete per la procedura dettagliata.