Подтвердить что ты не робот

Плохо ли создавать представления программно?

Итак, я новичок в разработке iOS, и мне было проще писать представления все программно. Таким образом, мои представления имеют UIViews, ScrollViews, UIButton, UILabel, все созданные и позиционированные программно. (Поэтому я никогда не использовал AutoLayouts).

Теперь я почти закончил свое приложение и хочу сделать вид iPad, и понял, что это была плохая идея, чтобы сделать это вот так.

Является ли эта плохая практика или я действительно использую автоматические макеты столько, сколько могу?

Если это нормально, как я это делаю прямо сейчас, каков правильный способ добавления разных представлений для iOS и iPad? Я видел этот ответ ниже о том, как найти устройство, достаточно простого выражения if else? - iOS: как определить текущую модель iPhone/устройства в Swift?

4b9b3361

Ответ 1

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

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

  • Вы строите быстрое приложение для клиента или хобби? Используйте раскадровку с автозагрузкой.
  • Вы строите проект с открытым исходным кодом, который будет использоваться многими людьми? Использовать программный интерфейс
  • Вы строите приложение в долгосрочной перспективе? (1 год) Используйте программный интерфейс

Еще труднее сделать приложение, которое должно быть повернуто без автозапуска. Потому что делать это с помощью кода требует гораздо больше работы, чем автозапуск. Большинство хороших приложений не используют эту функцию в любом случае, поэтому я не вижу большой проблемы.

Хороший совет никогда не использовать константы при написании программного интерфейса.

Если вы собираетесь сделать кнопку шириной 100 пикселей в ширину, не вводите 100px в любом месте кода. Вместо этого выясните размеры экрана и поместите основные виды в соответствии с размерами экрана. Затем поместите подвид или вторичные виды в соответствии с положением основных видов. Если вы сделаете это правильно, у вас будет более мощная поддержка макетирования, чем автозапуск.

Вот небольшая библиотека, которую я написал, пожалуйста, проверьте и сыграйте с кодом о том, как я размещаю представление: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift

Также здесь хорошая статья, мне нравится об этом: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code

Ответ 2

Это прекрасно, если у вас достаточно времени, терпения, хорошего навыка в вычислениях и конфигурациях отношений между различными элементами пользовательского интерфейса.

Однако использование Auto Layout довольно полезно и занимает мало времени, чем ручные вычисления.

Мы можем легко создать динамический и универсальный интерфейс, который с минимальными усилиями отвечает на изменения размера экрана, ориентации устройства и локализации.

Прочтите "Принятие автоматического макета" , чтобы реализовать автоматический макет в существующем приложении

Ответ 3

TL; DR

Это зависит от


Более длинная версия

Очевидно, что один размер не подходит всем. AutoLayout довольно эффективен как в интерфейсе Builder, так и в коде (будь то визуальный языковой формат или простой параметр ограничения), но иногда кажется, что вы "потираете правое ухо левой рукой" - что при добавлении представлений программным образом появляется Но будьте осторожны с тем, чтобы в каждом контроллере представления не было различий - вы не хотите вводить слишком много сложности в свой проект, не так ли?

Мне лично нравится использовать AutoLayout столько, сколько я могу, и всякий раз, когда я больше не могу его использовать, или StoryBoard View слишком перепутается с миллионами ограничений, я пытаюсь разделить виды на контейнеры - измените размер контейнера с помощью AutoLayout и иметь подпрограммы, обрабатываемые кодом.

Пример был бы обычным Media Player - возможно, я хочу иметь две полосы ниже и выше видео - я мог бы иметь видео и две расширенные полосы UIView, обрабатываемые AutoLayout. Но subviews (controls) в самих полосах будут добавлены кодом. Это дает мне контроль над моим кодом, но при этом он не вводит слишком много сложностей.

Ответ 4

Прежде всего - если вы хотите разработать iOS, вам нужно изучить Autolayout. Уже существует множество различных устройств с различными разрешениями и, возможно, будет еще больше в будущем.

Вторичный - если вы хотите эффективно работать с IB, вы должны читать руководство/смотреть обучающие видеоролики и иметь некоторую практику. Это может быть трудно начать, но тогда вы поймете, что IB является мощным, быстрым и часто лучшим способом разработки графического интерфейса. Часто, но не всегда!

Преимущества кода:

  • Простота копирования и вставки GUI. Это может быть важно, если у вас есть несколько похожих взглядов или хотите повторно использовать старый код.
  • Легко разрешать конфликты слияния и проверять фиксации.
  • Легче создавать стили - как один и тот же шрифт для всех этикеток в зависимости от страны.
  • Более мощный (есть вещи, которые нельзя сделать с IB), поэтому вы должны использовать его иногда.

Преимущества IB:

  • Вы можете видеть ваш графический интерфейс во время разработки для разных разрешений/локализации, поэтому вам не нужно компилировать и запускать проект на разных устройствах/симуляторах проверить GUI в порядке или нет. Также IB покажет вам предупреждения, если вы забудете некоторые ограничения Autolayout или возникли конфликты. Экономит много времени, если у вас есть сложный графический интерфейс с нетривиальными ограничениями Autolayout.
  • Намного легче понять код someones else, если он разработан в IB. Особенно важно для сложного GUI - не так легко найти требуемую метку или кнопку в нескольких сотнях строк кода.
  • Небольшой бонус - если вы хотите использовать настраиваемый элемент управления, разработанный с помощью кода, вы можете сделать его IBInspectable и использовать его без проблем в IB

Просто подведем итоги - если вам не нужны преимущества IB (например, GUI довольно прост и не использует Autolayout), разработка графического интерфейса через код может быть проще и быстрее. Но если вам приходится поддерживать разные разрешения и/или у вас есть сотни строк кода GUI в каждом контроллере представления, я настоятельно рекомендую попробовать IB.