Auto Layout и UIScrollView. Как его готовить?

[nIx0iD]

Можно было не удалять единственный ViewController, все равно потом добавили такой же.
А так — вполне себе нормальное Howto.

[iago]

UI верстается прямо в сториборде — дальше можно не читать. В любом проекте с >= 10 вьюх UI нужно выносить в ксибы, а сториборды оставлять только как карту навигации.

Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.

[storoj]

Можете подробнее прокомментировать момент про сториборды как карта навигации? Как я себе представил, по-вашему сториборд будет состоять из пустых контроллеров с проставленными классами и segues между собой, а вьюхи находятся в ксибах и грузятся например в loadView. Но неужели такая карта пустых контроллеров помогает ориентироваться в навигации? Мне кажется нет.

[iago]

— не надо грузить в loadView, если в сториборде в контроллере удалить вьюшку — она будет грузиться автоматом из ксиба с тем же именем, что и класс контроллера. Это описано в доках Эппла. Просто контроллер создаешь сразу с ксибом, и никаких проблем.
— ксибы целесообразнее использовать по ряду причин:
1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.

[storoj]

Ну получается, что сториборд остается только ради segues, которые все равно приходится руками вызывать? Это я к тому, что в таком виде смысл использования сториборда стремится к нулю, вам так не кажется?

[iago]

Ну да, не особо полезная штука. Хотя, все же, когда у нас за 40 контроллеров, проще въехать что откуда растет из сториборда.

[Agent_Smith]

Если навигация более-менее линейная, то да. Но если возможны кучи разных переходов, как на старом лого хабры, то ну его в топку этот шториборд!

[iago]

Согласен. В общем, так себе инструмент, старые-добрые ксибы никто не отменял, и лучше чем кодом писать переходы ничего нет. Segue сами по себе тоже не такая уж крутая штука.

[egormerkushev]

Хорошие советы. Спасибо, что поделились.

[YGeorge]

Добавлю еще:
5) если вы пилите проект хотя бы вдвоем, то после того как одновременно поправите интерфейс разных вьюх, но находищихся в одном сториборде, непременно будет конфликт, смержить который потом очень непросто. С ксибками же работать удобнее — это физически разные файлы.

[mibori]

Я тоже не очень люблю сторибоарды (может я их просто готовить не умею?).
Как там, например, реюзать один UITableViewCell для разных контроллеров?

[iago]

Ответил комментатору выше, его вопрос включает ваш.

[GigabyteTheOne]

Никто вас не заставляет делать всё в сторибордах, в данной статье они использовались потому что:
а) Всего одна вьюха, поэтому без разницы
б) По-умолчанию в проект добавляется сториборд, поэтому так было проще

Вообще это дело вкуса, что использовать. Для разного функционала можно использовать разные подходы.
На эту тему есть отличная статья: www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code

[iago]

Во-первых не дело вкуса, а дело задачи. В вашей же статье человек пишет, что ни в коем случае нельзя использовать сториборды на больших проектах (т.е. верстать UI в сторибордах) — о том и я пишу.

А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.

[GigabyteTheOne]

Да где же вы здесь увидели большой проект? Этот проект маленький, и в данном случае сториборд был оправдан.
Даже маленький Hello world будет полезен хоть кому-нибудь, а с вашей позиции лучше вообще никаких статей не писать.

[gooddy]

Читаем и никаких больше недопониманий и магии developer.apple.com/LIBRARY/ios/technotes/tn2154/_index.html

[AddAloner]

В iOS-разработке я не совсем новичок, но Auto Layout пользуюсь редко, особенно для ScrollView, и в предложенном примере возник только один вопрос, для чего делается этот шаг:

Выделяем наши основные View (те, которые непосредственно находятся внутри ScrollView) и выставляем им центрирование по горизонтали

P.S. Первый шаг с удалением/добавлением вьюконтроллеров я бы все-таки заменил на Editor -> Embed in -> Navigation Controller, меньше лишних действий

[GigabyteTheOne]

Спасибо, поправил пункт с NavigationConroller'ом.
Auto Layout со ScrollView очень удобно использовать для экрана с деталями какого-нибудь объекта (информация о городе, описание магазина) или для экрана с настройками, если обычный TableView уже не очень удобен.
К тому же, получается очень наглядная вёрстка, в отличие от TableVIew.

[yberdnikov]

все ето нормально пока не начинаешь баловаться с поддержкой rotation

[bezumkin]

Спасибо! Топик помог разобраться, почему не появлялся скролл.