Как создать интерфейсы Какао без Интерфейсного Разработчика? - PullRequest
38 голосов
/ 04 апреля 2009

Я бы предпочел создавать свои интерфейсы программно. Похоже, что все документы на Apple Developer предполагают, что вы используете Interface Builder. Можно ли создать эти интерфейсы программно, и если да, то с чего мне начать узнавать, как это сделать

Я думал, что соответствующий документ для этого, если возможно, будет в этом разделе: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html

Ответы [ 5 ]

36 голосов
/ 11 сентября 2009

Мне нравится вопрос, и я также хотел бы узнать о ресурсах для перехода на IB. Полезность («почему») ограничена только воображением. Сверх того, вот несколько возможных причин для явного программирования пользовательских интерфейсов:

  • Реализация лучшего Интерфейсного Разработчика.
  • Программирование динамических пользовательских интерфейсов, т. Е. Тех, чья структура статически недоступна (во время компиляции / кодирования).
  • Реализация серверной части Какао кроссплатформенной библиотеки или языка для пользовательских интерфейсов.

Существует серия постов в блоге о , работающих без кончика и недавнего описания Майкла Мухи о cocoa-dev .

23 голосов
/ 04 апреля 2009

Я бы предпочел создавать свои интерфейсы программно.

Почему? Интерфейсный Разработчик легче и быстрее. Вы не можете написать опечатку перетаскиванием, и вы не получите эти очень удобные руководства по аква, когда вы печатаете прямоугольники вручную.

Не борись с этим. Интерфейсный конструктор - ваш друг. Пусть это поможет вам.

Если вы настаиваете на том, чтобы тратить свое время и силы, написав свой интерфейс в коде:

Не на основе документов (как правило, на основе библиотек, таких как Mail, iTunes, iPhoto): создайте подкласс NSObject, создайте его экземпляр и сделайте его делегатом приложения, а в методе applicationDidFinishLaunching: делегата создайте окно, заполнить его представлениями и заказать его спереди.

На основе документов (например, TextEdit, Preview, QuickTime Player): в методе makeWindowControllers в вашем подклассе NSDocument создайте свои окна (и заполните их представлениями) и создайте для них контроллеры окон, обязательно отправив себя addWindowController: для каждого оконного контроллера.

19 голосов
/ 14 сентября 2010

Как полностью слепой разработчик, я могу сказать, что IB не совместим с VoiceOver (встроенным средством чтения с экрана в OS X).

Это означает, что без доступа к надежной документации по использованию Какао без IB я не могу разрабатывать приложения для OS X / iPhone в Какао, что означает, что я (по иронии судьбы) не могу легко разрабатывать приложения, доступные для слепых (и всех остальных) OS X / iOS.

Мое текущее решение, которое я бы предпочел не использовать, это Java + SWT, конечно, это работает для OS X, а не для iOS.

4 голосов
/ 19 июня 2010

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

IB не принимает пользовательские элементы интерфейса, поэтому более сложные интерфейсы не могут его использовать. И ДА, вы захотите делать более сложные вещи, которые дает вам UIKit.

3 голосов
/ 19 октября 2013

Хотя это немного тихо ... Я много раз пытался делать все только программно. Это сложно, но возможно.

Обновление : Я опубликовал еще один вопрос для этой конкретной проблемы: NSOutlineView на основе представления без NIB? , а теперь Я считаю, что все можно сделать программным способом, но это невероятно сложно без консультации с инженерами Apple из-за отсутствия информации или примеров.


Ниже аргумент может быть не по теме, но я хотел бы отметить, почему я настоятельно предпочитаю программным способом.

Я также предпочитаю программный способ. Поскольку

  • Инструмент статического макета не может обрабатывать что-либо динамическое.
  • Трудно воспроизвести одно и то же состояние пользовательского интерфейса на нескольких NIB. Все скрыто или скрыто. Вам нужно посетить все панели, чтобы найти параметры. В такой работе очень легко ошибиться - ошибка дружелюбна.
  • Управлять согласованным состоянием сложно. Потому что воспроизвести такой же вид сложно.
  • Автоматизация невозможна. Вы не можете создать автоматически сгенерированную форму ввода.
  • Переадресация параметров, таких как переменный размер элемента, выбранный пользователем, невозможна.
  • Нацеливание маленькой точки намного сложнее, чем нажатие клавиш размером с палец в фиксированном месте - забавно, что это серьезная проблема юзабилити для разработчиков!
  • ИБ иногда винты. Это означает, что он компилируется и все еще работает, но когда я открываю исходный код, он выглядит испорченным, и дополнительное редактирование становится невозможным. (возможно, вы этого еще не испытали, но если файл XIB становится сложным, это должно произойти)
  • Это сериализация на основе изображений. Концепция хорошая. Но проблема в том, что image-base only . IB не сохраняет исходный код для чистой загрузки путем воспроизведения исходного кода. Чистая загрузка очень важна, чтобы гарантировать определенное рабочее состояние. Также мы не можем исправить ошибки в исходном коде. Ошибки будут просто складываться бесконечно. Это основная причина, почему мы не можем воспроизвести состояние равно (не похож на) в IB.

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

С помощью текстового кода легко воспроизвести то же состояние - просто скопируйте код. Также легко проверить и исправить неправильную часть - потому что у нас есть полный контроль. Но в IB у нас нет контроля над сложными деталями.

IB не может быть окончательным решением. Это похоже на Photoshop, но даже Photoshop предлагает возможность создания текстовых сценариев. GUI - это движущаяся программа, а не статичное изображение или графика. Подход IB абсолютно неверен даже для визуального редактирования GUI. Если вы один из тех, кто читает Apple, читайте это, прошу полностью удалить зависимость от IB как можно скорее.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...