Zaawansowany (ręczny) przykład rzeczywisty

W tym przykładzie użyto biblioteki POP z serwisu Facebook.

W tej sekcji opisano bardziej zaawansowane podejście do powiązania, w którym użyjemy narzędzia firmy Apple xcodebuild do utworzenia projektu POP, a następnie ręcznie wyjmij dane wejściowe dla aplikacji Objective Sharpie. Zasadniczo obejmuje to, co objective Sharpie robi pod maską w poprzedniej sekcji.

 $ git clone https://github.com/facebook/pop.git
Cloning into 'pop'...
   _(more git clone output)_

$ cd pop

Ponieważ biblioteka POP ma projekt Xcode (pop.xcodeproj), możemy po prostu użyć xcodebuild do skompilowania pop. Ten proces może z kolei generować pliki nagłówkowe, które może być konieczne przeanalizowanie przez Objective Sharpie. Dlatego tworzenie przed powiązaniem jest ważne. Podczas kompilowania za pomocą xcodebuild funkcji upewnij się, że przekazujesz ten sam identyfikator i architekturę zestawu SDK, którą zamierzasz przekazać do aplikacji Objective Sharpie (i pamiętaj, że program Objective Sharpie 3.0 zwykle może to zrobić za Ciebie!):

$ 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 **

W konsoli programu będzie wiele danych wyjściowych informacji o kompilacji w ramach programu xcodebuild. Jak pokazano powyżej, widać, że element docelowy "CpHeader" został uruchomiony, gdzie pliki nagłówka zostały skopiowane do katalogu wyjściowego kompilacji. Często dzieje się tak i ułatwia tworzenie powiązań: w ramach kompilacji biblioteki natywnej pliki nagłówkowe są często kopiowane do lokalizacji eksploatacyjnych "publicznie", co ułatwia analizowanie powiązania. W tym przypadku wiemy, że pliki nagłówkowe POP znajdują się w build/Headers katalogu.

Jesteśmy teraz gotowi do powiązania pop. Wiemy, że chcemy skompilować zestaw SDK iphoneos8.1 przy użyciu arm64 architektury i że pliki nagłówkowe, o których nam zależy, znajdują się w build/Headers obszarze wyewidencjonowania git pop. Jeśli przyjrzymy się katalogowi build/Headers , zobaczymy kilka plików nagłówkowych:

$ 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

Jeśli przyjrzymy POP.hsię metodzie , możemy zobaczyć, że jest to główny plik nagłówka najwyższego poziomu biblioteki, który #importjest innym plikiem. Z tego powodu musimy przejść POP.h tylko do Objective Sharpie, a clang wykona resztę za kulisami:

$ 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.

Zauważysz, że przekazaliśmy -scope build/Headers argument objective Sharpie. Ponieważ język C i Objective-C biblioteki muszą #import lub #include inne pliki nagłówkowe, które są szczegółami implementacji biblioteki, a nie interfejsu API, który chcesz powiązać, -scope argument informuje Objective Sharpie o ignorowaniu dowolnego interfejsu API, który nie jest zdefiniowany w pliku gdzieś w -scope katalogu.

-scope Argument jest często opcjonalny dla czystej implementacji bibliotek, jednak nie ma żadnych szkód w jawnym dostarczaniu go.

Napiwek

Jeśli nagłówki biblioteki zaimportują dowolne nagłówki zestawu SDK systemu iOS, np. #import <Foundation.h>, konieczne będzie ustawienie zakresu. W przeciwnym razie funkcja Objective Sharpie wygeneruje definicje powiązań dla zaimportowanego nagłówka zestawu SDK systemu iOS, co spowoduje ogromne powiązanie, które prawdopodobnie spowoduje wygenerowanie błędów podczas kompilowania projektu powiązania.

Ponadto określono parametr -c -Ibuild/headers. Po pierwsze, argument informuje Objective Sharpie, -c aby zatrzymać interpretowanie argumentów wiersza polecenia i przekazać wszelkie kolejne argumenty bezpośrednio do kompilatora clang. -Ibuild/Headers W związku z tym jest argumentem kompilatora clang, który instruuje język clang do wyszukiwania w obszarze build/Headers, który jest miejscem, w którym znajdują się nagłówki POP. Bez tego argumentu clang nie wiedziałby, gdzie zlokalizować pliki, które POP.h się #importznajduje. Prawie wszystkie "problemy" z używaniem Objective Sharpie sprowadzają się do ustalenia, co należy przekazać do clang.

Kończenie powiązania

Funkcja Objective Sharpie została wygenerowana Binding/ApiDefinitions.cs i Binding/StructsAndEnums.cs pliki.

Są to podstawowe pierwsze przekazanie Objective Sharpie w powiązaniu, a w kilku przypadkach może to być wszystko, czego potrzebujesz. Jak wspomniano powyżej, deweloper zazwyczaj musi ręcznie zmodyfikować wygenerowane pliki po zakończeniu objective Sharpie, aby rozwiązać wszelkie problemy , które nie mogą być automatycznie obsługiwane przez narzędzie.

Po zakończeniu aktualizacji te dwa pliki można teraz dodać do projektu powiązania w Visual Studio dla komputerów Mac lub przekazać bezpośrednio do btouch narzędzi lub bmac w celu utworzenia końcowego powiązania.

Aby zapoznać się z dokładnym opisem procesu powiązania, zapoznaj się z naszymi instrukcjami dotyczącymi kompletnego przewodnika.