Разработка iPhone взаимодействует через интерфейс в пере или в коде?
SelectElement("leaveCode", valueToSelect)
function SelectElement(id, valueToSelect)
{
var element = document.getElementById(id);
element.value = valueToSelect;
}
4 ответа
Когда-то я был категорически против использования Interface Builder в моих собственных проектах. Это было связано с рядом факторов. Я впервые начал работать с инструментами Xcode, когда iPhone SDK вернулся в бета-версию (примерно в марте 2008 г.), и так как я этого не сделал, Это произошло из-за предыстории Mac Cocoa, я был несколько незнаком с его использованием. Однако это не было основным фактором в моем первоначальном отказе от разработки IB для iPhone - Interface Builder для разработки iPhone во время первоначальной бета-версии iPhone SDK действительно был отстой, и его было сложно использовать.
Однако история совсем другая. с сегодняшним iPhone SDK. Хотя некоторые досадные ошибки IB все еще существуют, я почти полностью изменил свое отношение к использованию Interface Builder. Я обнаружил, что в большинстве случаев использование Interface Builder в ваших проектах является хорошей идеей. Сейчас это отличный инструмент, и тебе следует воспользоваться им.
Теперь, не надо. Поймите меня неправильно - я все еще твердо придерживаюсь мнения, что вы должны иметь возможность реализовать все, , что вы делаете в Interface Builder, используя только код, и я думаю, что такая возможность бесценна. Не используйте Interface Builder как костыль - в конечном итоге вы только навредите себе (и своей производительности или качеству своих продуктов). Хотя тонкости перетаскивания в IB отлично подходят для 90% того, что вам нужно сделать, когда у вас есть что-то нестандартное для реализации, которое может быть выполнено только в коде, вы либо пожалеете, что следовали, либо будете благодарны за следование этому совету. Мне посчастливилось ненавидеть IB достаточно долго, поэтому я научился делать все только в коде, а затем применил эти знания обратно к IB.
Редактировать:
Чтобы решить проблему отсутствия возможности повторного использования (воспринимаемой или реальной) с помощью NIB против кода ... вы выиграли ' t реализовывать что-то, что, по всей вероятности, предназначено для повторного использования в Interface Builder. На самом деле вы не можете создать собственный элемент управления или представление в IB, поэтому это исключено, и в большинстве случаев вы собираетесь реализовать подкласс контроллера представления, который создан для решения конкретной задачи. Конечно, вы всегда должны стремиться к тому, чтобы ваш код и связанные с ним ресурсы были максимально повторно используемыми. Это может включать в себя конструктивные соображения, чтобы не допустить ненужного дублирования очень похожих подклассов контроллера представления.
Использование компоновщиков освобождает вас от кода, который вам в противном случае пришлось бы поддерживать, и чем меньше вам нужно поддерживать, тем лучше.
Макеты, созданные IB, действительно требуют некоторого обслуживания, но это стандарт инструмент с собственной документацией и собственной онлайн-поддержкой (форумы, списки и т. д.). Если кому-то еще когда-нибудь понадобится вмешаться в ваш код, вы можете фактически гарантировать, что у него есть опыт работы с IB, но не обязательно ваш особый стиль построения макета.
Это зависит от ваших предпочтений.
Я предпочитаю писать это в коде.
- Я могу повторно использовать код.
- Использование XIB / NIB обычно нарушает одно определение (если вы выполняете какие-либо настройки).
- Обслуживание XIB / NIB часто более утомительно и подвержено ошибкам (ODR). Мне очень не нравится поддерживать стили кнопок (пример) для каждой кнопки.
- циклические ссылки более вероятны.
- Экземпляры Code / objects / ib часто менее пригодны для повторного использования / модульны. Хотя я отношусь к тому типу людей, которые избегают объектов пользовательского интерфейса, которые могут делать все.
- Отложенный / неоднозначный порядок инициализации создает довольно пугающее состояние для клиентов, которые никогда не должны предполагать, что объект готов к использованию или полностью инициализирован (если вы не предпочитаете для поддержания этих проверок, что является хорошим способом потратить время).
- Если производительность важна,
Отсутствие надежного структурированного владения, идентификации и инициализации. Я не хочу, чтобы ivars были соединениями IB, потому что это затрудняет использование многих классов за пределами «текущего контекста». Другими словами, это связывает код с ресурсом (чаще, чем в идеале). Поскольку вы не можете определить порядок инициализации или определить инициализаторы или дополнительные аргументы инициализации в IB, вы должны затем сообщить объектам друг о друге, создав циклические зависимости и ссылки.
Sbrocket: или зачем ленивая инициализация (если это на самом деле то, что вы имеете в виду) так страшно, когда относительно легко (или фактически во многих случаях автоматически) обеспечить инициализацию и подключение объекта.
Re: scary t хочет, чтобы ivars были соединениями IB, потому что это затрудняет использование многих классов за пределами «текущего контекста», другими словами, это связывает код с ресурсом (чаще, чем в идеале). Поскольку вы не можете определить порядок инициализации или определить инициализаторы или дополнительные аргументы инициализации в IB, вы должны затем сообщить объектам друг о друге, создавая циклические зависимости и ссылки.
Sbrocket: или зачем ленивая инициализация (при условии, что это действительно то, что вы имеете в виду) так страшно, когда относительно легко (или фактически во многих случаях автоматически) гарантировать, что объект инициализирован и подключен.
Re: scary t хочет, чтобы ivars были IB-соединениями, потому что это затрудняет использование многих классов за пределами «текущего контекста», другими словами, это связывает код с ресурсом (чаще, чем в идеале). Поскольку вы не можете определить порядок инициализации или определить инициализаторы или дополнительные аргументы инициализации в IB, вы должны затем сообщить объектам друг о друге, создавая циклические зависимости и ссылки.
Sbrocket: или зачем ленивая инициализация (при условии, что это действительно то, что вы имеете в виду) так страшно, когда относительно легко (или фактически во многих случаях автоматически) гарантировать, что объект инициализирован и подключен.
Re: scary Я не говорил о ленивой инициализации. Я говорил об отложенном и неоднозначном порядке инициализации.
Инициализация пера является полуупорядоченной. Фактический порядок / процесс могут отличаться, и это не может быть надежно использовано в многоразовых интроспективных программах ... опять же, вы закончите писать слишком много кода, который является хрупким, невозможно повторно использовать, никогда нельзя гарантировать предсказуемое поведение и необходимо всегда проверять состояние (еще одна запись для круговой зависимости). Если это не разовая реализация, зачем беспокоиться об этих сложностях?
Такой подход к программированию хаотичен, и реализации должны (в свою очередь) быть готовы обрабатывать что угодно в любое время. Одно дело - защитить себя от сбоев, но писать в этом контексте защитный код производственного уровня… никак.
Гораздо проще написать согласованную программу, инициализация которой определяет достоверность в контексте, о котором реализации могут знать (если инициализированы), что объект в целом подготовлен к использованию. Сложность частного случая сведена к минимуму. Многие из таких проектов разваливаются по мере увеличения сложности программы, в то время как разработчики библиотек добавляют слои за слоями «защитных мер», просто чтобы не мешать работе - многопоточность - отличный вход для таких хайзенбагов. Излишняя двусмысленность нежелательна в повторно используемом коде производственного уровня; люди не должны перекрестно ссылаться на все особые случаи программы, а сложности, касающиеся определенного поведения и особых случаев, либо распространяются, либо игнорируются (при условии, что они должным образом отслеживаются и документируются, что является более совместными усилиями, чем правильное написание его с самого начала ). Я думаю, мы все можем согласиться с тем, что следует избегать обременительных интерфейсов и реализаций.
Sbrocket: Мне также было бы интересно увидеть некоторые точные цифры, которые показывают, что загрузка NIB медленнее - конечно, поначалу это может показаться логичным думал, но мы всегда такие плохие предсказатели узких мест производительности без какого-либо жесткого тестирования.
Я никогда не говорил (явно), что это было медленнее :)
Хорошо, если серьезно, разархивирование NIB было (для меня) на удивление медленный процесс, хотя наши представления о медленном времени и времени разархивирования могут сильно отличаться.
Пример: у меня было приложение на основе документа, и загрузка пера была в несколько раз медленнее, чем загрузка документа, когда размеры документа в несколько раз превышали размер пера. Перенос реализации в код сделал процесс намного быстрее. Когда это было в коде, и я контролировал порядок инициализации,
Конструктор интерфейсов отлично подходит для определенного уровня сложности. Для более или менее сложных вещей я предпочитаю делать это в коде.
Если у вас есть интерфейс, который не будет использоваться более чем одним способом, имеет несколько, но не много элементов, и не требует сложной компоновки, то IB отлично подойдет.
В конечном итоге я почти никогда не использую IB. Это как характер проектов, над которыми я работаю, так и личные предпочтения. Определенно есть некоторые интерфейсы, за которыми я бы сразу направился в IB, но мне давно не нужно было создавать один из них.