To pole wyboru jest dostępne w programie Interface Builder (IB), ale tylko w przypadku projektów Cocoa przeznaczonych dla systemu OS X. W przypadku iOS obecnie nie jest dostępny. Możesz ustawić to programowo.
Auto Layout na iOS z mojego zrozumienia - i inni czują się swobodnie rozbić tu - nie jest pełna realizacja tego, co jest dostępne na OS X.
Szczerze mówiąc, biorąc pod uwagę to, co mówisz potem ta opcja jest prawdopodobnie czymś, o co nie musisz się martwić. Myślę, że ważne jest, aby uaktualnić projekty OS X do Auto Layout, ale ogólnie w przypadku iOS jest mało prawdopodobne, że będziesz mieszał jeden z drugim. Oznacza to, że albo zaznaczysz swój Xib w Inspektorze plików, aby "Używał Autolayout", albo nie.
Powiedział, że jest jeden przypadek użycia gdzie może trzeba zadzierać z tą flagą. Dzieje się tak, jeśli chcesz utworzyć samodzielny plik Xib dla widoku, a następnie załaduj go programowo, używając loadNibNamed. W tym czasie domyślnie ograniczenia stylu Auto Resizing są konwertowane na nowe style Auto Layout. Zazwyczaj chcę dodać własne, więc ustawiam tę flagę, aby zap "em.
myView.translatesAutoresizingMaskIntoConstraints = NO
Zresztą to już inna historia.
Oto link, aby uzyskać więcej informacji, chociaż masz bez wątpienia miał zapoznać się już:
Adopting Auto Layout
Jedno chciałbym powiedzieć to, że jeśli masz problemy z Auto Layout w na początku - a nie byłbyś człowiekiem, gdybyś nie był, wszyscy byliśmy - wtedy trzymałbym się z Interface Builderem i myślał o złotych zasadach. Najważniejsze dla mnie jest to, że nienawidzi dwuznaczności. To jest jak próżnia w naturze. Zanim usuniesz ograniczenie , którego nie chcesz,, musisz dodać jedną , którą chcesz, a następnie usunąć starą.
Innym błędem, który popełniłem, było mieszanie automatycznego układu i ramek. Zrobiłbym więc kod, który sprawdziłby szerokość ramki, a następnie zastosował to do ograniczeń. Zły błąd. To naprawdę kończy się łzami. Po przejściu do Auto Layout bardzo ważne jest, aby naprawdę zapomnieć o robieniu czegokolwiek z CGRect, frame itd.
Trzymaj się tego. Zacznij od prostych widoków w IB i eksperymentuj. Jest naprawdę metoda na szaleństwo.
Jeszcze jeden związek też warto przyjrzeć znaczy:
10 Things You Need To Know About Cocoa Autolayout
Wow, dzięki tak dużo Max, w tym szczegółowej i jasnej odpowiedzi. Ciągle nie rozumiem, dlaczego mówisz, że nie potrzebujesz tego podczas konwersji projektu iOS. Po prostu chcę tego, abym mógł przeprowadzić częściową konwersję krok po kroku na AL. Chodzi mi o to, że jeśli go tam nie ma, to nie jest, ale jest to jedna z tych sytuacji, w której zastanawiam się, dlaczego zostałaby wyraźnie pominięta w zestawie dla iOS dev, a jeszcze bardziej do tego, dlaczego inni deweloperzy nie będą narzekać. .to znaczy Zastanawiam się, czy brakuje mi jakiegoś punktu ... – bobsmells
prawdopodobnie dlatego, że w iOS oczekują, że użyjesz AL prawie wyłącznie w IB, najprawdopodobniej używając tablic fabularnych. Ładowanie samodzielnego widoku Program Xibs programowo z loadNibNamed jest prawdopodobnie uważany przez Apple za znacznie mniej powszechny. W jaki sposób jest skonfigurowany twój projekt? Czy masz standardowe kontrolery widoku z powiązanymi widokami, czy używasz loadNibNamed? –
Mam standardowe VC z powiązanymi widokami. Korzystam z komponentu innego producenta (iCarousel-https: //github.com/nicklockwood/iCarousel), co zapewnia ułatwienie tworzenia własnego widoku dla każdego panelu za pomocą podobnej metody do cellForRowAtIndexPath, gdy mamy do czynienia z widokami tabeli. Problem polega na tym, że widok jest zwrócony przeze mnie z tej metody, co oznacza, że nigdy nie dodaję go do jego superwizji, co oznacza, że nie mam szansy na dodanie ograniczeń. Oczywiście mogłem zagłębić się w kod iCarousel i zrobić to w ten sposób, ale na pewno brakuje mi czegoś ... nie powinienem móc używać frameworka jako czarnej skrzynki? – bobsmells