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

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

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

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

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

Ответ 1

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

Ответ 2

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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