.xib Code Generation in Xamarin.iOS (Generowanie kodu xib na platformie Xamarin.iOS)

Narzędzie Apple Interface Builder ("IB") może służyć do wizualnego projektowania interfejsów użytkownika. Definicje interfejsu utworzone przez IB są zapisywane w plikach xib . Widżety i inne obiekty w plikach xib mogą mieć "tożsamość klasy", która może być niestandardowym typem zdefiniowanym przez użytkownika. Użycie typów niestandardowych umożliwia dostosowanie zachowania widżetów i pisanie niestandardowych widżetów.

Te klasy użytkowników są zwykle podklasami klas kontrolerów interfejsu użytkownika. Mają gniazda (właściwości) i akcje (zdarzenia), które można połączyć z obiektami interfejsu. W czasie wykonywania jest ładowany interfejs IB. W tym czasie obiekty są tworzone, a gniazda i akcje są połączone z różnymi obiektami interfejsu użytkownika dynamicznie. Podczas definiowania tych klas zarządzanych należy zdefiniować wszystkie akcje i placówki, aby były zgodne z oczekiwanymi przez IB akcjami. Visual Studio dla komputerów Mac używa modelu przypominającego kod CodeBehind w celu uproszczenia kodu. Środowisko Xcode ma podobny Objective-C model. Jednak model i konwencje generowania kodu platformy Xamarin.iOS zostały poprawione tak, aby były bardziej znane deweloperom platformy .NET.

Pliki xib i klasy niestandardowe

Istnieje możliwość zdefiniowania typów niestandardowych w plikach xib oprócz używania istniejących typów z platformy Cocoa Touch. Można również używać typów zdefiniowanych w innych plikach xib lub zdefiniowanych wyłącznie w kodzie C#. Obecnie konstruktor interfejsu nie zna szczegółów typów zdefiniowanych poza bieżącym plikiem xib , więc nie wyświetli ich ani nie pokaże niestandardowych gniazd i akcji. Usunięcie tego ograniczenia jest planowane w przyszłości.

Klasy niestandardowe można zdefiniować w pliku xib za pomocą polecenia "Dodaj podklasę" na karcie "Klasy" konstruktora interfejsu. Klasy te nazywamy klasami "CodeBehind". Jeśli plik .xib zawiera plik odpowiednika ".xib.designer.cs" w projekcie, Visual Studio dla komputerów Mac automatycznie wypełni go definicjami klas częściowych dla wszystkich klas niestandardowych w pliku .xib. Te częściowe klasy nazywamy "klasami projektanta".

Generowanie kodu

Generowanie kodu jest włączane przez obecność {0}pliku .xib.designer.cs dla dowolnego{0} pliku xib z akcją kompilacji Page. Visual Studio dla komputerów Mac generuje klasy częściowe w pliku projektanta dla wszystkich klas użytkowników, które można znaleźć w pliku xib. Visual Studio dla komputerów Mac generuje właściwości dla placówek i metod częściowych akcji.

Plik projektanta jest automatycznie aktualizowany po zmianie pliku xib i Visual Studio dla komputerów Mac odzyska fokus. Wprowadzanie zmian w pliku projektanta nie jest zalecane, ponieważ zmiany zostaną zastąpione przy następnym Visual Studio dla komputerów Mac aktualizacji pliku.

Rejestracje i przestrzenie nazw

Visual Studio dla komputerów Mac generuje klasy projektanta przy użyciu domyślnej przestrzeni nazw projektu dla lokalizacji pliku projektanta. To zachowanie jest zgodne z normalnym generowaniem przestrzeni nazw projektu .NET. Przestrzeń nazw plików projektanta używa domyślnych przestrzeni nazw projektu i ustawień zasad nazewnictwa platformy .NET. Jeśli domyślna przestrzeń nazw projektu ulegnie zmianie, ponownie wygenerowane klasy będą używać nowej przestrzeni nazw. Po rewitalizacji może się okazać, że klasy częściowe nie są już zgodne.

Aby klasa jest odnajdywalna przez Objective-C środowisko uruchomieniowe, Visual Studio dla komputerów Mac stosuje [Register (name)] atrybut do klasy. Mimo że platforma Xamarin.iOS automatycznie rejestruje NSObjectklasy pochodne, używa w pełni kwalifikowanych nazw platformy .NET. Atrybut zastosowany przez Visual Studio dla komputerów Mac zastępuje zachowanie platformy Xamarin.iOS, aby upewnić się, że każda klasa jest zarejestrowana przy użyciu nazwy używanej w pliku xib. Dodaj atrybut ręcznie dla wszystkich klas niestandardowych zdefiniowanych przy użyciu protokołu IB bez używania Visual Studio dla komputerów Mac do generowania plików projektanta. Dzięki temu klasy zarządzane są zgodne z oczekiwaną Objective-C nazwą klas.

Klasy nie mogą być zdefiniowane w więcej niż jednym pliku xib lub będą powodować konflikt.

Części klas innych niż Projektant

Projektant klasy częściowe nie są przeznaczone do użycia zgodnie z oczekiwaniami. Gniazda są prywatne i nie określono żadnej klasy bazowej. Oczekuje się, że każda klasa będzie mieć odpowiadającą część klasy "nienazwaicie" w innym pliku. Plik "non-designer" ustawia klasę bazową, manipuluje wylotami i definiuje konstruktory wymagane do utworzenia wystąpienia klasy z kodu natywnego. Domyślne szablony .xib mają części klasy "non-designer", ale w przypadku innych klas niestandardowych zdefiniowanych w pliku .xib należy ręcznie dodać część inną niż projektant.

To rozdzielenie przy użyciu klas częściowych jest potrzebne do elastyczności. Na przykład wiele klas CodeBehind może podklasować wspólną zarządzaną klasę abstrakcyjną, która podklasuje klasę do podklasy przez IB.

Konwencjonalne jest umieszczenie klas CodeBehind w pliku .xib.cs obok pliku projektanta {0}.xib.designer.cs.{0}

Wygenerowane akcje i punkty sprzedaży

W klasach projektanta częściowego Visual Studio dla komputerów Mac generuje właściwości odpowiadające wszystkim połączonym punktom zdefiniowanym w IB i metodom częściowym odpowiadającym dowolnym połączonym akcjom.

Właściwości wylotu

Projektant klasy zawierają właściwości odpowiadające wszystkim punktom wyjścia zdefiniowanym w klasie niestandardowej. Te właściwości umożliwiają powiązanie z opóźnieniem. Są to szczegóły implementacji mostka Xamarin.iOS do celu języka C. Pomyśl o nich jako równoważne polam prywatnym, które mają być używane tylko z klasy CodeBehind. Ustaw pole jako publiczne, dodając publiczny dostęp do pola w części klasy innej niż projektant.

Jeśli właściwości wylotu są zdefiniowane, aby mieć typ id (odpowiednik NSObject), generator kodu projektanta obecnie określa najsilniejszy możliwy typ na podstawie obiektów podłączonych do tego gniazda, dla wygody. Jednak to zachowanie może nie być obsługiwane w przyszłych wersjach. Zaleca się jawne wpisywanie gniazd podczas definiowania klasy niestandardowej.

Właściwości akcji

Projektant klasy zawierają metody częściowe odpowiadające wszystkim akcjom zdefiniowanym w klasie niestandardowej. Te metody nie mają implementacji. Przeznaczenie metod częściowych jest dwa razy:

1. Jeśli wpiszesz partial treść klasy części klasy innej niż projektant, Visual Studio dla komputerów Mac zaoferuje automatyczne uzupełnianie podpisów wszystkich nieimplimplmentowanych metod częściowych.
2. Podpisy metody częściowej mają zastosowany atrybut, który uwidacznia je na Objective-C świecie, dzięki czemu mogą zostać obsłużone jako odpowiednia akcja.

Możesz zignorować metodę częściową i zaimplementować akcję, stosując atrybut do innej metody. Możesz też pozwolić, aby przejdą do klasy bazowej.

Jeśli zdefiniowano akcje mające typ nadawcy id (odpowiednik NSObject), generator kodu projektanta określa obecnie najsilniejszy możliwy typ na podstawie obiektów połączonych z tą akcją. Jednak to zachowanie może nie być obsługiwane w przyszłych wersjach. Zaleca się jawne wpisywanie akcji podczas definiowania klasy niestandardowej.

Te metody częściowe są tworzone tylko dla języka C#, ponieważ funkcja CodeDOM nie obsługuje metod częściowych. Nie są generowane dla innych języków.

Użycie klas między XIB

Czasami użytkownicy chcą odwoływać się do tej samej klasy z wielu plików xib , na przykład z kontrolerami kart. Możesz jawnie odwołać się do definicji klasy z innego pliku xib lub ponownie zdefiniować tę samą nazwę klasy w drugim pliku xib.

Ten ostatni przypadek może być problematyczny z powodu Visual Studio dla komputerów Mac przetwarzania plików xib indywidualnie. Visual Studio dla komputerów Mac nie można wykryć i scalić zduplikowanych definicji. W przypadku konfliktów można wielokrotnie stosować atrybut Register, gdy ta sama klasa częściowa jest zdefiniowana w wielu plikach projektanta. Najnowsze wersje Visual Studio dla komputerów Mac próbują rozwiązać konflikty, ale nie zawsze działają zgodnie z oczekiwaniami. W przyszłości to zachowanie może nie być obsługiwane, a zamiast tego Visual Studio dla komputerów Mac spowoduje, że wszystkie typy zdefiniowane we wszystkich plikach xib i kodzie zarządzanym w projekcie będą widoczne bezpośrednio ze wszystkich plików xib.

Rozdzielczość typu

Typy używane w IB to Objective-C nazwy typów mapowane na typy CLR przy użyciu atrybutów Rejestru. Podczas generowania kodu Visual Studio dla komputerów Mac rozpozna typy CLR, w pełni kwalifikując nazwy typów do Objective-C typów. Te Objective-C typy są opakowane przez rdzeń Xamarin.iOS.

Generator kodu nie może obecnie rozpoznawać typów CLR z Objective-C nazw typów w kodzie użytkownika lub bibliotekach. W takich przypadkach zwraca on dosłowną nazwę typu. Musi mieć taką samą nazwę jak Objective-C typ, aby prawidłowo rozpoznać typ CLR. Typ CLR musi znajdować się w tej samej przestrzeni nazw co używany kod. Przyszłe wersje generatora kodu będą uwzględniać wszystkie Objective-C typy w projekcie.