Apple, допили пожалуйста Interface Builder!

    Этот пост — крик гнева в сторону Apple, и все же во мне осталась надежда. Я являюсь iOS-разработчиком уже 4 года, и то, что поначалу казалось сиюминутным несовершенством, несущественными деталями, с годами превращается в китайскую пытку водой, а ведь мы с вами пользуемся IB каждый день, ну или хотя бы раз в неделю.



    Возможно, Apple и не заслуживает такой критики — правда, все остальное, ну или почти все остальное, у них на высоте. Исключая iTunes и Apple developer portal (который за последние годы, все же, стал значительно лучше) технологии позволяют сосредоточиться на том, что ты делаешь, а не на том, как это будет смотреться в IE.

    Сначала я не использовал IB вовсе, уж таким кривым и убогим он мне казался после других визуальных редакторов. Даже Macromedia Dreamviewer MX, имхо, имел больше шансов называться WYSIWYG-редакторов для UI. Но прошло несколько лет, и появилась замечательная штука — Autolayout — которую катастрофически неудобно имплементить в коде. Мало счастья в таком коде:

    UIImageView *iv = [[UIImageView alloc] initWithImage:image];
        UIView *renderView = [[UIView alloc] initWithFrame:iv.bounds];
        NSInteger completedDistance = renderView.bounds.size.width * percentsCompleted;
        UIView *progressView = [[UIView alloc] initWithFrame:CGRectMake(completedDistance, 0, renderView.bounds.size.width, renderView.bounds.size.height)];
        progressView.backgroundColor = RGB_UICOLOR(255, 255, 255, 0.8);
        renderView.clipsToBounds = YES;
        [renderView addSubview:iv];
        [renderView addSubview:progressView];


    но код вида

    NSMutableArray *constraints = [@[] mutableCopy];
        
        [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                      attribute:NSLayoutAttributeWidth
                                      relatedBy:NSLayoutRelationEqual
                                         toItem:self.parentView
                                      attribute:NSLayoutAttributeWidth
                                     multiplier:1
                                       constant:0]];
       [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                      attribute:NSLayoutAttributeHeight
                                      relatedBy:NSLayoutRelationEqual
                                         toItem:self.parentView
                                      attribute:NSLayoutAttributeHeight
                                     multiplier:1
                                       constant:0]];
        [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                      attribute:NSLayoutAttributeTop
                                      relatedBy:NSLayoutRelationEqual
                                         toItem:self.parentView
                                      attribute:NSLayoutAttributeTop
                                     multiplier:1
                                       constant:0]];
        [constraints addObject:[NSLayoutConstraint constraintWithItem:self
                                     attribute:NSLayoutAttributeLeading
                                     relatedBy:NSLayoutRelationEqual
                                        toItem:self.parentView
                                     attribute:NSLayoutAttributeLeading
                                    multiplier:1
                                      constant:0]];
        
        [self.parentView addConstraints:constraints];


    ввергает душу девелопера в уныние и депрессию. В IB настройка авторазметки (autolayout) по началу тоже на сахар, но с ходом времени приноравливаешься, начинаешь заставлять себя не замечать жутких косяков, терпеть маленькие недостатки пока… у тебя не случается истерика и количество откровенных ляпов, неисправленных годами, не переваливает за все разумные пределы. А ведь альтернативы нет, формат недокументарованный, сторонних инструментов не будет! Вот мой укороченный черненький списочек:

    • дайте масштаб хотя бы 200%! Если на вьюхе много маленьких элементов, можно сойти с ума тыкая мышкой в микроскопические вьюшечки, выбирать из длиннющего списка — тоже задача не из быстроприятных;
    • визуально можно задать далеко не все свойства вьюх, хорошо если 30%. Вспоминается Borland Delphi и его волшебный Object Inspector, в котором можно было создать практически любую вьюху, и выглядела она почти так же, как и в рантайме. В IB вьюхи похожи на говно, точнее на набор абстрактных квадратов руки Пикассо. Зато есть флаг Hidden (ВСЕ, ВСЕ выставляют его программно в зависимости от событий!) и Stretching (я даже не знаю, что это такое);
    • Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;
    • Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!
    • После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;
    • Где внятные best practices по сторибордам, особенно если приложение не блокнот или калькулятор? Когда пытаешься портануть на айпад приложение, которое индус или соотечественник, увлеченный индийской культурой разрабатывал исключительно в сториборде, плачешь кровавыми слезами. Ячейки таблиц нужно вооще запретить создавать в сторибордах, ксибы и только ксибы! Система должна иметь минимальную защиту от дурака;


    Мало всего этого, нам недавно добавили новой боли в заднице:

    • Наиглючнейший интерфейс IB (простите тафтологию) из всех предыдущих реинкарнаций! Констрэйнты часто притворяются Leading space (видимо, такая рыба в собственном ксибе). Единственный способ понять, что это такое — чуть-чуть раздвинуть окно Assistant Editor-а, но!
    • При этом наш холст начинает плавно уезжать вверх и влево!
    • За год, прошедший с выхода iOS 6 все уже привыкли, что IB сам доставляет все ненужные констрэйнты до логической целостности, а тут он по умолчанию делает это неявно, во время компиляции ксиба! Так что предугадать, к чему приведет введение одного лишь width, без запуска приложения никак нельзя. Советую использовать команду «Add missing constraints» и верстать по-старинке.


    К чести Apple можно сказать, что констрэйнты перестали съезжать от каждого чиха на мышку, а ведь это доводило меня до нервного срыва 4 раза в xCode 4, а напарник друга коллеги даже скончался от сердечного приступа.

    Те, кто недавно открыл для себя iOS, хором поют «допилят!», свято веруя в икону яблока и Стива Джобса. На что я возражаю: «Не допилят!», у них всегда найдется десяток дел поважнее. Действительно важных, красивых дел, но Apple — мы имеем с IB дело каждый день, пожалей нас, простых смертных девелоперов!

    На прощание хочу предложить интересный опрос:
    Как вы верстаете UI в iOS?

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 70
    • +1
      IB не нужен.

      Сначала все весело-приятно, а потом внезапно пытаешься сделать шаг в сторону и начинаешь проклинать тот день, когда связался с этой шарманкой. Автолейауты можно было бы сделать по-человечески и из кода. Но не делают :(
      • 0
        Я тоже всегда так считал и считаю, но бывает множество факторов, когда приходится использовать ИБ. Например:
        — проект уже год велся с ИБ, переписывать все с нуля не дают;
        — все те же автолэйауты, которые по задумке чудо как хороши;
        — Эппл промоутит IB, и значит каждый день рождаются сотни программистов, которые используют IB. Хорошо если вы пишете свой проект, но придя в команду где используют IB, приходится использовать IB.
      • –3
        И мне кажется, что еще очень не скоро сделают вменяемый визуальный редактор интерфейса для iOS. Достаточно посмотреть на успехи Microsoft на этом поприще. Они свой xaml оттачивают уже с десяток лет, и все равно, его использование периодически напоминает адскую пытку, особенно, когда хочется запилить всякие финтифлюшки с анимациями или переопределением сложных контролов. Вместо одного рабочего языка ты вынужден учить два — сам язык + язык разметки. Тот кто думает, что это удобно, просто вряд ли с этим серьезно работал.

        Понятно, что эта идеология идет из веба. Но в вебе она вынужденная + несет определенные плюшки. Там это продукт стандартизации html. Но в мобильных и десктопных платформах от использования дополнительного языка для разметки мы не получаем никаких плюшек, так как нет единого стандарта. Замечания типа «зато любой дурак может верстать и не знать код» все равно разбиваются о суровую реальность. Не может. В итоге одни минусы и ровно один плюс — можно привлекать начинающих разработчиков тем, что формочки клепаются визуально.
        • +3
          Microsoft не показатель, в 1998 году с выходом Visual C++ 6.0 — сравните визуальный редактор Visual C++ 6.0 и Borland C++ Builder любой версии. Разница была просто колоссальна, а рынок и технологии — примерно одни и те же.
          • +4
            Сказануть такое мог только человек, учивший XAML по третесортным туториалам «как быстро сделать x на WPF». Достаточно прочесть нормально структурированную специализированную книгу, и вопросов не останется — там все очень логично и довольно просто.
            • +2
              Если в систему А добавить компонент Б, то система АБ никак не может быть проще, чем А и Б по-отдельности. Поэтому вводить Б — дурь.
              Можно было ничуть не хуже статическое объвление интерфейсов поддержать на уровне одного языка. Вон, у Xamarin есть JSON-подобный язык разметки для Monotoch.Dialog на основе C#. Работать с этим на порядок удобнее, чтобы ввести кастомное поведение или представление в контрол мне не нужно изгалаться на десяток файлов. Просто наследуешь и все. Что мешало MS сделать то же самое?
          • НЛО прилетело и опубликовало эту надпись здесь
            • –1
              Вы счастливчик, каких немного.
              • +1
                Меня тоже припишите сюда.
                Не имел никаких проблем с IB — только с Autolayout (тут приходится пользоваться своим, менее приятным решением)
                • +2
                  Так никаких или с autolayout'ом все же были? :)

                  Что еще раздражает, так это то, что Interface Builder при открытии файла зачем-то его меняет. Системы контроля версий (особенно, те, которые лочат файлы, типа P4) дуреют с этого. Точнее, системы контроля версий все контролируют, а дуреют программисты…
                  • +1
                    Autolayout не использую в принципе — это ужасный геморрой тянущийся сутками. Нервы свои стоит жалеть.
                    Думал, в Xcode 5 допилили, ан нет — все тот же ужас.

                    Коротко: проблемы были только с Autolayout, пока им пользовался.

                    А еще в Xcode 5 у меня полностью отвалилась история версий (git) во всех проектах — не знаю, что делать.

                    Недавно начал пользоваться eclipse, пожалел, что там нельзя вести разработку с IB и симулятором :(
                    • 0
                      Меня Autolayout в Xcode 5 порадовал, если что не так сразу напишет warning или ошибку
                      • 0
                        Кстати, беру свои слова насчет Autolayout в Xcode 5 назад. Только что научился им пользоваться. Есть пара хаков, которые приходится использовать — но, в основном, Apple отлично поправили его.
                        • +1
                          HTML-верстка прекрасно, все одинаково смотрится в разных браузерах, никогда не имел проблем с IE. Есть пара хаков, которые приходится использовать, особенно в CSS, но в остальном никогда не имел проблем.
                • +1
                  я тоже xib-ы использую, помоему хорошо так уменьшают объем кода, огорчает отсутствие стилей, если надо поменять шрифт, то надо менять его во всех xib-ах руками
                • +2
                  Меня в этот же список запишите. Много лет пользую IB — и ксибы и сториборды. Работаю с разной сложностью интерфейсами, все ок. Autolayout не использую :)
                • +3
                  «Еще один не выдержал — слабак!» :)

                  Самая пичаль это то, что генерит этот билдер (НЕХ), на андроиде design view используется только как превьюха, т.к. драгндроп работает еще говеннее, чем билдер. Но все прекрасно правится ручками с авто-подстановкой, авто-форматиронием и авто-сделайчтобыбыловсехорошо.

                  «Сотрудники компании эппл» решили, что негоже разработчикам трогать руками «сырой» xml и сделали ад и страдания. :) Впрочем, со временем я даже кое-что все таки там правил, смену контроллера и прочие плюшки прям из хмл/
                  • 0
                    Я тоже пытался, но все без толку — иногда работает, иногда нет — и напарываешься на неочевидные глюки. Потом через 2 часа пересоздашь ксиб, и понимаешь, что произошло что-то тебе не подвластное.
                  • +1
                    Еще немного раздражает такая мелочь — когда выбираешь в сториборде другую вьюху, список ее компонентов приходится «выбирать из длиннющего списка» всех контроллеров. Можно ведь было сделать подскролл.
                    • +2
                      Ох, как же я не люблю этот IB… и автор прав насчет автолэйаутов — это такой гемморой, если делать в коде с примесями IB.
                      • –1
                        >> дайте масштаб хотя бы 200%! Если на вьюхе много маленьких элементов, можно сойти с ума тыкая мышкой в микроскопические вьюшечки, выбирать из длиннющего списка — тоже задача не из быстроприятных;

                        Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.

                        >> визуально можно задать далеко не все свойства вьюх, хорошо если 30%.

                        Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?

                        >> Stretching(я даже не знаю, что это такое)

                        Я тоже. Но может тогда оно нам не надо?)

                        >> Раньше в качестве хедера таблицы катила вьюха (UIView), сейчас нужен UITableViewHeaderFooterView. Окей, откуда же мне ее перетащить в ксиб? Правильно, ниоткуда, пиши руками! А если вздумаешь подсунуть таблице UIView-ху, я обижусь и крэшнусь;

                        Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.

                        >> Нет внятного XML, который генерит IB. Вручную невозможно ни подправить, ни смержить. Начинаешь, прости господи, завидовать Android-разработчикам — у них есть в меру говеный визуальный редактор, но в случае чего пишите ручками — никто не обидится!

                        XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.

                        >> После смены класса вьюхи ее «IB-сверхъя» не меняется, что ведет к глюкам и крашам как вашего приложения, так и всего xCode. Допустим, вы полчаса создавали UITableViewCell со множеством сабвьюшек и констрэйнтов, и вдруг внезапно поняли, что вам нужен CollectionView и, соответственно, его ячейка. Выход один — пока вы не потратили невосполнимый запас жизненной энергии, удаляйте ксиб и пересоздавайте его с нуля. Только так Apple может гарантировать вам работоспособность приложения;

                        Тут согласен. Надо фиксить.

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

                        А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
                        • +3
                          >> Ctrl+Shift+Click выдает полный список вьюх под кликом и дальше двигаем стрелочками.
                          это что, удобнее чем 200% масштаб и клик? Это все равно что в фотошопе по слоям находить, либо визуально.
                          >> Я бы сказал 90% из самых юзабельных. Сейчас на вскидку не могу сказать свойств нет, но они очень нужны. А Вы?
                          Да, могу, список их не вместится на ваш монитор.
                          >> Я тоже. Но может тогда оно нам не надо?)
                          Но если оно мне и вам не надо, зачем тогда его выносить туда, где итак явный недостаток полезных свойств.
                          >> Метод у UITableViewHeaderFooterView initWithReuseIdentifier: как бы намекает что там не простая вьюха.
                          Вьюха правильная, но ее нет в IB, поэтому нет возможности задизайнить ее через IB.
                          >> XCode 5 сейчас генирит вполне читаемый XML. Даже править можно руками.
                          Не настолько правильный, как XAML или андроидовский лэйаут, недокументированный, непредсказуемый. Тоже заменял в нем классы, и бывало напарывался на странные косяки.
                          >> А в чем конкретно проблемы? Ну скопировал ячейки, по-растягивал и что?
                          Скопировал ячейки, порастягивал и потратил на это час.
                          • –2
                            >> 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»?
                            • +1
                              Глупо спорить с тем, что Xcode — угребище, а Interface Builder и того хуже. Альтернатива первому есть, а вот последнему — увы. То, что вы сейчас затеяли очень похоже на спор ради спора.

                              Не надо так.
                              • –1
                                Так пишите в Vim. Там-то все намного проще.

                                То, что Вы затеяли (я имею ввиду пост) очень похоже на нытье. Нравится Вам или нет Вы все ровно будете писать под iOS/MacOS в Xcode. Все альтернативы убогие.
                                • +1
                                  Вы в пылу спора ради спора забыли с кем и о чем спорите. Я не автор поста.

                                  Пишу частенько в sublime text, кстати. Чуть меньше, чем в Xcode, но все же. Но запросто могу поверить, что кому-то AppCode больше по душе, чем Xcode.
                            • 0
                              Для пропертей можно юзать «User-defined Runtime Attributes», там даже не property, а keyPath. Другое дело, что этот вариант очень не очевидный, можно несколько дней угробить, разбираясь откуда эти значения берутся. Но вариант.
                          • –3
                            Сталкивался с IB, только когда писал первое приложение.
                            Сейчас приложения используют настолько «нестандартный» интерфейс, что связываться с IB нет смысла вообще
                            • +6
                              В свете того, что сейчас происходит, у меня более скромные пожелания: «Apple, пожалуйста, не сломай то, что работает!»
                              • +3
                                С недавних пор перелез на Masonry для конструирования autolayout'а из кода. Визуально количество кода уменьшилось раза в три.

                                Тот код из поста переписывается в
                                [self makeConstraints:^(MASConstraintMaker *make) {
                                    make.width.equalTo(@0);
                                    make.height.equalTo(@0);
                                    make.top.equalTo(@0);
                                    make.leading.equalTo(@0);
                                }];


                                Нервов при написании constraint'ов поубавилось. Оно далеко неидеально, но действительно стоит того, чтобы попробовать.
                                • 0
                                  там появилось волшебная кнопка add another constrains в Xcode 5. Сорвала продолжительную овацию на WWDC %)
                                  • 0
                                    Ну да, я ж про нее писал :) если б не она, пришлось бы на картах гадать, куда xCode поставит констрэйнт
                                    • +1
                                      у вас глас вопиющего в пустыне. я сразу понял что тут херня и разделил nibs iphone/ipad а там немного подшаманиваю фреймы в зависимости от. получилось мининимум кода и понятно. эплы с constrains реально дали маху. ОЧЧЕНЬ сложно а они не в курсе что сложно :) потому что думают что совсем легко :)
                                      А когда у вас большой код и вы занимаетесь не только constrains, этот вижуал формат до одного места. это как засунуть в NSDictionary в одном месте volume & key а в другом потом мучительно вспоминать «что я нахрен имел ввиду в этой dictionary» :)
                                      • 0
                                        Что я могу ответить? Точняк!
                                  • 0
                                    Для уменьшения размера кода при работе с констрэинтами можно использовать Visual Format Language.
                                    Правда, если после этого вам по какой-то причине понадобится изменить один из добавленных подобным образом констрэинтов (т.е. его константу, больше там ничего менять нельзя), то искать нужный придется перебором массива constraints.
                                    А так да, работать с автолайаутом в IB не очень удобно. Хорошо, что хоть в XCode 5 этот процесс несколько улучшили, убрав, например, автодобавление недостающих констрэинтов.
                                    • +3
                                      Самый правильный путь — это самый простой.
                                      Да в 4 иксе автолейаут был говнищем. Ждем пока допилят пятый. Писать все в коде все равно не вариант, каждый раз НЕНАВИСТЬ когда сталкиваюсь с таким проектом и таской по рефакторингу или багфиксу оного. Поверьте, то что вы не можете попасть мышкой во вьюшку это ничто, по сравнению с рефакторингом чужого лейаут кода, зачастую похабно написанного.
                                      • 0
                                        верю, охотно верю!
                                      • +1
                                        Меня очень напрягают мерджи сторибордов на ровном месте, да и файлы проектов тоже не подарок. Хочу попытаться написать мерджилку сторибордов и проектов, хотя бы чтобы разруливались ситуации одновременного добавления экранов/файлов разными людьми. Пока мне кажется, что задача вполне решаема. Хабраюзер, нужна ли тебе такая утилита?
                                        • 0
                                          Нужна! Даже помочь могу!
                                          • 0
                                            Интуиция подсказывает, что задача не тривиальная, много подводных камней. Вообще, проблема с мерджем сториборда стоит действительно остро и подобный инструмент был бы многим полезен.
                                            • 0
                                              Если вы придумали хороший алгоритм, то это будет волшебная тулза!
                                            • 0
                                              Я не использую автоматического выравнивания и счастлив наличием IB.

                                              Что беспокоит меня?
                                              Подскажите, можно ли из *.xib, заведенного под iPhone сделать аналог под iPad простым копированием?

                                              Это действительно беспокоит.
                                              • 0
                                                Что-то я не понял вопроса. Т.е. вы хотите разные ксибы, но чтобы одинаково вели? Тогда зачем разные ксибы…
                                                • 0
                                                  Потому что размеры устройств разные. Какая лучшая практика для приложений типа Universal?

                                                  В данный момент я делаю так
                                                  1) завожу iphone_568.xib, создаю controls, связи;
                                                  2) копирую в iphone_480.xib
                                                  3) рихтую view под 480

                                                  Все. С Ipad.xib это не срабатывает. Приходится все элементы управления и связи тупо дублировать руками
                                                  • +1
                                                    Тут только AutoLayout поможет, судя по всему. В AL самое сложное, имхо, понять как он работает. Пока это понимание не пришло я дико плевался и также ненавидел Apple как и ТС.
                                              • 0
                                                Проблему с масштабом решал просто — выставлял координаты и размеры вручную. Причем весьма удобно смотреть расстояния до других объектов с зажатым Alt. Так что посмотрел сколько куда пикселей осталось — подвинул, растянул. Макеты получается сверстать пиксель в пиксель. То что на глаз расставил, все равно надо контролировать, чтобы стояло точно на своих местах.
                                                • +2
                                                  Я ни разу не ios разработчик, но моих фрагментарных знаний как раз хватает, чтобы заявить следующее.
                                                  AFAIK через IB можно задать абсолютно все свойства через user defined runtime attributes (key-value coding). И констрейнты все равно в коде трогать приходится если есть анимация позиции или размера.
                                                  • 0
                                                    Не совсем все, например какой-нибудь CGColor не выйдет. Как-то раз хотели так задать цвет границы у layer, пришлось кодировать
                                                    • +2
                                                      Ну это не такая уж большая проблема, по сравнению со пачкой кода который занимается только лишь расстановкой, порой, статических элементов, содержимое и внешний вид которых не меняется
                                                  • +2
                                                    > а напарник друга коллеги даже скончался от сердечного приступа.

                                                    это шутка, или такое действительно имело место? Как пользователь IB, в реальность такого охотно верю.
                                                    • 0
                                                      Шутка конечно, но недалекая от истины :)
                                                    • +1
                                                      Лолшто? Может не Apple виноват в, простите, кривоватости чьих-то решений и рук?

                                                      Поделюсь с вами тайным секретом, только не рассказывайте никому, а то не дай Б-г люди перестанут писать контроллеры по 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.

                                                      Безусловно это все ужасно, лучше фигачить все руками, да.
                                                      • 0
                                                        Один хитрый трюк, скорее похожий на хак, вы выучили и обвиняете меня в кривости рук — да, вы большой молодец. Это, безусловно, позволяет вам утверждать что я верстаю 800-строчную простыню.
                                                        • 0
                                                          А где здесь хак? Нормальное стандартное решение.
                                                          Меня жутко раздражают вот такие гневные посты с советами от советчиков, «начинающие» разработчики смотрят на такие высказывания и берут их в толк, после чего имеем как раз те самые контроллеры на 800 строк и синглтоны синглтонов завернутые в макрос в макрос в макрос…
                                                          • 0
                                                            Может тогда по всем пунктам пройдетесь, чтобы не быть голословным.
                                                      • +1
                                                        Вся надежда на AppCode :)
                                                        • +1
                                                          Была бы, если бы не на яве… :)
                                                          • 0
                                                            Учитывая как тормозят сториборды в нативном Xcode, будет смешно, если JetBrains удастся сделать более шуструю реализацию на Java.
                                                            • +3
                                                              За что минусуете, они реально тормозят на любом железе.
                                                        • 0
                                                          Использую UIView-AutoLayout для autolayout'a. Все хорошо, IB не нужен, спасибо)
                                                          • 0
                                                            Просмотрел API, либа вроде неплохая. Но не убирает один косяк — если приходится периодически копаться в чужом коде, поддерживать что-то, все равно придется иметь дело со стандартными средствами. Так что стандартные пути все же предпочтительнее.
                                                            • +1
                                                              Да, использую ее в проектах по «обоюдному согласию». Ее плюс в том, что в отличии от других популярных либ (keep и mansory) она ближе к эппловскому стилю и при этом возможностей выстрелить себе в ногу в ней гораздо меньше. В связке с VFL и пониманием того как все работает внутри либы (а там элементарная категория) autolayout можно и руками после нее писать.
                                                              А вообще замечание про чужой код справедливо практически ко всем либам)
                                                              • 0
                                                                Либы — часто хорошо, главное не злоупотреблять :)
                                                          • 0
                                                            Ссылки на несколько хелперов для autolayout в комментариях уже есть, вот до кучи альтернативный подход: github.com/ReactiveCocoa/ReactiveCocoaLayout
                                                            • +1
                                                              Не боитесь, что у вас будут сложности с устройством на работу после этого поста?
                                                              Шутка :) Стивов Джобсов уже нет.

                                                              Никогда не имел проблем с IB, и, скорее, получаю удовольствие от него.
                                                              Даже для самого харкордного кастома от заказчика у меня как-то всё просто получается.
                                                              Часто сложные интерфейсы разделяю на простые вью
                                                              Кода для вью получается не более двух страничек… Или для вью-контроллера — не более, чем трёх страничек.
                                                              На вью обычно у меня от двух до четырех аутлетов. Если становится больше, надо подумать, может быть стоит разбить вью на несколько частей?
                                                              Если вью-контроллер большой, может быть из него стоит вытащить код в невью-котроллеры (типа GameProgressController, MyNetworkRequestsChainController и т. п.).

                                                              Посоветую вам не использовать сторибоарды, если вы не один в команде. Ксибы — хороший способ реюза частей интерфейса и комфортный распределенный девелопмент. Ксибы и сторибоарды можно (а иногда нужно) сочетать.

                                                              В общем, делайте всё для своего удобства. Негритянский труд в виде таскания брёвен — это что-то далекое от программирования и мешает творчески подходить к задаче.
                                                              • 0
                                                                Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы.
                                                                В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.

                                                                В общем, в любом случае размер кода растет пропорционально количеству связанных между собой элементов, видимых единовременно на экране. Конечно, если нужно показывать, скажем, прогноз погоды и новости — можно смело делить их в совершенно разные контроллеры.

                                                                Сториборды можно использовать, не надо только там создавать ячейки и лепить много контролов прямо на вьюху контроллера — замучаешься переносить на айпад и обратно.

                                                                И все же, повторюсь, основной посыл статьи таков: Apple может потратить часть ресурсов и допилить IB до более законченного состояния. В 2009 я программил под мак и под iPhone OS — под мак создавать интерфейс в IB было раем, он был очень похож на рантаймовые вьюшки. Под iOS — как было занятие ниже среднего, таким оно и осталось.
                                                                • 0
                                                                  >>Даже если б и был, я б ему и тогда сказал, что IB как был полусырым продуктом в 2009-м, так и по сей день не выходит из этой фазы. В достаточно больших проектах вью контроллеры разрастаются и до нескольких тысяч строк — тогда делю их на DataSource и сам контроллер, выношу делегаты в отдельные классы (например, обработка коллбэков таблицы или collection view) — но у этого есть и обратная сторона медали, вследствие декомпозиции нужно создавать дополнительные интерфейсы и иные связи.

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

                                                                  А в ваших проектах как много классов, которые можно просто перетянуть курсором мыши в другой проект и они заработали бы?
                                                                  У меня где-то 50%-70% в зависимости от проекта, включая наследников UIViewController и UIView.
                                                                  • 0
                                                                    Не, никак не 50-70%%. Кроме чего-то универсального, есть 80% кода, который завязан на конкретное приложение и имеет смысл только в контексте его. Возможно, сказывается долгая продуктовая разработка — когда работал на аутсорсинге, процентов соответственно было больше.

                                                                    Ну и тут есть обратная сторона медали. Знал одного программиста, который долго работал замкнутый сам в себе, уж очень интровертный человек. Добавили его к нам на проект, к тому моменту уже шедший 1.5 года и в различное время писанный 3-4 девелоперами. Вместе с ним прилетело штук 50 файлов с префиксом от его имени-фамилии, большинство функциональности в которых дублировало уже имеющуюся. В общем, в команде стараюсь пользоваться вмес стандартным, и как можно меньше самописности — особенно в iOS, где стандартные библиотеки вполне неплохи.
                                                              • 0
                                                                [удалён]
                                                                • 0
                                                                  Как интересно, наткнулся на свой пост трехлетней давности, а воз и поныне там. Появились Swift, часы, вот API с нейронными сетями на подходе, а IB как был так и остался, статья актуальна до сих пор

                                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.