Comments 21
Можно было не удалять единственный ViewController, все равно потом добавили такой же.
А так — вполне себе нормальное Howto.
А так — вполне себе нормальное Howto.
UI верстается прямо в сториборде — дальше можно не читать. В любом проекте с >= 10 вьюх UI нужно выносить в ксибы, а сториборды оставлять только как карту навигации.
Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.
Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.
Можете подробнее прокомментировать момент про сториборды как карта навигации? Как я себе представил, по-вашему сториборд будет состоять из пустых контроллеров с проставленными классами и segues между собой, а вьюхи находятся в ксибах и грузятся например в loadView. Но неужели такая карта пустых контроллеров помогает ориентироваться в навигации? Мне кажется нет.
— не надо грузить в loadView, если в сториборде в контроллере удалить вьюшку — она будет грузиться автоматом из ксиба с тем же именем, что и класс контроллера. Это описано в доках Эппла. Просто контроллер создаешь сразу с ксибом, и никаких проблем.
— ксибы целесообразнее использовать по ряду причин:
1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.
— ксибы целесообразнее использовать по ряду причин:
1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.
Ну получается, что сториборд остается только ради segues, которые все равно приходится руками вызывать? Это я к тому, что в таком виде смысл использования сториборда стремится к нулю, вам так не кажется?
Хорошие советы. Спасибо, что поделились.
Добавлю еще:
5) если вы пилите проект хотя бы вдвоем, то после того как одновременно поправите интерфейс разных вьюх, но находищихся в одном сториборде, непременно будет конфликт, смержить который потом очень непросто. С ксибками же работать удобнее — это физически разные файлы.
5) если вы пилите проект хотя бы вдвоем, то после того как одновременно поправите интерфейс разных вьюх, но находищихся в одном сториборде, непременно будет конфликт, смержить который потом очень непросто. С ксибками же работать удобнее — это физически разные файлы.
UFO just landed and posted this here
Никто вас не заставляет делать всё в сторибордах, в данной статье они использовались потому что:
а) Всего одна вьюха, поэтому без разницы
б) По-умолчанию в проект добавляется сториборд, поэтому так было проще
Вообще это дело вкуса, что использовать. Для разного функционала можно использовать разные подходы.
На эту тему есть отличная статья: www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
а) Всего одна вьюха, поэтому без разницы
б) По-умолчанию в проект добавляется сториборд, поэтому так было проще
Вообще это дело вкуса, что использовать. Для разного функционала можно использовать разные подходы.
На эту тему есть отличная статья: www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code
Во-первых не дело вкуса, а дело задачи. В вашей же статье человек пишет, что ни в коем случае нельзя использовать сториборды на больших проектах (т.е. верстать UI в сторибордах) — о том и я пишу.
А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.
А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.
Читаем и никаких больше недопониманий и магии developer.apple.com/LIBRARY/ios/technotes/tn2154/_index.html
В iOS-разработке я не совсем новичок, но Auto Layout пользуюсь редко, особенно для ScrollView, и в предложенном примере возник только один вопрос, для чего делается этот шаг:
P.S. Первый шаг с удалением/добавлением вьюконтроллеров я бы все-таки заменил на Editor -> Embed in -> Navigation Controller, меньше лишних действий
Выделяем наши основные View (те, которые непосредственно находятся внутри ScrollView) и выставляем им центрирование по горизонтали
P.S. Первый шаг с удалением/добавлением вьюконтроллеров я бы все-таки заменил на Editor -> Embed in -> Navigation Controller, меньше лишних действий
Спасибо, поправил пункт с NavigationConroller'ом.
Auto Layout со ScrollView очень удобно использовать для экрана с деталями какого-нибудь объекта (информация о городе, описание магазина) или для экрана с настройками, если обычный TableView уже не очень удобен.
К тому же, получается очень наглядная вёрстка, в отличие от TableVIew.
Auto Layout со ScrollView очень удобно использовать для экрана с деталями какого-нибудь объекта (информация о городе, описание магазина) или для экрана с настройками, если обычный TableView уже не очень удобен.
К тому же, получается очень наглядная вёрстка, в отличие от TableVIew.
все ето нормально пока не начинаешь баловаться с поддержкой rotation
Спасибо! Топик помог разобраться, почему не появлялся скролл.
Sign up to leave a comment.
Auto Layout и UIScrollView. Как его готовить?