Układanie i sortowanie podwidywań w kontrolerze UIViewController

Mam aplikację z UITabController i każda zakładka jest UINavigationController. Korzeniem jednego z moich UINavigationControllers jest UIViewController.

Wewnątrz widoku kontrolera chcę rozplanować niektóre podwidywacze, ale nie wiem, gdzie i jak je ułożyć w sposób niezależny od rozdzielczości (tzn. nie wartości kodu twardego, takie jak 320px, 480px, 44px itp.).

Gdy widok jest w pełni załadowany i przedstawiony na pionowym iPhonie, jego wysokość wyniesie 367px = 480 - 20 (pasek stanu) - 44 (Pasek nav) - 49 (Karta bar).

Wewnątrz kontrolera widoku, obecnie tworzę wszystkie moje podwinięcia w metodzie viewDidLoad. Wydaje się jednak, że w ramach tej metody obecna wysokość widoku wynosi 460px (self.view.bounds.size.height). Tak więc podczas konfigurowania moich podwidywań nie mogę prawidłowo obliczyć rozmiarów czegokolwiek.

W ramach metody viewWillAppear: widok wie, że ma odpowiedni rozmiar, ale oznaczałoby to ustawianie i obliczanie ramek subview za każdym razem, gdy Widok się pojawi (np. Kontrolery widoku potomnego na stosie nawigacyjnym.

Czy jedynym sposobem, aby to zrobić poprawnie, jest układ w viewWillAppear:?

Próbowałem użyć właściwości autoresizujących (parent ' s autoresizesSubviews & autoresizingMask) ale wydaje się, że w ogóle nie działają!? Czy są one skuteczne tylko wtedy, gdy widok jest ustawiony, a następnie jest zmieniany rozmiar (ręcznie / zmiana orientacji?).

Byłbym wdzięczny, gdyby ktoś dał mi znać, dlaczego autoresizing nie działa, i jak najlepiej układać rzeczy nie hardcoding żadnego rozmiary.

Author: Peter Hosey, 2010-01-10
Source

2 answers

autoresizesSubviews powinien być ustawiony w widoku rodzica, natomiast {[1] } powinien być ustawiony w widoku potomka - to jest błąd, który zrobiłem, więc ty też możesz.

W loadView powinieneś powiększyć swoje podwiki tak, aby pasowały do rozmiaru widoku nadrzędnego, a później, gdy Widok nadrzędny zostanie zmieniony z 460 na 367 pikseli, Twoje podwiki również zostaną zmienione, zgodnie z powyższymi ustawieniami maski.

Jeśli to się nie powiedzie, nie ma nic złego w ustawieniu rozmiaru widoku w viewWillAppear - the wpływ na wydajność robienia tego za każdym razem jest znikomy.

Jeśli nic innego nie działa, zawsze jest layoutSubviews: - tam możesz zrobić ręczny układ, jeśli musisz, jest wywoływany, gdy system uważa, że układ może wymagać zmiany. jest też setNeedsLayout: że czasami powołuję się z viewWillRotate:/viewDidRotate: itd. Ale tak naprawdę to nie powinno być potrzebne, a autoresize powinno być wystarczająco dobre.

EDIT: tak, aby zaimplementować niestandardową logikę układu w layoutSubviews Jak wspomniałem powyżej, trzeba by podklasować UIView.

 33
Author: DenNukem,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-02-11 17:34:06

Możesz wykonać logikę układu wewnątrz viewWillLayoutSubviews UIViewController.

-(void)viewWillLayoutSubviews{
    [super viewWillLayoutSubviews];
    // Your layout logic here
}

DOC: wywołany tuż przed wywołaniem metody layoutsubview kontrolera widoku. Podklasy mogą być wdrażane w razie potrzeby. Wartość domyślna to nop.

 41
Author: aumanets,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-04-30 16:24:19