Automatyczne maskowanie programowo w porównaniu z programem Builder / xib / nib

Miałem (prawdopodobnie fałszywe) założenie, że włączenie wskaźnika prawego marginesu w Xib jest równoznaczne z użyciem UIViewAutoresizingFlexibleLeftMarginkodu wewnętrznego i tak dalej.

Tak więc myślałem zgodnie z tą migawką:

Później dzisiaj musiałem sprawdzić krzyż i natknąłem się na ten wątek .

A także dokumentację Apple, zatytułowaną „Automatyczne przetwarzanie zmian układu za pomocą reguł automatycznej zmiany rozmiaru” w tym linku: https://developer.apple.com/library/content/documentation/WindowsViews/Conceptual/ViewPG_iPhoneOS/CreatingViews/ CreatingViews.html

Tak więc mam teraz w głowie nową koncepcję tego, w jaki sposób programowe ustawienie masek automatycznej zmiany wielkości byłoby równoważne ustawieniom xib:

Scenariusz 1 : Tylko ustawienie (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight)odpowiada:

W XIB?

Scenariusz 2 : Ustawienie (UIViewAutoresizingFlexibleWidth | UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin | UIViewAutoresizingFlexibleBottomMargin)w kodzie odpowiada:

W XIB?

Czy moje 2 odnowione scenariusze są prawidłowe? Czy teraz rozumiem?

Tak, w Konstruktorze interfejsów jest to „odwrócone” w pewnym sensie (lub UIView, w zależności od tego, jak na to patrzysz). Twoje cytowane „scenariusze” są prawidłowe.

Tak, zacytowałeś wszystko poprawnie. Zgadzam się również, że wydaje się to nieco zacofane, dlatego doceniam twój post.

Możesz użyć makra preprocesora, UIViewAutoresizingFlexibleMarginsgdy margines UIView będzie elastyczny we wszystkich kierunkach. Umieszczam to w prekompilowanym pliku nagłówkowym, aby był uwzględniany wszędzie.

#define UIViewAutoresizingFlexibleMargins                 \
              UIViewAutoresizingFlexibleBottomMargin    | \
              UIViewAutoresizingFlexibleLeftMargin      | \
              UIViewAutoresizingFlexibleRightMargin     | \
              UIViewAutoresizingFlexibleTopMargin

Użycie UIViewAutoresizingFlexibleMarginssprawi, że element interfejsu pozostanie wyśrodkowany, ponieważ NIE będzie obejmował żadnej strony. Aby element wzrastał / zmniejszał się wraz z rodzicem, ustaw odpowiednio UIViewAutoresizingFlexibleWidthi UIViewAutoresizingFlexibleHeight.

Lubię używać, UIViewAutoresizingFlexibleMarginsponieważ mogę później odwoływać się do niego w następujący sposób:

myView.autoresizingMask = UIViewAutoresizingFlexibleMargins;

zamiast

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;

Często widzę te marginesy LUB połączone razem w jednym wierszu, jak w powyższym przykładzie. Po prostu trudne do odczytania.

Włączenie pionowej / poziomej strzałki (zwanej sprężyną) wewnątrz pudełka sprawi, że wysokość / szerokość będą elastyczne. Ale włączenie linii zewnętrznej (zwanej rozpórką) spowoduje, że ta strona będzie nieelastyczna / nieelastyczna.

Włączenie zewnętrznej lewej linii (lewa rozpórka) nie jest równoważne z włączeniem UIViewAutoresizingFlexibleRightMargin. Zamiast UIViewAutoresizingFlexibleRightMargin= na razie prawo amortyzatora wyłączona, wyłączone czy włączone prawo amortyzatora.

Na początku jest to dość mylące, ale jeśli przyjrzysz się uważnie, istnieje różnica w sprężynach i rozpórkach. Nie wiem, dlaczego Apple to zrobił, ale dla mnie były przypadki, w których łatwiej było z niego korzystać. A użycie przeciwnych właściwości w kodzie jest jeszcze bardziej mylące.

Swift 4 używa tego

gadBannerView?.autoresizingMask = [.flexibleRightMargin  , .flexibleLeftMargin , .flexibleTopMargin , .flexibleBottomMargin]

Cel C

myView.autoresizingMask = UIViewAutoresizingFlexibleBottomMargin | UIViewAutoresizingFlexibleLeftMargin | UIViewAutoresizingFlexibleRightMargin | UIViewAutoresizingFlexibleTopMargin;