Udostępnij za pośrednictwem

NSString w środowiskach Xamarin.iOS i Xamarin.Mac

  • Artykuł

Projekt zarówno platform Xamarin.iOS, jak i Xamarin.Mac wywołuje interfejs API do uwidocznienia natywnego typu ciągu .NET, stringw celu manipulowania ciągami w języku C# i innych językach programowania platformy .NET oraz uwidacznia ciąg jako typ danych uwidoczniony przez interfejs API zamiast NSString typu danych.

Oznacza to, że deweloperzy nie powinni przechowywać ciągów, które mają być używane do wywoływania interfejsu API Xamarin.iOS i Xamarin.Mac (Unified) w specjalnym typie (Foundation.NSString), mogą nadal używać interfejsów Mono System.String dla wszystkich operacji, a za każdym razem, gdy interfejs API na platformie Xamarin.iOS lub Xamarin.Mac wymaga ciągu, nasze powiązanie interfejsu API zajmuje się kierowaniem informacji.

Na przykład Objective-C właściwość "text" typu UILabelNSStringjest zadeklarowana następująco:

@property(nonatomic, copy) NSString *text

Jest to widoczne w środowisku Xamarin.iOS jako:

class UILabel {
    public string Text { get; set; }
}

W tle implementacja tej właściwości marshaluje ciąg języka C# do elementu NSString i wywołuje objc_msgSend metodę w taki sam sposób, jak Objective-C w ten sam sposób.

Istnieje kilka interfejsów API innych firmObjective-C, które nie korzystają z NSStringelementu , ale zamiast tego używają ciągu języka C (znak). W takich przypadkach nadal można użyć typu danych ciągu języka C#, ale należy użyć atrybutu [PlainString] w celu poinformowania generatora powiązań, że ten ciąg nie powinien być marshaled jako NSString, ale zamiast tego jako ciąg języka C.

Wyjątki od reguły

W obu środowiskach Xamarin.iOS i Xamarin.Mac wprowadziliśmy wyjątek od tej reguły. Decyzja między tym, kiedy ujawniamy strings, a kiedy dokonujemy wyjątku i uwidaczniamy NSString, jest podjęta, jeśli NSString metoda może wykonywać porównanie wskaźników zamiast porównania zawartości.

Może się tak zdarzyć, gdy Objective-C interfejsy API używają stałej publicznej NSString jako tokenu reprezentującego jakąś akcję, zamiast porównywać rzeczywistą zawartość ciągu.

W takich przypadkach NSString interfejsy API są uwidocznione i istnieje mniejszość interfejsów API, które to mają. Zauważysz również, że właściwości NSString są widoczne w niektórych klasach. Te NSString właściwości są widoczne dla elementów, takich jak powiadomienia. Są to właściwości, które zwykle wyglądają następująco:

class Foo {
     public NSString FooNotification { get; }
}

Powiadomienia są kluczami używanymi dla NSNotification klasy, gdy chcesz zarejestrować określone zdarzenie emitowane przez środowisko uruchomieniowe.

Klucze zwykle wyglądają mniej więcej tak:

class Foo {
     public NSString FooBarKey { get; }
}

Innym miejscem, w którym NSStringobiekty są uwidocznione w interfejsie API, jest tokeny, które są używane jako parametry dla niektórych interfejsów API w systemie iOS lub OS X, które przyjmują NSDictionary obiekty jako parametry. Słownik zazwyczaj zawiera NSString klucze. Xamarin.iOS zgodnie z konwencją nazywa te właściwości statyczne NSString , dodając nazwę "Klucz".