3
Есть ли недостатки производительности, недостатки разработки или преимущества при разработке представлений с помощью Interface Builder?Должны ли виды создаваться с использованием NIB или кода на iPhone?
A
ответ
11
Часто вы хотите использовать Interface Builder; Есть несколько причин, почему вы хотели бы сделать это через программные интерфейсы:
- это более общепринятый способ создания пользовательских интерфейсов, благодаря своей простоте и визуальных преимуществ, которые вы не можете достичь так же легко, просто используя код.
- помогает вашим приложениям соответствовать iPhone Human Interface Guidelines, используя маркеры и т. Д., Которые Apple рекомендует разработчикам следить за тем, чтобы поддерживать согласованность и удобство использования приложений iPhone.
Несмотря на это, основная причина, почему программные интерфейсы иногда более благоприятны по сравнению с использованием Interface Builder для элементов интерфейса, которые должны быть созданы несколько раз - например, создание nUIImageView с - на основе переменной, которая не может быть реплицируется в Interface Builder. Программные интерфейсы обеспечивают эту гибкость и, как правило, более эффективны в этом случае.
Обратите внимание, что NIBs/XIB также занимают память, и если все ваши интерфейсы размещены в вашем основном файле NIB, это не только увеличит использование памяти вашим приложением (для ресурсов, которые могут не понадобиться мгновенно в любом случае) но это увеличит время загрузки. Однако, как утверждается, обычным обходным решением этой проблемы является не использование программных интерфейсов, а размещение разных групп элементов интерфейса в разных файлах NIB, размещение сразу необходимых интерфейсов в основном файле NIB, который загружается при запуске приложения , и другие группы элементов интерфейса в других файлах NIB, которые при необходимости загружаются.
Короче говоря, общий способ использования заключается в использовании Interface Builder, за исключением случаев, когда вам нужно создать переменное количество элементов, с которыми невозможно легко справиться в Interface Builder.
0
Из того, что я видел до сих пор, создание представлений с помощью XIB очень просто. Но так как я долгое время не развивался на iPhone, я могу только направить вас к этой статье, которая показывает образец XIB, преобразованный в код Objective-C.
http://arstechnica.com/apple/guides/2009/04/iphone-dev-convert-xib-files-to-objective-c.ars
Interface Builder в любой день! :)
Я уверен, что нет существенных выигрышей в производительности, напрямую кодируя представление.
2
Недостатком является то, что легко пропустить проводку до выхода или действия, и устранение неполадок может быть болезненным. Два позитива - это то, что позиционирование, выравнивание и привязка элементов пользовательского интерфейса намного проще, а элементы перерисовываются при повороте телефона (что является процессом анимации, который вам в противном случае нужно было бы обрабатывать с помощью программных элементов).
2
Говоря для себя, я нашел интерфейс строителя ужасно тупым, когда я пытался научиться разрабатывать для iPhone. Рабочий процесс, который вы должны использовать, по-прежнему не имеет для меня большого смысла. Конструктор интерфейса быстрее подходит для тонких интерфейсных макетов, чем для ручного кодирования.
Недостаток программной генерации графического интерфейса в UIViewControllers заключается в том, что вы размыли разницу между представлениями и контроллерами в шаблоне MVC.Если вы можете сохранить генерация графического интерфейса в методе loadView, вы все равно можете поддерживать приличную границу между кодом, генерируя информацию и код, который отображает информацию.
Вкратце: я предпочитаю генерировать графические интерфейсы, переопределяя loadView в подклассах UIViewController.
-1
Никогда не смотрите на генерацию кода NIB с помощью инструмента. Но посмотрите на записку от Apple.
Примечание: Несмотря на то, что вы можете создать приложение Objective-C без использования файлов nib, делать это очень редко и не рекомендуется. В зависимости от вашего приложения избегание использования файлов nib может включать в себя переопределение большого количества поведения структуры для достижения тех же результатов, которые вы получили бы с помощью файла nib.
1
Почему никто не упомянул о переводе. У нас есть проект в 11 локалях - это даст количество nib * (# locales) - это просто неприемлемо (более сотни перьев для проекта из 10 пользовательских интерфейсов).
Я новичок в разработке iOS, но не с шаблоном MVC, и я не знаю, почему вы не можете сохранить вид отдельно от ViewController и не использовать Interface Builder. Я бы просто создал еще один класс для создания представления и использования его в методе loadView контроллера. В этом классе это действительно не влияет на то, сколько методов я бы использовал, я бы все еще держал границы M-V-C сильными. Звучит это хорошо? (Я еще не настолько опытен с Objc, чтобы быть уверенным :) –