Хорошие причины, почему бы не использовать файлы XIB?

Question

Существуют ли веские причины, по которым мне не следует использовать файлы XIB / NIB с сильно настроенным пользовательским интерфейсом, обширной анимацией и сверхнизкими потребностями в памяти?

Как начинающий, я начал с XIB. Тогда я понял, что не могу делать почти все в них. Стало очень трудно настраивать вещи так, как я хотел. В итоге я выбросил все свои XIB и сделал все программно.

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

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

Answer 1

Я думаю, что Interface Builder является одним из крупнейших активов разработки программного обеспечения для Mac (и, соответственно, iPhone). GUI визуальные; почему не создать их с помощью визуального интерфейса? IB достаточно гибок, чтобы вы могли расположить интерфейс, используя его «общие» компоненты, а затем разделить их на подклассы, где это необходимо. Конечно, если у вас есть уникальный интерфейс, вам нужно будет создать подкласс класса представления и выполнить пользовательское рисование, но вы также можете выложить свой интерфейс в IB, а затем легко использовать инспектор для переключения класса на свой собственный подкласс. 1003 *

Answer 2

Честно говоря, я думаю, что это спектр удобства. Если вам удобно писать все в коде, тогда сделайте это. Если вы хорошо спроектируете свой проект, то для создания новых окон и т. П. Вам потребуется примерно столько же работы. Но я знаю, что многим людям не очень нравится мир GUI, поэтому nib / xibs хорошо там работают.

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

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

Вот вопрос к списку. Какое влияние на производительность оказывает использование XIB? Я думал, что они были плюсом, потому что они не загружаются в память, пока они вам не понадобятся. Тем не менее, это время загрузки больше, что замедлит вашу программу. Мысли?

Answer 3

Когда ваше приложение имеет какие-то «стандартные» представления, используйте XIB. Если вам нужна реальная настройка, в зависимости от внешнего контента (XML ...) сделайте это программно.

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

Answer 4

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

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

Answer 5

XML-содержимое nib-файла очень сложно. Это делает чрезвычайно трудным просмотр изменений или исправление конфликтов слияния с системой контроля версий, такой как Git.

Интерфейсный конструктор - хорошая идея, но Брет Виктор в своем выступлении " Изобретая по принципу " и его эссе " Изучаемое программирование " косвенно бросает вызов Apple создаст еще лучшую IDE.

Одна идея, основанная на принципе Брета Виктора: что если бы я мог выбрать «Инструмент перемещения» в приложении iOS Simulator, который позволил бы мне переместить кнопку в моем приложении, а затем в реализации изменился код кадра (.m) файл? Это было бы намного лучше.

Answer 6

Я экономлю массу времени при работе с UIControllers (UITabBarControllers, UINavigationControllers и т. Д.) На этапе запуска, когда все элементы навигации подключены.

Я просто создаю X viewControllers с сопровождающим XIB, добавляю необходимые материалы для IB, метки, изображения и т. Д. Это означает, что практически для любого приложения вы можете получить подтверждение концепции в течение нескольких часов. Этого достаточно, чтобы оправдать тратить некоторое время на изучение тонкостей IB. Особенно на iPhone, где у вас может быть масса хороших идей пользовательского интерфейса, но все они терпят неудачу при переходе от симулятора к реальному устройству.

Лучшее, на мой взгляд, это сбалансировать, если вы тратите много времени на "изменить кадр 3 px -> compile -> ahh .. нужны еще два пикселя -> change 2 px - compile -> ahh .. еще 1 px "для того, что можно сделать в IB, вы серьезно начнете тратить время.

Я начинаю как выше, но потом я часто выбрасываю XIB для нестандартных вещей. Хитрость заключается в том, чтобы не тратить часы на реализацию версий пользовательских вещей в коде снова и снова, а выяснить, как это должно быть, и делать пользовательские вещи один раз:)