Серьезные основания, почему не использовать файлы XIB?
Есть ли какие-либо серьезные основания, почему я не должен использовать XIB / файлы NIB с очень специализированным UI и обширными анимациями и супер низкими потребностями объема потребляемой памяти?
Как новичок я запустил с XIB. Затем я выяснил, что не мог сделать примерно всего в них. Это начало становиться действительно твердым настроить вещи путем, я хотел, чтобы они были. Таким образом в конце, я выбросил весь свой XIBs и сделал все это программно.
Таким образом, когда кто-то спрашивает меня, если XIB хорош, я обычно говорю: Да, если Вы хотите сделать дрянные скучные интерфейсы и не заботитесь слишком много о производительности, идете вперед. Но что еще могло быть причиной не использовать XIB?
Действительно ли я - единственный разработчик iPhone, который предпочитает делать, все программно для этого рассуждает?
4 ответа
Я думаю, что Interface Builder является одним из самых больших преимуществ разработки программного обеспечения для Mac (и, соответственно, iPhone). Графические интерфейсы визуальны; почему не создавать их с помощью визуального интерфейса? IB достаточно гибок, чтобы вы могли создать интерфейс, используя его "общие" компоненты, а затем подклассифицировать их там, где это необходимо. Конечно, если у вас уникальный интерфейс, вам придется подклассифицировать класс представления и выполнить пользовательское рисование, но вы также можете создать интерфейс в IB, а затем легко использовать инспектор для переключения класса на ваш пользовательский подкласс.
Честно говоря, я думаю, что это спектр удобства. Если вам удобно писать все в коде, то дерзайте. Если вы хорошо спроектируете свой проект, то потребуется примерно такой же объем работы по созданию новых окон и т. Д. Но я знаю, что многим людям не так комфортно работать с миром графического интерфейса, поэтому nib / xibs там хорошо работают.
Честно говоря, я довольно часто использую XIB в качестве основы и редактирую их с помощью кода, чтобы получить желаемый вид. Личное предпочтение.
В некоторых случаях может быть сложно настроить представления после загрузки из xib. Когда у вас есть конфликтующие настройки между IB и кодом, которые могут быть неприятными для устранения неполадок.
Вот вопрос к списку. Каково снижение производительности при использовании xib? Я думал, что они были плюсом, потому что они не загружаются в память, пока они вам не понадобятся. Тем не менее, это время загрузки больше, что замедлит вашу программу. Мысли?
Одна вещь, которую я нашел в коде лучше, - это соединения событий в элементах управления: когда вы ищете способы использования метода (сообщения), вы находите их, если они закодированы, и не находите их, если они были установлены в IB.
С другой стороны, размещение объектов на виде намного проще в IB, где вы можете видеть их размер и положение. Когда вы делаете это в коде, вам нужно угадать настройки размера и происхождения, а затем запустить его и внести коррективы, а затем запустить его снова, чтобы увидеть, как он выглядит.
Я экономлю кучу времени при работе с UIControllers (UITabBarControllers, UINavigationControllers и т.д.) на этапе запуска, когда подключается вся навигация.
Я просто создаю X viewControllers с сопутствующим XIB, бросаю в IB необходимые вещи, ярлыки, изображения и т.д. Это означает, что практически для любого приложения вы можете создать пробную версию за несколько часов. Этого достаточно, чтобы потратить некоторое время на изучение тонкостей IB. Особенно на iPhone, где у вас может быть тонна хороших идей пользовательского интерфейса, но все они проваливаются, когда переходят из симулятора на реальное устройство.
Самое лучшее, на мой взгляд, это сбалансировать это, если вы обнаружите, что используете много времени, делая "изменить кадр 3 px -> скомпилировать -> ах... нужно еще два пикселя -> изменить 2 px - скомпилировать -> ах... еще 1 px" для чего-то, что может быть сделано в IB, вы начнете серьезно терять время.
Я начинаю, как описано выше, но потом я часто выбрасываю XIBы для пользовательских вещей. Фокус в том, чтобы не тратить часы на реализацию версий пользовательских вещей в коде снова и снова, а понять, как это должно быть, и сделать пользовательскую вещь один раз:)
.