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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

Interface Builder это хорошая идея, но Bret Victor, в своем докладе «Inventing on Principle» и его эссе «Learnable Programming,» косвенно бросает вызов Apple, чтобы построить еще лучше IDE.

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