2015-04-18 23 views
8

Czy XCode 6.3/Swift 1.2 dodał dodatkowe marginesy do widoku zawartości UITableViewCell? Przed aktualizacją miałem niestandardowy interfejs UIView, który rozszerzał się na cały ekran w komórkach. Przykład:XCode 6.3 dodawanie marginesów do tableviewcell

enter image description here

Teraz wszystko w komórce wydaje się mieć dodatkowe marże, że nie mam pojęcia, skąd one pochodzą.

enter image description here

Należy zauważyć, że szerokość Te widzenia nie są w żaden sposób zmienione w kodzie i prawej i lewej stronie są ograniczone jak niżej:

enter image description here

Należy również pamiętać, że używam tableView.separatorStyle = .None. Dodam ten fakt, ponieważ z jakiegoś powodu w jednym z moich tableView s, który ma domyślny separator, nie wydaje się, aby dodać te dodatkowe marginesy.

Czy ktoś wie, czy zrobił jakieś dziwne zmiany w XCode 6.3? Takie zachowanie wystąpiło bezpośrednio po aktualizacji.

Edit: enter image description here

+0

Uruchomiłem tę aplikację na iOS 8 przed aktualizacją i wyglądało to jak pierwszy zrzut ekranu. – ad121

+0

Nie wiem, co jeszcze mogę dodać. Właśnie przetestowałem to z ograniczeniami -16 na każdej stronie i to poprawnie rozszerza się przez ekran, ale jestem nieświadomy, dlaczego moje marże byłyby zepchnięte (nie chcę użyć bandaid poprawki bez znającej przyczyny w ten sposób) . Wydrukowałem szerokość contentView, view, tableView i samą komórkę i wszystkie są 375 na iphone 6, ale niebieski blok ma szerokość 359 z ograniczeniami podanymi w pytaniu. – ad121

+0

Ale dlaczego w ogóle ograniczyłeś ograniczenia? Ustaw je na rzeczywistych krawędziach widoku treści, a zmiany w marży nie będą miały wpływu na Ciebie. Zdaję sobie sprawę, że nie jest to odpowiedź na podstawowe pytanie, ale zakładając, że marginesy będą wynosić 8, a ustawienie ograniczeń do -8, aby to zrekompensować, było dość szalone na początek. – matt

Odpowiedz

19

przyjrzeć się dokładnie w tym zrzucie ekranu inspektora rozmiar dla wiodących ograniczeń:

enter image description here

zobaczyć, jak "W stosunku do marginesu" jest zaznaczone? To Twój problem. Jeśli margines się zmieni, zmieni się twoja lewa krawędź. Odznacz tę pozycję menu, a następnie zmień stałą na zero. Zrób to także dla ograniczenia końcowego, a twoje problemy się skończą.

Zajrzyjmy teraz do głębszego problemu: co się zmieniło? Masz absolutną rację, coś się stało. Uważam, że naprawili błąd i zostałeś złapany w naprawę. Rejestrowanie pokazuje mi, że komórka preservesSuperviewLayoutMargins jest true, a marginesy tabeli wynoszą 0,16,0,16. Dzieje się tak nawet w systemie iOS 8.2, więc efektywne marginesy w systemie iOS 8.2 powinny być równe. Jednak były to 8, tak jakby preservesSuperviewLayoutMargins były false. Ale w iOS 8.3 to ustawienie jest właściwie przestrzegane - z rezultatem, który zaobserwowałeś.

Zatem inny sposobem rozwiązania problemu byłoby zostawić swoje ograniczenia, ponieważ są one, ale ustawić każda komórka na preservesSuperviewLayoutMargins do false w cellForRowAtIndexPath:. Działa to równie dobrze, aby wynik był identyczny w obu systemach.

EDIT Dobra wiadomość: wygląda na to, zmiana ta powróciła w iOS 9. Zatem, bez zmian, twoje komórki będzie wyglądać tak samo w iOS 9 tak jak w iOS 8.2 i wcześniej.

+0

Edytowane w celu wyjaśnienia podstawowego zjawiska: masz absolutną rację, marginesy się zmieniły! Dziękuję bardzo za wskazanie tego. – matt

+0

.. to było imponujące debugowanie! Musiał przejrzeć wszystkie ograniczenia mojej komórki widoku tabeli. Naprawiono je wszystkie. Dziękuję Ci. – nmdias

+0

Naprawdę złapali Cię nowe ograniczenia oparte na marginesie Apple. Kiedy utworzysz wiązanie początkowo za pomocą przeciągania kontrolnego, będzie ono oparte na marginesie - bez przytrzymywania klawisza Option_, aby uzyskać wariant bez marginesów. W związku z tym ograniczenia oparte na marginesie są technologią opt-out; możesz zrezygnować, ale większość ludzi nie będzie tego wiedziała i ostatecznie użyje ich, nawet nie zdając sobie z tego sprawy. – matt