Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 70
IB не нужен.
Сначала все весело-приятно, а потом внезапно пытаешься сделать шаг в сторону и начинаешь проклинать тот день, когда связался с этой шарманкой. Автолейауты можно было бы сделать по-человечески и из кода. Но не делают :(
Сначала все весело-приятно, а потом внезапно пытаешься сделать шаг в сторону и начинаешь проклинать тот день, когда связался с этой шарманкой. Автолейауты можно было бы сделать по-человечески и из кода. Но не делают :(
Я тоже всегда так считал и считаю, но бывает множество факторов, когда приходится использовать ИБ. Например:
— проект уже год велся с ИБ, переписывать все с нуля не дают;
— все те же автолэйауты, которые по задумке чудо как хороши;
— Эппл промоутит IB, и значит каждый день рождаются сотни программистов, которые используют IB. Хорошо если вы пишете свой проект, но придя в команду где используют IB, приходится использовать IB.
— проект уже год велся с ИБ, переписывать все с нуля не дают;
— все те же автолэйауты, которые по задумке чудо как хороши;
— Эппл промоутит IB, и значит каждый день рождаются сотни программистов, которые используют IB. Хорошо если вы пишете свой проект, но придя в команду где используют IB, приходится использовать IB.
И мне кажется, что еще очень не скоро сделают вменяемый визуальный редактор интерфейса для iOS. Достаточно посмотреть на успехи Microsoft на этом поприще. Они свой xaml оттачивают уже с десяток лет, и все равно, его использование периодически напоминает адскую пытку, особенно, когда хочется запилить всякие финтифлюшки с анимациями или переопределением сложных контролов. Вместо одного рабочего языка ты вынужден учить два — сам язык + язык разметки. Тот кто думает, что это удобно, просто вряд ли с этим серьезно работал.
Понятно, что эта идеология идет из веба. Но в вебе она вынужденная + несет определенные плюшки. Там это продукт стандартизации html. Но в мобильных и десктопных платформах от использования дополнительного языка для разметки мы не получаем никаких плюшек, так как нет единого стандарта. Замечания типа «зато любой дурак может верстать и не знать код» все равно разбиваются о суровую реальность. Не может. В итоге одни минусы и ровно один плюс — можно привлекать начинающих разработчиков тем, что формочки клепаются визуально.
Понятно, что эта идеология идет из веба. Но в вебе она вынужденная + несет определенные плюшки. Там это продукт стандартизации html. Но в мобильных и десктопных платформах от использования дополнительного языка для разметки мы не получаем никаких плюшек, так как нет единого стандарта. Замечания типа «зато любой дурак может верстать и не знать код» все равно разбиваются о суровую реальность. Не может. В итоге одни минусы и ровно один плюс — можно привлекать начинающих разработчиков тем, что формочки клепаются визуально.
Microsoft не показатель, в 1998 году с выходом Visual C++ 6.0 — сравните визуальный редактор Visual C++ 6.0 и Borland C++ Builder любой версии. Разница была просто колоссальна, а рынок и технологии — примерно одни и те же.
Сказануть такое мог только человек, учивший XAML по третесортным туториалам «как быстро сделать x на WPF». Достаточно прочесть нормально структурированную специализированную книгу, и вопросов не останется — там все очень логично и довольно просто.
Если в систему А добавить компонент Б, то система АБ никак не может быть проще, чем А и Б по-отдельности. Поэтому вводить Б — дурь.
Можно было ничуть не хуже статическое объвление интерфейсов поддержать на уровне одного языка. Вон, у Xamarin есть JSON-подобный язык разметки для Monotoch.Dialog на основе C#. Работать с этим на порядок удобнее, чтобы ввести кастомное поведение или представление в контрол мне не нужно изгалаться на десяток файлов. Просто наследуешь и все. Что мешало MS сделать то же самое?
Можно было ничуть не хуже статическое объвление интерфейсов поддержать на уровне одного языка. Вон, у Xamarin есть JSON-подобный язык разметки для Monotoch.Dialog на основе C#. Работать с этим на порядок удобнее, чтобы ввести кастомное поведение или представление в контрол мне не нужно изгалаться на десяток файлов. Просто наследуешь и все. Что мешало MS сделать то же самое?
Вы счастливчик, каких немного.
Меня тоже припишите сюда.
Не имел никаких проблем с IB — только с Autolayout (тут приходится пользоваться своим, менее приятным решением)
Не имел никаких проблем с IB — только с Autolayout (тут приходится пользоваться своим, менее приятным решением)
Так никаких или с autolayout'ом все же были? :)
Что еще раздражает, так это то, что Interface Builder при открытии файла зачем-то его меняет. Системы контроля версий (особенно, те, которые лочат файлы, типа P4) дуреют с этого. Точнее, системы контроля версий все контролируют, а дуреют программисты…
Что еще раздражает, так это то, что Interface Builder при открытии файла зачем-то его меняет. Системы контроля версий (особенно, те, которые лочат файлы, типа P4) дуреют с этого. Точнее, системы контроля версий все контролируют, а дуреют программисты…
Autolayout не использую в принципе — это ужасный геморрой тянущийся сутками. Нервы свои стоит жалеть.
Думал, в Xcode 5 допилили, ан нет — все тот же ужас.
Коротко: проблемы были только с Autolayout, пока им пользовался.
А еще в Xcode 5 у меня полностью отвалилась история версий (git) во всех проектах — не знаю, что делать.
Недавно начал пользоваться eclipse, пожалел, что там нельзя вести разработку с IB и симулятором :(
Думал, в Xcode 5 допилили, ан нет — все тот же ужас.
Коротко: проблемы были только с Autolayout, пока им пользовался.
А еще в Xcode 5 у меня полностью отвалилась история версий (git) во всех проектах — не знаю, что делать.
Недавно начал пользоваться eclipse, пожалел, что там нельзя вести разработку с IB и симулятором :(
я тоже xib-ы использую, помоему хорошо так уменьшают объем кода, огорчает отсутствие стилей, если надо поменять шрифт, то надо менять его во всех xib-ах руками
Меня в этот же список запишите. Много лет пользую IB — и ксибы и сториборды. Работаю с разной сложностью интерфейсами, все ок. Autolayout не использую :)
«Еще один не выдержал — слабак!» :)
Самая пичаль это то, что генерит этот билдер (НЕХ), на андроиде design view используется только как превьюха, т.к. драгндроп работает еще говеннее, чем билдер. Но все прекрасно правится ручками с авто-подстановкой, авто-форматиронием и авто-сделайчтобыбыловсехорошо.
«Сотрудники компании эппл» решили, что негоже разработчикам трогать руками «сырой» xml и сделали ад и страдания. :) Впрочем, со временем я даже кое-что все таки там правил, смену контроллера и прочие плюшки прям из хмл/
Самая пичаль это то, что генерит этот билдер (НЕХ), на андроиде design view используется только как превьюха, т.к. драгндроп работает еще говеннее, чем билдер. Но все прекрасно правится ручками с авто-подстановкой, авто-форматиронием и авто-сделайчтобыбыловсехорошо.
«Сотрудники компании эппл» решили, что негоже разработчикам трогать руками «сырой» xml и сделали ад и страдания. :) Впрочем, со временем я даже кое-что все таки там правил, смену контроллера и прочие плюшки прям из хмл/
Еще немного раздражает такая мелочь — когда выбираешь в сториборде другую вьюху, список ее компонентов приходится «выбирать из длиннющего списка» всех контроллеров. Можно ведь было сделать подскролл.
Ох, как же я не люблю этот IB… и автор прав насчет автолэйаутов — это такой гемморой, если делать в коде с примесями IB.
>> дайте масштаб хотя бы 200%! Если на вьюхе много маленьких элементов, можно сойти с ума тыкая мышкой в микроскопические вьюшечки, выбирать из длиннющего списка — тоже задача не из быстроприятных;
Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
>> визуально можно задать далеко не все свойства вьюх, хорошо если 30%.
Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
>> Stretching(я даже не знаю, что это такое)
Я тоже. Но может тогда оно нам не надо?)
>> Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;
Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
>> Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!
XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
>> После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;
Тут согласен. Надо фиксить.
>> Когда пытаешься портануть на айпад приложение, которое индус или соотечественник, увлеченный индийской культурой разрабатывал исключительно в сториборде, плачешь кровавыми слезами.
А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
>> визуально можно задать далеко не все свойства вьюх, хорошо если 30%.
Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
>> Stretching(я даже не знаю, что это такое)
Я тоже. Но может тогда оно нам не надо?)
>> Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;
Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
>> Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!
XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
>> После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;
Тут согласен. Надо фиксить.
>> Когда пытаешься портануть на айпад приложение, которое индус или соотечественник, увлеченный индийской культурой разрабатывал исключительно в сториборде, плачешь кровавыми слезами.
А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
>> Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
>> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
Да, могу, список их не вместится на ваш монитор.
>> Я тоже. Но может тогда оно нам не надо?)
Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
>> Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
>> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
>> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
Скопировал ячейки, порастягивал и потратил на это час.
это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
>> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
Да, могу, список их не вместится на ваш монитор.
>> Я тоже. Но может тогда оно нам не надо?)
Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
>> Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
>> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
>> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
Скопировал ячейки, порастягивал и потратил на это час.
>> Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
в фотошопе автоселект слоя по клику, тут тоже кликнул и выбрал нужный. Зачем 200%? Вы там вьхи 2х2 двигаете по экрану?
>> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
Да, могу, список их не вместится на ваш монитор.
Ого! Я думаю вы недооцениваете мой монитор. Ну давайте хотя бы 10.
>> Я тоже. Но может тогда оно нам не надо?)
Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
Может кому-то надо? Где Вы кстати нашли его? Что то не могу найти.
>>Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
Есть метод делегата — (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section; который должен вернуть UIView из которой потом будет создан таблицей UITableViewHeaderFooterView.
>> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
Я думаю внимательность тут решающий фактор. Вообще я только конфликты в ней решал. В основном IB хватает.
>> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
Скопировал ячейки, порастягивал и потратил на это час.
А как должно быть? Волшебная кнопка «Сгенерировать UI для iPad»?
это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
в фотошопе автоселект слоя по клику, тут тоже кликнул и выбрал нужный. Зачем 200%? Вы там вьхи 2х2 двигаете по экрану?
>> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
Да, могу, список их не вместится на ваш монитор.
Ого! Я думаю вы недооцениваете мой монитор. Ну давайте хотя бы 10.
>> Я тоже. Но может тогда оно нам не надо?)
Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
Может кому-то надо? Где Вы кстати нашли его? Что то не могу найти.
>>Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
Есть метод делегата — (UIView *)tableView:(UITableView *)tableView viewForHeaderInSection:(NSInteger)section; который должен вернуть UIView из которой потом будет создан таблицей UITableViewHeaderFooterView.
>> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
Я думаю внимательность тут решающий фактор. Вообще я только конфликты в ней решал. В основном IB хватает.
>> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
Скопировал ячейки, порастягивал и потратил на это час.
А как должно быть? Волшебная кнопка «Сгенерировать UI для iPad»?
Глупо спорить с тем, что Xcode — угребище, а Interface Builder и того хуже. Альтернатива первому есть, а вот последнему — увы. То, что вы сейчас затеяли очень похоже на спор ради спора.
Не надо так.
Не надо так.
Для пропертей можно юзать «User-defined Runtime Attributes», там даже не property, а keyPath. Другое дело, что этот вариант очень не очевидный, можно несколько дней угробить, разбираясь откуда эти значения берутся. Но вариант.
Сталкивался с IB, только когда писал первое приложение.
Сейчас приложения используют настолько «нестандартный» интерфейс, что связываться с IB нет смысла вообще
Сейчас приложения используют настолько «нестандартный» интерфейс, что связываться с IB нет смысла вообще
В свете того, что сейчас происходит, у меня более скромные пожелания: «Apple, пожалуйста, не сломай то, что работает!»
С недавних пор перелез на Masonry для конструирования autolayout'а из кода. Визуально количество кода уменьшилось раза в три.
Тот код из поста переписывается в
Нервов при написании constraint'ов поубавилось. Оно далеко неидеально, но действительно стоит того, чтобы попробовать.
Тот код из поста переписывается в
[self makeConstraints:^(MASConstraintMaker *make) {
make.width.equalTo(@0);
make.height.equalTo(@0);
make.top.equalTo(@0);
make.leading.equalTo(@0);
}];Нервов при написании constraint'ов поубавилось. Оно далеко неидеально, но действительно стоит того, чтобы попробовать.
там появилось волшебная кнопка add another constrains в Xcode 5. Сорвала продолжительную овацию на WWDC %)
Ну да, я ж про нее писал :) если б не она, пришлось бы на картах гадать, куда xCode поставит констрэйнт
у вас глас вопиющего в пустыне. я сразу понял что тут херня и разделил nibs iphone/ipad а там немного подшаманиваю фреймы в зависимости от. получилось мининимум кода и понятно. эплы с constrains реально дали маху. ОЧЧЕНЬ сложно а они не в курсе что сложно :) потому что думают что совсем легко :)
А когда у вас большой код и вы занимаетесь не только constrains, этот вижуал формат до одного места. это как засунуть в NSDictionary в одном месте volume & key а в другом потом мучительно вспоминать «что я нахрен имел ввиду в этой dictionary» :)
А когда у вас большой код и вы занимаетесь не только constrains, этот вижуал формат до одного места. это как засунуть в NSDictionary в одном месте volume & key а в другом потом мучительно вспоминать «что я нахрен имел ввиду в этой dictionary» :)
Для уменьшения размера кода при работе с констрэинтами можно использовать Visual Format Language.
Правда, если после этого вам по какой-то причине понадобится изменить один из добавленных подобным образом констрэинтов (т.е. его константу, больше там ничего менять нельзя), то искать нужный придется перебором массива constraints.
А так да, работать с автолайаутом в IB не очень удобно. Хорошо, что хоть в XCode 5 этот процесс несколько улучшили, убрав, например, автодобавление недостающих констрэинтов.
Правда, если после этого вам по какой-то причине понадобится изменить один из добавленных подобным образом констрэинтов (т.е. его константу, больше там ничего менять нельзя), то искать нужный придется перебором массива constraints.
А так да, работать с автолайаутом в IB не очень удобно. Хорошо, что хоть в XCode 5 этот процесс несколько улучшили, убрав, например, автодобавление недостающих констрэинтов.
Самый правильный путь — это самый простой.
Да в 4 иксе автолейаут был говнищем. Ждем пока допилят пятый. Писать все в коде все равно не вариант, каждый раз НЕНАВИСТЬ когда сталкиваюсь с таким проектом и таской по рефакторингу или багфиксу оного. Поверьте, то что вы не можете попасть мышкой во вьюшку это ничто, по сравнению с рефакторингом чужого лейаут кода, зачастую похабно написанного.
Да в 4 иксе автолейаут был говнищем. Ждем пока допилят пятый. Писать все в коде все равно не вариант, каждый раз НЕНАВИСТЬ когда сталкиваюсь с таким проектом и таской по рефакторингу или багфиксу оного. Поверьте, то что вы не можете попасть мышкой во вьюшку это ничто, по сравнению с рефакторингом чужого лейаут кода, зачастую похабно написанного.
Меня очень напрягают мерджи сторибордов на ровном месте, да и файлы проектов тоже не подарок. Хочу попытаться написать мерджилку сторибордов и проектов, хотя бы чтобы разруливались ситуации одновременного добавления экранов/файлов разными людьми. Пока мне кажется, что задача вполне решаема. Хабраюзер, нужна ли тебе такая утилита?
Я не использую автоматического выравнивания и счастлив наличием IB.
Что беспокоит меня?
Подскажите, можно ли из *.xib, заведенного под iPhone сделать аналог под iPad простым копированием?
Это действительно беспокоит.
Что беспокоит меня?
Подскажите, можно ли из *.xib, заведенного под iPhone сделать аналог под iPad простым копированием?
Это действительно беспокоит.
Что-то я не понял вопроса. Т.е. вы хотите разные ксибы, но чтобы одинаково вели? Тогда зачем разные ксибы…
Потому что размеры устройств разные. Какая лучшая практика для приложений типа Universal?
В данный момент я делаю так
1) завожу iphone_568.xib, создаю controls, связи;
2) копирую в iphone_480.xib
3) рихтую view под 480
Все. С Ipad.xib это не срабатывает. Приходится все элементы управления и связи тупо дублировать руками
В данный момент я делаю так
1) завожу iphone_568.xib, создаю controls, связи;
2) копирую в iphone_480.xib
3) рихтую view под 480
Все. С Ipad.xib это не срабатывает. Приходится все элементы управления и связи тупо дублировать руками
Проблему с масштабом решал просто — выставлял координаты и размеры вручную. Причем весьма удобно смотреть расстояния до других объектов с зажатым Alt. Так что посмотрел сколько куда пикселей осталось — подвинул, растянул. Макеты получается сверстать пиксель в пиксель. То что на глаз расставил, все равно надо контролировать, чтобы стояло точно на своих местах.
Я ни разу не ios разработчик, но моих фрагментарных знаний как раз хватает, чтобы заявить следующее.
AFAIK через IB можно задать абсолютно все свойства через user defined runtime attributes (key-value coding). И констрейнты все равно в коде трогать приходится если есть анимация позиции или размера.
AFAIK через IB можно задать абсолютно все свойства через user defined runtime attributes (key-value coding). И констрейнты все равно в коде трогать приходится если есть анимация позиции или размера.
> а напарник друга коллеги даже скончался от сердечного приступа.
это шутка, или такое действительно имело место? Как пользователь IB, в реальность такого охотно верю.
это шутка, или такое действительно имело место? Как пользователь IB, в реальность такого охотно верю.
Лолшто? Может не Apple виноват в, простите, кривоватости чьих-то решений и рук?
Поделюсь с вами тайным секретом, только не рассказывайте никому, а то не дай Б-г люди перестанут писать контроллеры по 800 строк с ручным лэйаутом и ручным же созданием статических элементов.
Для решения этой проблемы нужно просто создать xib с UIVIew, накидать на него все что вам нужно, создать класс с таким же названием (опционально) и вывести в этот класс необходимые аутлеты.
После этого в вашей UITableViewCell, в init'е достаточно написать что-то типа
И в случае когда вы внезапно что вам нужен UICollectionViewCell, то вы просто проделываете все описанные действия в init'е CollectionCell.
Более, этот метод, позволяет реюзать одну и ту же вьюху в разных частях вашего UI.
Безусловно это все ужасно, лучше фигачить все руками, да.
Поделюсь с вами тайным секретом, только не рассказывайте никому, а то не дай Б-г люди перестанут писать контроллеры по 800 строк с ручным лэйаутом и ручным же созданием статических элементов.
Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка
Для решения этой проблемы нужно просто создать xib с UIVIew, накидать на него все что вам нужно, создать класс с таким же названием (опционально) и вывести в этот класс необходимые аутлеты.
После этого в вашей UITableViewCell, в init'е достаточно написать что-то типа
NSString *partialIndentifier = NSStringFromClass([AwesomeView class]);
UINib *partialNib = [UINib nibWithNibName:partialIdentifier bundle:nil];
self.awesomeView = [[partialNib instantiateWithOwner:self options:nil] lastObject];
[self addSubview:self.awesomeView];
И в случае когда вы внезапно что вам нужен UICollectionViewCell, то вы просто проделываете все описанные действия в init'е CollectionCell.
Более, этот метод, позволяет реюзать одну и ту же вьюху в разных частях вашего UI.
Безусловно это все ужасно, лучше фигачить все руками, да.
Один хитрый трюк, скорее похожий на хак, вы выучили и обвиняете меня в кривости рук — да, вы большой молодец. Это, безусловно, позволяет вам утверждать что я верстаю 800-строчную простыню.
А где здесь хак? Нормальное стандартное решение.
Меня жутко раздражают вот такие гневные посты с советами от советчиков, «начинающие» разработчики смотрят на такие высказывания и берут их в толк, после чего имеем как раз те самые контроллеры на 800 строк и синглтоны синглтонов завернутые в макрос в макрос в макрос…
Меня жутко раздражают вот такие гневные посты с советами от советчиков, «начинающие» разработчики смотрят на такие высказывания и берут их в толк, после чего имеем как раз те самые контроллеры на 800 строк и синглтоны синглтонов завернутые в макрос в макрос в макрос…
Вся надежда на AppCode :)
Использую UIView-AutoLayout для autolayout'a. Все хорошо, IB не нужен, спасибо)
Просмотрел API, либа вроде неплохая. Но не убирает один косяк — если приходится периодически копаться в чужом коде, поддерживать что-то, все равно придется иметь дело со стандартными средствами. Так что стандартные пути все же предпочтительнее.
Да, использую ее в проектах по «обоюдному согласию». Ее плюс в том, что в отличии от других популярных либ (keep и mansory) она ближе к эппловскому стилю и при этом возможностей выстрелить себе в ногу в ней гораздо меньше. В связке с VFL и пониманием того как все работает внутри либы (а там элементарная категория) autolayout можно и руками после нее писать.
А вообще замечание про чужой код справедливо практически ко всем либам)
А вообще замечание про чужой код справедливо практически ко всем либам)
Ссылки на несколько хелперов для autolayout в комментариях уже есть, вот до кучи альтернативный подход: github.com/ReactiveCocoa/ReactiveCocoaLayout
Не боитесь, что у вас будут сложности с устройством на работу после этого поста?
Шутка :) Стивов Джобсов уже нет.
Никогда не имел проблем с IB, и, скорее, получаю удовольствие от него.
Даже для самого харкордного кастома от заказчика у меня как-то всё просто получается.
Часто сложные интерфейсы разделяю на простые вью
Кода для вью получается не более двух страничек… Или для вью-контроллера — не более, чем трёх страничек.
На вью обычно у меня от двух до четырех аутлетов. Если становится больше, надо подумать, может быть стоит разбить вью на несколько частей?
Если вью-контроллер большой, может быть из него стоит вытащить код в невью-котроллеры (типа GameProgressController, MyNetworkRequestsChainController и т. п.).
Посоветую вам не использовать сторибоарды, если вы не один в команде. Ксибы — хороший способ реюза частей интерфейса и комфортный распределенный девелопмент. Ксибы и сторибоарды можно (а иногда нужно) сочетать.
В общем, делайте всё для своего удобства. Негритянский труд в виде таскания брёвен — это что-то далекое от программирования и мешает творчески подходить к задаче.
Шутка :) Стивов Джобсов уже нет.
Никогда не имел проблем с IB, и, скорее, получаю удовольствие от него.
Даже для самого харкордного кастома от заказчика у меня как-то всё просто получается.
Часто сложные интерфейсы разделяю на простые вью
Кода для вью получается не более двух страничек… Или для вью-контроллера — не более, чем трёх страничек.
На вью обычно у меня от двух до четырех аутлетов. Если становится больше, надо подумать, может быть стоит разбить вью на несколько частей?
Если вью-контроллер большой, может быть из него стоит вытащить код в невью-котроллеры (типа GameProgressController, MyNetworkRequestsChainController и т. п.).
Посоветую вам не использовать сторибоарды, если вы не один в команде. Ксибы — хороший способ реюза частей интерфейса и комфортный распределенный девелопмент. Ксибы и сторибоарды можно (а иногда нужно) сочетать.
В общем, делайте всё для своего удобства. Негритянский труд в виде таскания брёвен — это что-то далекое от программирования и мешает творчески подходить к задаче.
Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы.
В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.
В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.
Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.
И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.
В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.
Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.
И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
>>Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы. В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.
Вопрос, просто, чтобы знать, как там у других художников дела.
А в ваших проектах как много классов, которые можно просто перетянуть курсором мыши в другой проект и они заработали бы?
У меня где-то 50%-70% в зависимости от проекта, включая наследников UIViewController и UIView.
Вопрос, просто, чтобы знать, как там у других художников дела.
А в ваших проектах как много классов, которые можно просто перетянуть курсором мыши в другой проект и они заработали бы?
У меня где-то 50%-70% в зависимости от проекта, включая наследников UIViewController и UIView.
Не, никак не 50-70%%. Кроме чего-то универсального, есть 80% кода, который завязан на конкретное приложение и имеет смысл только в контексте его. Возможно, сказывается долгая продуктовая разработка — когда работал на аутсорсинге, процентов соответственно было больше.
Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
[удалён]
Как интересно, наткнулся на свой пост трехлетней давности, а воз и поныне там. Появились Swift, часы, вот API с нейронными сетями на подходе, а IB как был так и остался, статья актуальна до сих пор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Apple, допили пожалуйста Interface Builder!