Пользователь
0,0
рейтинг
14 мая 2014 в 11:53

Разработка → Auto Layout и UIScrollView. Как его готовить? из песочницы tutorial


В iOS 6 Apple представили замечательную возможность для вёрстки UI для iOS-приложений — Auto Layout. Но вот что удивительно, до сих пор очень немногие проекты используют эту возможность. А ведь это очень сильный инструмент, если с умом подойти к вёрстке UI, можно сэкономить очень много времени на подстраивании элементов для 3,5” и 4” экранов, портретно-ландшафтном расположении экрана и даже на универсальной вёрстке для iPhone и iPad.

И это всё не считая того, что скоро представят iPhone 6 и никто до сих пор точно не знает, какое там будет разрешение и какой экран. Лучше бы заранее подстраховаться.

В основном, тема Auto Layout довольно простая, и изучить её несложно. Но лично я столкнулся с большой проблемой при расположении элементов в UIScrollView. Я потратил немало времени и нервов на изучение того, как же правильно расположить элементы и указать размер контента для того чтобы ScrollView начал пролистываться.

Хоть и решение довольно простое, но на него не так просто выйти. В данной статье я бы хотел рассказать, как же всё-таки правильно готовить UIScrollView в Auto Layout.



Итак, создадим с нуля наш проект. Открываем XCode и создаём Single View Application. Далее вводим название и прочие настройки. Мы будем всё разбирать на примере приложения для iPhone.



Далее в получившемся проекте открываем файл Main.storyboard, выделяем единственный ViewController и оборачиваем его в NavigationController (например, выбрав в меню Editor — Embed in — Navigation Controller).

Добавляем на ViewController ScrollView. Заодно выставляем у NavigationBar свойство Translucent в выключенное состояние (это делается просто для того чтобы наши элементы не залазили под верхнюю панель).



Так как ScrollView обычно предназначен для того чтобы показывать контент, общая высота которого больше, чем высота экрана, то для этого выставляем нашему ViewController свойство Size в Freeform, а потом в параметрах выставляем нужную нам высоту и ширину (я поставил 320x700).



После этого наконец-то можно набросать нужные нам элементы. Я для примера просто набросаю несколько цветных View.



Вот в общем-то наш небольшой эскиз готов, теперь будем применять Auto Layout.
Для начала выделим ScrollView и выставим ему все отступы по 0, это позволит ему буквально прилипать к краям родительской View, что в свою очередь позволит работать в любых размерах: хоть 3,5”, хоть 4”.



Далее начинаем добавлять интересные нам отступы для наших View. Для всех view нужно добавить отступы сверху, слева и справа, а также указать высоту. При добавлении отступов вы можете заметить, что XCode начнёт ругаться на storyboard и выводить предупреждения “ScrollView- Has ambiguous scrollable content height” и “ScrollView- Has ambiguous scrollable content width”. Пока не обращайте на него внимания и продолжайте добавлять отступы.





Осталось 2 ключевых момента.

1. Добавляем самому нижнему View отступ снизу



2. Выделяем наши основные View (те, которые непосредственно находятся внутри ScrollView) и выставляем им центрирование по горизонтали (Editor — Align — Horisontal Center in Container)



Вот и всё. Наши warning’и пропали, всё отлично привязалось. Можно запускать приложение и наслаждаться работающей прокруткой. Отлично работает как на 3,5”, так и на 4”.

Надеюсь, этот tutorial поможет вам в дальнейшем сэкономить время и нервы.
Константин @GigabyteTheOne
карма
9,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (21)

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

    Ну и пользы от таких туториалов немного. Начинающему после его прочтения некуда пойти (это не цикл статей, нет ни более элементарных, ни менее элементарных вещей), а для опытного разработчика, которого интересуют неочевидные тонкости, здесь информации ноль.
    • +1
      Можете подробнее прокомментировать момент про сториборды как карта навигации? Как я себе представил, по-вашему сториборд будет состоять из пустых контроллеров с проставленными классами и segues между собой, а вьюхи находятся в ксибах и грузятся например в loadView. Но неужели такая карта пустых контроллеров помогает ориентироваться в навигации? Мне кажется нет.
      • +1
        — не надо грузить в loadView, если в сториборде в контроллере удалить вьюшку — она будет грузиться автоматом из ксиба с тем же именем, что и класс контроллера. Это описано в доках Эппла. Просто контроллер создаешь сразу с ксибом, и никаких проблем.
        — ксибы целесообразнее использовать по ряду причин:
        1) И самая главная — одновременная разработка под iPhone и iPad. Если делать все в сториборде, то выйдет так — сделал UI в iPhone_storyboard, проверил, застестил, сделал UI в iPad_storyboard, проверил, застестил. В случае с ксибом одного ксиба на афон и айпад хватит, а если айпадный должен чем-то незначительно отличаться — ксиб можно просто скопировать (попробуйте безглючно и без потери constraint-ов скопировать вьюху из одного сториборда в другой);
        2) В больших и серьезных проектах сториборды со множеством UI-элементов тормозят даже на SSD, я молчу про относительно новые iMac и Macbook pro 2010-2011 гг. с HDD, там вообще тихий ужас.
        3) Карта пустых контроллеров вполне себе помогает ориентироваться в навигации ничуть не хуже, чем карта с элементами. Все равно ксибы не похожи на то, что вы видите после запуска приложения, разве что если вы используете только стандартные контролы.
        4) Ну и наконец, если делать некоторые вьюшки ксибами, их можно переиспользовать просто как вьюшки. Сторибордовый же контроллер намертво прикреплен к своему месту. Особенно это касается табличных и коллекшновых ячеек.
        • +1
          Ну получается, что сториборд остается только ради segues, которые все равно приходится руками вызывать? Это я к тому, что в таком виде смысл использования сториборда стремится к нулю, вам так не кажется?
          • 0
            Ну да, не особо полезная штука. Хотя, все же, когда у нас за 40 контроллеров, проще въехать что откуда растет из сториборда.
            • +2
              Если навигация более-менее линейная, то да. Но если возможны кучи разных переходов, как на старом лого хабры, то ну его в топку этот шториборд!
              • 0
                Согласен. В общем, так себе инструмент, старые-добрые ксибы никто не отменял, и лучше чем кодом писать переходы ничего нет. Segue сами по себе тоже не такая уж крутая штука.
        • +1
          Хорошие советы. Спасибо, что поделились.
        • 0
          Добавлю еще:
          5) если вы пилите проект хотя бы вдвоем, то после того как одновременно поправите интерфейс разных вьюх, но находищихся в одном сториборде, непременно будет конфликт, смержить который потом очень непросто. С ксибками же работать удобнее — это физически разные файлы.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +2
        Я тоже не очень люблю сторибоарды (может я их просто готовить не умею?).
        Как там, например, реюзать один UITableViewCell для разных контроллеров?
      • 0
        Ответил комментатору выше, его вопрос включает ваш.
    • 0
      Никто вас не заставляет делать всё в сторибордах, в данной статье они использовались потому что:
      а) Всего одна вьюха, поэтому без разницы
      б) По-умолчанию в проект добавляется сториборд, поэтому так было проще

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

        А вырывать из контекста и освещать какой-либо Hello world-style элемент разработки, и не писать ничего более — ничтожная польза. Либо пишите нормальный, объемный туториал для новичков в виде цикла статей, либо пишите короткую статью про тонкости для профессионалов.
        • 0
          Да где же вы здесь увидели большой проект? Этот проект маленький, и в данном случае сториборд был оправдан.
          Даже маленький Hello world будет полезен хоть кому-нибудь, а с вашей позиции лучше вообще никаких статей не писать.
  • +1
    Читаем и никаких больше недопониманий и магии developer.apple.com/LIBRARY/ios/technotes/tn2154/_index.html
  • 0
    В iOS-разработке я не совсем новичок, но Auto Layout пользуюсь редко, особенно для ScrollView, и в предложенном примере возник только один вопрос, для чего делается этот шаг:
    Выделяем наши основные View (те, которые непосредственно находятся внутри ScrollView) и выставляем им центрирование по горизонтали

    P.S. Первый шаг с удалением/добавлением вьюконтроллеров я бы все-таки заменил на Editor -> Embed in -> Navigation Controller, меньше лишних действий
    • 0
      Спасибо, поправил пункт с NavigationConroller'ом.
      Auto Layout со ScrollView очень удобно использовать для экрана с деталями какого-нибудь объекта (информация о городе, описание магазина) или для экрана с настройками, если обычный TableView уже не очень удобен.
      К тому же, получается очень наглядная вёрстка, в отличие от TableVIew.
  • 0
    все ето нормально пока не начинаешь баловаться с поддержкой rotation
  • +1
    Спасибо! Топик помог разобраться, почему не появлялся скролл.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.